End-User%20Application%20Development%20for%20the%20Semantic%20Web

1
End-User Application Development for the Semantic
Web

• Karun Bakshi
• kbakshi_at_mit.edu
• Computer Science and Artificial Intelligence
  Laboratory (CSAIL), MIT

2
Overview

• Tools for performing information based tasks are
  lacking.
• We need to fix these problems if we are to fully
  leverage all the information at our disposal.
• I propose an approach to fix these problems and I
  think the Semantic Web can help.
• In the process we demonstrate
• An application of the Semantic Web
• Applications for the Semantic Web

3
Agenda

• Introduction
• Related Work
• Approach
• Demonstration
• Implementation
• Discussion
• Evaluation
• Conclusion

4
Introduction
5
Information Based Tasks

• Information Based Tasks
• Require multiple sets of information and
  functionality
• Can reuse and visualize the same information and
  functionality from other tasks
• Use Cases
• Military Commander
• Doctor
• Software Project Manager

6
A Day in the Life of a Software Project Manager

• Receive E-mail Bug Report from Customer
• Check Task Assignments
• Log Bug in Bug Tracking Software (automatic
  e-mail notification)
• Schedule meeting via e-mail and update calendar
• Update Project Schedule and Task Assignments
• Update Project Budget

7
How Do We Accomplish Such Tasks Today?

• Users Must
• Dig deep and wide to find relevant information
  and functionality
• Mentally collate information
• Re-enter Information ? Data Synchronization?
• Lather, Rinse, Repeat
• A solution that allows aggregating relevant
  resources would
• Increase efficiency
• Be mission critical

8
Status Quo A Potential Solution?

• Build an uber-Application or build a task-focused
  application. But
• How do I reuse the calendar or e-mail for another
  purpose?
• What if I need to track additional information?
• What if I do a certain new task more often?
• How does another user tackle the same problem?
• How do we handle feature creep?

9
Source of Problem

• Tasks are Fluid. Information and functionality
  depends on
• User
• Expertise
• Preferences
• Task Definition
• Task
• Evolve over time
• New unanticipated tasks appear
• New information is available that can be
  incorporated
• Applications are static!

10
Problem Definition

• How do we provide users with an interface
  supportive of their tasks while avoiding the
  problems engendered by application shortcomings?
• How Important is this Problem?
• WWW ? more information
• WWW ? more complex tasks
• WWW ? lay users
• What about ad hoc multi-domain applications?

11
Related Work
12
Related Work
UI Real Estate Management
Task Focused Applications
Workspace Builder Tools
Build Task Workspace
Creation
Configure Task Workspace
Configure Operations
Configure Content
Configuration
Configure Presentation
Task Management Interface
Data Management Interface
13
MyYahoo!

• Allows Selecting
• Content
• Layout
• Relevant Operations

• Limited to News Domain
• User can configure settings, rather than create
  them

14
SNAP Together Visualization

• Linked Content
• Arbitrary Content
• Multiple Visualizations
• No UI Programming

• Knowledge of schema and SQL, or use fixed
  queries
• Fixed visualizations
• Primarily for data exploration

15
WinCuts

• Allows collaboration
• Peripheral awareness
• Supports multiple domains

• Cannot be persisted
• Have to go to source window to change content
• Pixel based content, not semantic
• Shareable, but not transferable

16
Important Ideas

• Window Management
• Persistent Habitat
• Persistent Queries
• Dynamic Content
• Reusable Content
• User Creatable/Editable
• Co-Location of Relevant Operations
• Synchronized/Linked content

17
Important Ideas (contd.)

• Little knowledge of underlying schema
• Powerful query ability
• Tasks require peripheral awareness of other
  happenings
• No Programming
• Multiple visualizations
• Low overhead reconfigurability
• Applicable to multiple domains

18
Whats Missing?

• General Purpose Interface
• All above properties
• Domain Interoperable (support multiple domains ad
  hoc and simultaneously)
• Transferable
• Semantic Interface

19
Approach
20
Our Approach

• Combine desirable characteristics in a single
  system
• Information Management Interfaces Should Match
  Tasks.
• Users Know Tasks Best
• Therefore Give User Control Over Building Them
• What are the application building primitives that
  users must control to match the fluid nature of
  tasks?
• What we are NOT trying to achieve
• The best implementation for particular
  techniques, feature sets, UI widgets, etc.

21
Our Approach (contd.)

• Unify the Data Model
• Let Users Build and Populate a Task Workspace
• Formalize Structure Existing Ideas/Features
• Content
• Presentation
• Manipulation
• Give users fragments of functionality to select
  aggregate for unique tasks

22
Semantic Web Motivation

• Information on the World Wide Web is primarily
  intended for human consumption with complex
  semantics distributed across text, images, video,
  sound
• There is no way for machines to use and leverage
  such information easily and effectively
• Thus, very little on the WWW can be automated,
  and use of all the information on the WWW is
  constrained to the limited bandwidth of human
  processing

23
Semantic Web What is it?

• An initiative to embed semantics into content on
  the WWW to make it amenable to machine
  processing.
• Semantics are embedded via metadata annotations
• Software (agent) understands the annotations
  because they follow a particular schema/ontology
• Different schemas can be used to describe the
  same entity
• But with metadata annotations, we begin to have a
  substrate for automation

24
Semantic Web The Data Model

• Semi-structured (unenforced and/or partial schema
  validation) data models are very flexible
• Captures multiple domains
• Models the web
• Linking content from multiple domains in a
  growing (multi-schema) web
• No single schema to enforce

25
Resource Description Framework (RDF)

• A specification/technology that captures and
  defines such a semi-structured data model for the
  Semantic Web
• Can be used to capture content from multiple
  domains
• Provides a common interchange format (XML based)
  that allows applications to communicate

26
RDF Example
Karun has a blue cat named Max, and Karuns
friend John has a blue car.
John
ltURIgt
ltURIgt
URI Universal Resource Identifier Literal
String data
Karun
ltURIgt
Blue
ltURIgt
Blue
Max
27
RDF Example
Karun has a blue cat named Max, and Karuns
friend John has a blue car.
John
ltURIgt
ltURIgt
Karun
ltURIgt
color
FF
type
color
type
blue
ltURIgt
ltURIgt
ltURIgt
00
green
ltURIgt
name
Car
red
name
Max
00
Cat
28
How Does the Semantic Web Fit In?

• A Problem?
• More information
• Faster generation of information
• Highly granular information

• An Opportunity?
• RDF models multiple domains
• RDF allows granular access and annotation

29
Whats Left?

• Tools that let users create a task workspace by
  manipulating fragments of
• Content ? Queries (Channels) ? Channel Manager
• Presentation ? Views Layout ? View Designer and
  Workspace Builder
• Manipulation ? Operations ? Workspace Builder
• Haystack provides
• such fragments at the developer level
• other supportive capabilities
• Build tools to expose them to the user

30
Haystack

• An general purpose information management platform

User Interface Framework
Adenine
RDF Store
Services/Agent Framework
31
Haystack Views
Browsing Paradigm
Recursive Rendering
32
Haystack User Interaction

• Direct Manipulation
• Drag Drop
• Context Menus

• Operations
• UI Continuation
• Currying

• Demonstration

33
Demonstration
34
Tool Set

• Workspace Designer
• View Designer
• Channel Manager

35
(No Transcript)
36
Implementation
37
Implementation
Workspaces Builder Channel Manager Views Designer Haystack
Content X (selecting) X (defining)
Presentation X (layout) X (user views) X (developer views)
Manipulation X (Select Curried Operations,Dynamic Binding) X (developer operations, drag and drop, context menus)
38
Implementation (contd.)

• Each Application Building Primitive has
• An ontology
• A set of views
• Each tool generates RDF entities according to an
  ontology
• User navigates to each entity and modifies it
  using its view(s)
• Each entity can have several views, e.g. Design
  View vs. Usage View

39
Implementation (contd.)

• Store views, operation, content description and
  workspace as metadata along with application data
  in single format

40
Workspace Designer

• Design Decisions
• Space Allocation to Winlets
• Modality in Workspace Interaction
• Uniform Treatment of Views
• Dynamic Binding and Currying

41
View Designer Pattern

• Developer Created Designer
• Exposes domain specific capabilities to
  create/customize views
• Named view that can be reused in any context in
  Haystack, just like any other view

42
Property Lens View Designer
43
Property Lens View Designer (contd.)

• Captures
• RDF semantics only (property name and value)
• Resource ? View
• Literal ? Read-only/Editable
• Layout
• Has design and usage views
• Design Intentionally Abstract
• Multi-valued properties are supported
• Provides baseline view extensibility without
  developer support or additional view designers

44
(Information) Channels

• What is a channel?
• Query
• Dynamic set of items (no ordering) ? URIs only
• Organizing mechanism for dynamic corpora
• What are the implementation components?
• Channel Agent
• Query Primitives
• Query
• View of Query Primitive

45
Channel Query Primitives
ltQuery Primitive Argumentsgt
queryPrimitive
ltSet of URIsgt
RDF Query Primitives
Operators
Domain Specific Query Primitives
ltURI1gt ltURI2gt ltURI3gt
Property Constraints
46
Channel Query Primitives
47
Discussion
48
Discussion

• Transferable and Personalizable
• Capture process in an interface
• Low overhead task switching
• Extensible by developers
• Seamless integration of user/developer extensions
• Consistent interaction modality
• Domain specific view designers
• Benefits of Channels
• How much work is this?

49
Evaluation
50
Evaluation

• By Example
• Our tools/Specialized tools
• Paper Writing Workspace ? bridged multiple
  domains
• Project Management Workspace
• Preliminary End-User evaluation with
  Massachusetts General Hospital researchers

51
Evaluation (contd.)

• Future User Study
• Is such just in time information management
  desirable?
• Can users succeed with such an task interface
  paradigm (not whether the particular interface
  implementation is usable)?

52
Conclusion
53
Conclusion

• We advocated user specified task workspaces
• We identified three primary aspects of tasks ? a
  simple ontology for building applications
• We provide tools that allow composing fragments
  of functionality into task workspaces
• Content ? Channels
• Presentation ? Views
• Manipulation ? Operations

54
Conclusion (contd.)

• We demonstrated the usefulness and validity of
  the ideas (although a field study is currently
  lacking)
• We have proposed a solution to the general
  problem of information management that will be
  even more critical for the Semantic Web
• Tools to take advantage of Semantic Web content
  immediately
• Tools to build applications for the Semantic Web
• We have proposed an application of the Semantic
  Web

55
Future Work

• Better UI for Tools
• Other enabling components for Semantic Web
• Ontology Translation
• View Servers

56
Acknowledgements

• Project Oxygen and Biomedical Informatics
  Research Network (www.nbirn.net) for funding
• David Karger for Advising
• Various audiences and friends for helpful
  feedback on this work and presentation

57
Thank You!

• http//people.csail.mit.edu/kbakshi

58
(No Transcript)