Unference: UI (not AI) as key to the Semantic Web

1. Unference:UI (not AI) as key to the Semantic Web David Karger

2. A Semantic Web Vision • Autonomous computational agents perform sophisticated information tasks on behalf of their human users • Use data that is annotated with rich semantics • Ontologies that explain precisely what the data means • Schema annotations that explain how to align multiple ontologies • Rules that explain how new data can be formally derived from existing • Inference systems that put it all together • Lots of logicians and AI researchers developing tools • This vision is frightening • Involves solving problems that have bedeviled AI for decades • Often used to attack the semantic web • Or to argue to slow down deployment • “we can’t put up that data until we have an ontology!”

3. SW As Enabler for Real Intelligence • Leave inference to people • Build UIs that make it easier for them to do it • Free data from applications and web sites • Users decide • what data they need • what it should look like • how to organize it • UIs that look a lot like existing applications • Hide complexity of Semantic Web • But expose new capabilities SW offers for fluid data • In tension with previous goal • Better UIs are the low hanging fruit that can bring the SW forward before AI is ready

4. David’s Layer Cake User Interface RDF XML Unocode

5. Why Applications? • Typical user tasks require interaction with multiple pieces of information • Display • Explore • Query • Manipulate • Applications bring together the data, specialized views, and operations necessary to perform tasks

8. Irrelevant info Distracting Covers up more important info Artist Of dance, not music ID3v2 added “Composer” shown in wrong place • Menu of genre choices • My genre (of dance, not music) missing • ID3v2 lets user add • No “difficulty” field • Place in comment field • Uses field up • Where put “tempo”?

9. Summary of Problems • Application has fixed idea of “right” data • Both properties and values for them • And right way to display that data • User wants to “stretch” the app to their needs • Cannot hide irrelevant data • Cannot incorporate new kinds of data • Cannot change how data is presented • Perhaps just use generic comment field? • Add what you want • Format how you want

10. Properties have structure • Used for layout • And for browsing

11. Sometimes, one application isn’t enough • Applications inappropriately partition task • Because task wasn’t planned for in application design • No application has all the necessary data, operations • Need to launch several to do task • Each includes unneeded data, operations • Clutter distracts from what you need to see • Can’t work with data “across” application boundaries • Can’t record or view data connections • Have to find it again in second application • Or enter it manually a second time • Type budget numbers on postits to move to other application

17. Why? • Building applications is hard • Done by expert few for the many • They determine which data, views, operations are useful • Applications are “mass produced” • Everybody gets the same one • And only build for large markets • Word processor, email, photo album, … • Problem: different people want different applications • Basket weaving. UFO sightings, junkyard management • Want to work with unusual information • Want to see, navigate, manipulate it “their way” • Developers can’t afford to build these boutique applications

18. What about the web? • Web sites static, like applications • Struggle to manage data across sites • Mash-ups show desire for and benefits of mixing data • But you have to be a programmer to make your own

19. Better living with the SW • Applications aren’t that complicated: • What data should be in view? • How should it be shown/laid out? • What operations will be used to manipulate that data? • Most apps look the same: • Screen broken into tiles • Each contains a collection or an information object • Each object shown with some properties, “formatted” in certain layout • It should be possible for end users to specify these things • Create applications and web sites by describing, not programming

20. Fresnel dsp:publicationLens rdf:type :Lens; :classLensDomain ow:Publication; :group gr:group; :purpose :defaultLens; :showProperties ( dc:description dc:identifier dc:creator dc:contributor dc:date dc:subject dc:type dc:publisher dc:rights ) . dsp:rightsFomat rdf:type :Format; :group gr:group; :propertyFormatDomain dc:rights; :propertyStyle "dspace-rights" .

21. Haystack

22. Workspace Designer • Editing mode for applications • Define regions of screen • By splitting existing regions • Resize Regions • Specify content of each region • Object to be shown (drag and drop object) • Lens to use to show object (menu of relevant lens) • Operations to make available on object (drag operations)

23. Writing a Brain Research Paper

24. Adding “Things to Do” Region

25. Revised Application

26. Opportunities and Challenges • Huge opportunity to let and users manually aggregate and visualize information from multiple sources • Breaks traditional application model • When building app, don’t know what data will be subject • Cannot plan views, layouts, manipulation in advance • No boundaries---where is end of application? • Need new languages (Fresnel) for specifying what to do • And natural UIs for authoring these specifications • What can most users do? • Can’t program • Can rearrange window layouts and icons on screen (“customize”) • Find a middle, where customization becomes end-user application development • Authoring • Output has tremendously outpaced input