IRIS Ontology

1
IRIS Ontology Linking FRD

• Contributors Jack Park, Michael Ginn, Adam
  Cheyer, Sunil Mishra
• Credits also to Melinda Gervasio, Colin Evans,
  Steve Hardt, Leslie Pound, Rich Giuli,

2
Philosophical Question

• What does IRIS want to be when it (she?) grows
  up?
• Thats not an idle or silly question
• The issues revolve around
• How much Knowledge does IRIS contain
• How will IRIS use that Knowledge?

3
What we know (from IrisPRD)

• IRIS provide an application framework for
  enabling users to create a personal map across
  their office-related information objects
• Provide dashboard views, contextual navigation,
  and relationship-based structure across a suite
  of apps, such as calendar, email, web, file,
  messaging, etc.
• Share a semantically rich view of (authorized
  parts of) the users work life, with CALO and
  other teammates

4
Outline

• Ontology FRD
• Linking (Knowledge Acquisition) FRD

5
Big Picture
Ontologies
Linking
Applications
6
Goal Summary

• A goal is to craft a software framework, IRIS,
  which is onto-centric, meaning
• Framework is partly created by some ontology
• Framework robustly supports a range of existing
  ontological entities as a knowledgebase
• Framework supports the creation, update, and
  deletion of knowledgebase entities
• Framework supports limited inference process
  across the IRIS knowledgebase
• Framework supports user-initiated linking among
  knowledgebase entities and to external entities
  (knowledge acquisition)
• Framework supports semantic interoperability with
  other IRIS platforms
• Recall the philosophical questionAnd what we
  know
• Constraints on level of knowledge in IRIS

7
Ontology Overview

• This section specifies those functional
  requirements associated with the creation,
  maintenance, and application of ontologies
  specifically, office environment ontologies
  within the IRIS and related to IRIS/CALO
  platforms.

8
Ontology Personas

• IRIS Applications
• Ontologies form the foundations on which
  applications interoperate in IRIS
• IRIS User Interface
• Write interface objects to specific ontological
  entities
• Data
• Ontologies provide data definitions
• IRIS Users (people and agents)
• Use ontological entities in
• Relationship formation
• Categorization
• Search
• Inference
• Query Manager (QM)
• Other CALO applications (?)

9
Ontology QM/IRIS Needs

• IRIS needs 3-store to handle frames and slots
• Need ontologies between IRIS and CALO aligned
• QM needs way to access triples in IRIS
• Could state queries in
• OWL not recommended too hairy
• RDF query language
• QM to provide export of appropriate ontology for
  IRIS

With thanks to Sunil Mishra
10
Ontology Problem Statement

• The problems to be solved involve the
  determination of
• The appropriate type of ontology necessary to
  support IRIS in its mission
• The appropriate architecture necessary to support
  an onto-centric framework
• The implementation design necessary to integrate
  the IRIS onto-centric framework with the
  RadarNetworks infrastructure

11
Ontology Requirements

• Ontology should support
• Data definitions/constraints
• Relationship definitions
• Category definitions
• User Interface definitions/constraints
• IRIS behavior definitions/constraints (?)
• Data manipulation definitions/constraints (?)
• If IRIS is to serve as a complete knowledgebase,
  added features might include
• Class definitions

12
Minimalist View of Ontology Requirements

• Basic IRIS may only need
• Vocabulary words
• Relationship names
• Category names
• RDF vocabularies
• vCard
• iCal
• Other vocabularies for TeamShare, etc.
• Such entities as required to interoperate with
  CALO

13
Ontology Design

• Ontology Desiderata
• Ontology Design Issues
• Ontology Recommended Path

14
Ontology Desiderata

• RESTful Architecture for linking communications
  within IRIS
• Simplest possible API
• Prototypical URI specification
• Subject (application) e.g. http// , app// ,
• Predicate (behavior) e.g. put, display,
• Object (object ID) e.g. http//server.org/ema
  il4545454
• E.g.
• app//Calendar/put/http//calo.sri.com/CalEvent12
  345
• Lots of room for design work here
• Compatibility with CALO Ontologies
• Interoperability with CALO for queries and other
  CALO support
• IRIS capable of loading and running from
  different ontologies

15
Ontology View Points

• Ontology from the point of view of knowledge
  engineering and interoperability
• Relationships in the IRIS knowledgebase
• Categories
• Ontology from the point of view of software
  architectures, the IRIS implementation

16
Ontology Design Issues

• IRIS Framework
• Applications to support
• User Interface (HCI) issues to support
• Overall Framework issues
• Interoperability
• Robustness
• Specification Architecture
• OWL
• RDF and RDFS
• Recall the philosophical question

17
Ontology Dependencies

• Final implementation is dependent on the
  architecture
• API driven
• API
• Implementations of the API
• Jena2 with wrapper
• RadarNetworks (RN) with wrapper
• Application driven
• Direct Jena2
• Direct RN
• IRIS 1 is API driven
• IRIS 2 with RN may be Application driven
• Whatever API is inherent in RN

18
Ontology Recommended Path

• 1.3 Near term (immediate)
• Parallel
• Integrate with RadarNetworks
• Determine ontology specifications in concert with
  QM (and other CALO) teams
• 1.4 Later
• Demonstrate import of OWL ontologies from Query
  Manager (QM) export
• Develop inference mechanisms to support QM
• 2.0 Much later
• The big Kahuna

19
Tasks

• 1.3
• Come up to speed with RadarNetworks
• Refactor IRIS
• Includes lots of subtasks associated with other
  IRIS design issues (e.g. unifying Journal and
  Chat apps)
• May include redesign of ContextManagementApp (see
  Linking FRD)
• Does include general redesign associated with the
  RadarNetworks architecture
• Acquire example ontologies from QM group for
  development

20
Linking Overview

• Linking is taken as an instance of Knowledge
  Acquisition
• Linking is the processes and application(s)
  required to support the construction,
  maintenance, and application of relations,
  categories, annotations, reminders and other
  links between and among semantic objects in the
  IRIS universe (knowledgebase), and with objects
  outside the IRIS universe, such as Web pages,
  files in local storage (hard disks, etc), and
  other objects.

21
Linking Personas

• IRIS Applications
• Applications may need to forge links, as does,
  for example, the present ActivitiesApp, which
  internally provides createdBy links to Activities
• IRIS Users
• IRIS users benefit greatly with the ability to
  forge links, to annotate, and to categorize all
  of the objects in their daily life
• CALO Applications
• CALOs learning capabilities avail opportunities
  for creation and maintenance of links in the IRIS
  knowledgebase

22
Linking Problem Statement

• Linking is a bitch

23
Linking Requirements

• Given that links are formed with URIs, linking
  requires a RESTfull architecture
• A RESTful architecture may not be appropriate to
  other classes of inter and intra application
  functionality (see the Automation FRD)
• Other applications may use the RESTfull
  implementation, but should not be restricted to
  it.

24
Current Linking Implementation

• In IRIS 1.0, virtually all user-initiated linking
  has been wired into ContextManagementApp
• Applications, e.g. email, calendar, etc., publish
  the results of user selection of objects in the
  IRIS GUI
• Users select relation types or categories, or
  they select other actions, e.g. annotate
• ContextManagementApp combines these selections
  and performs the necessary actions

25
Roadmap

• 1.3 Near term
• Parallel
• Settle the Ontology architecture
• Re-architect IRIS according to
• RadarNetworks needs
• Ontology architecture
• User interface needs (see HCI and User Interface
  FRDs)

26
Tasks

• Essentially covered in the Ontology Tasks