Ubiquitous Metainformation and the W Y W W Y W I Principle

1. Ubiquitous Metainformation and the W Y W W Y W I Principle Michael Bieber*, Joe Catanio*, Li Zhang** *Information Systems Department **Computer Science Department College of Computing Sciences New Jersey Institute of Technology http://web.njit.edu/~bieber November 2003 This talk ties together much of our current research.. It also gives a vision of where the WWW is heading. 1

2. The W Y W W Y W I PrincipleWhat you want, when you want it Wanting to point to something and say: • Tell me more about this! • What is this? • How can I use this? What do I need to know to use it? • Can I modify this? • How does this differ from similar ones? • What is the next step? This is all metainformation & people should get it! 2

3. Ubiquitous Metainformation Goal: Metainformation widespread in everyday systems How: provide tools for developers • Relationship Analysis • systematically determining metainformation • Metainformation Engine • automatically generating metainformation • WYWWYWI Principle • widespread accepted design philosophy 3

4. Examples Metainformation (what to provide) Relationship Analysis (how to find metainformation) Metainformation Engine (how to automate it) Virtual Documents (many real world documents) Related Work WYWWYWI (what it will take) Outline 4

5. Metainformation • The full context within and around an element relationships metadata element 5

6. Roberto Galnares’ dissertation Metainformation • metadata(about selected element) • content relationships (based on display content) • structural relationships(based on element type or “class”) • annotation relationships(user-declared, knowledge-sharing) • metainformation-based navigation(user-directed) 6

7. Examples Metainformation (what to provide) Relationship Analysis (how to find metainformation) Metainformation Engine (how to automate it) Virtual Documents (many real world documents) Related Work WYWWYWI (what it will take) Outline 7

8. Joe Catanio’s dissertation Relationship Analysis (RA) • What metainformation could we provide? • RA: a systematic methodology to determine relationships (& metadata and new destination elements) • New systems analysis technique • Fills a major hole in software engineering • Analysts gain deeper understanding of a system • Yields richer analyses and designs • Relationships become links 8

9. Relationship Analysis (RA), cont. • approach: brainstorming with domain experts • for existing systems: • pick elements from screen shots • for new systems: • pick entities from use cases • Ask questions from RA taxonomy 9

10. RA Taxonomy • based on Guilford’s Structure of Intellect theory [1950] • describing intellect and creativity • refined by Rao & Turoff’s Hypertext Morphology [1991] • for systems analysis 10

11. RA Taxonomy 11

12. RA Taxonomy 12

13. RA: Brainstorming Questions 13

14. Examples Metainformation (what to provide) Relationship Analysis (how to find metainformation) Metainformation Engine (how to automate it) Virtual Documents (many real world documents) Related Work WYWWYWI (what it will take) Outline 14

15. Metainformation Engine • “Just in time” metainformation • required for virtual documents (e.g., query results) • Automatically: • generates link anchors • generates links to services providing metainformation: • metadata, content, structural, annotation relationships • incorporates metainformation-based navigation • Provides lightweight systems integration through linking to everyday systems Roberto Galnares’ dissertation 15

16. Example • Purchasing System • screen shot of our prototype later... 16

17. Sample Screen from Purchasing System: All text with no links... 17

18. But we could want metainformation about almost any element... 18

19. V0000304390 {vendor} Vendor Details{Vendor IS} Vendor Reliability{Vendor IS} Vendor Agreements{Vendor IS} Other Possible Vendors{Purchasing Data Warehouse} Your Purchasing History{Purchasing IS} All Screens with this Vendor{CASE Workbench} 19

20. User’s Web Browser Metainformation Engine ME Desktop ME Relationship Engine ME Broker ME Lexical Analysis Vendor IS Wrapper Purchasing D.W. Wrapper Purchasing IS Wrapper CASE Workbench Wrapper Service Wrapper (i) Vendor Information System Purchasing Data Warehouse Purchasing Information System CASE Workbench Service (i) existing system or Web service To Integrate: (1) wrapper: parses screens to identify elements (2) provide metadata/structural rel’ship rules (3) identify glossaries for content relationships uses Java, XML, Xpath, etc. 20

21. User’s Web Browser Metainformation Engine ME Desktop ME Relationship Engine ME Broker ME Lexical Analysis Vendor IS Wrapper Purchasing D.W. Wrapper Purchasing IS Wrapper CASE Workbench Wrapper Service Wrapper (i) Vendor Information System Purchasing Data Warehouse Purchasing Information System CASE Workbench Service (i) To Integrate: (1) wrapper: parses screens to identify elements (2) provide metadata/structural rel’ship rules (3) identify glossaries for content relationships uses Java, XML, Xpath, etc. existing system or Web service 21

22. V0000304390 {vendor} Vendor Details{Vendor IS} Vendor Reliability{Vendor IS} Vendor Agreements{Vendor IS} Other Possible Vendors{Purchasing Data Warehouse} Your Purchasing History{Purchasing IS} All Screens with this Vendor{CASE Workbench} Relationship Rules • element type (“vendor”) • link display label(“Vendor Details”) • relationship metadata for filtering links • semantic relationship type (“elaboration”) • relationship keywords • destination system(“Vendor Info System”) • exact command(s) for destination system(“retrieve_full(ID, details)”) • conditions • user types and tasks, expertise required, access restrictions 22

23. Relationship Rules • Mechanism for implementing access to: • Metadata • Structural relationships • Content-based relationships • Annotation relationships • Metainformation navigation 23

24. Prototype:Digital Library Integration 26

25. Interesting Issues • Information overload! • Must filter and rank order list of links • Too many anchors • Requires good user interface design • Semantics • Systems/services should use same element types • Unique persistent identifiers • For every screen, document, element of interest 27

26. Examples Metainformation (what to provide) Relationship Analysis (how to find metainformation) Metainformation Engine (how to automate it) Virtual Documents (many real world documents) Related Work WYWWYWI (what it will take) Outline 28

27. Virtual Documents • from user interaction, queries, customizations • Metainformation must be added “just in time” • Example • do a decision support analysis (“# vehicles needed”) • add comments to calculation results • bookmark screen (“make it a favorite”) • close screen • follow bookmark later (“system regenerates screen”) • system must re-locate comment anchors “just in time” 29

28. Li Zhang’s dissertation Virtual Documents • Re-generate virtual documents • without re-entering parameters • then wrapper parses to add metainfo anchors • Re-identify elements • Location can shift • content can change (e.g., stock price) • Re-locate anchors 30

29. Examples Metainformation (what to provide) Relationship Analysis (how to find metainformation) Metainformation Engine (how to automate it) Virtual Documents (many real world documents) Related Work WYWWYWI (what it will take) Outline 31

30. What you want, when you want itWhat will it take? • WYWWYWI mindset for developers & public • Developer Tools • Relationship Analysis • Metainformation Engine • Wrappers for everyday systems • Annotation/knowledge-sharing services (linking, comments, guided tours, etc.) • Ubiquitous Access • To repositories of relationship rules/glossaries 32

31. Metainformation broader conceptualization Relationship Analysis (how to find metainformation) Metainformation Engine (how to automate it) Lightweight systems integration through linking Virtual Documents Re-generation, re-identification, re-location WYWWYWI: a design philosophy What you want, when you want it Research Contributions Thank you! Questions, please? 33