OpenOntologyRepository (OOR) Initiative - Use Cases    (189A)

This page introduces some use cases for OOR.    (1892)

A formal set of use case descriptions using the Use Case Description Ontology is available at OOR Use Cases. These use cases distinguish a hierarchy of user roles and allow for managing several kinds of items, such as ontologies, mappings, compositions of ontologies, etc.    (2D7H)

Use Case Diagrams    (1WVG)    (2D7I)    (1WVH)

Use Cases which OOR will support    (189B)

Ontology User    (1HXZ)

Name: Find Ontology    (1HY0)

  Goal: Finding an ontology to meet pre-defined needs.
  Summary: Describes how a user of ontologies may find one to meet their needs.
  Actors: Ontology User
  Preconditions: A registry of ontologies
  Triggers: Need for an ontology
  Basic Course: A user of ontologies has developed requirements for an ontology and wishes to determine if an ontology exists that meets a majority of their requirements. They logon to an ontology repository and start searching.

0) The user logs on to an OOR instance. 
1) The user navigates to a/the search page. 
2) The user selects the most relevant search fields (e.g. domain, subject, creator, etc.) from parameter list provided.
3) The user enters their search criteria.
3) The search returns a list of possible candidate matches. 

  Alternative Courses: The local OOR returns no results and promts the user to select federated OOR instances to search. 
  Post Conditions:    (1HY1)

Name: Browse a single Ontology    (1HY2)

Goal: Browse a single ontology of the users choice.
Summary: Describes how an interested party/user would find a ontology and view it.
Actors: OOR User
Preconditions: A instance of an OOR accessible to the user.
Triggers: User is interested in locating an ontology and inspecting it to ascertain its 'goodness'.
Basic Course: 
0) The user logs on to an OOR instance. 
1) The user navigates to a/the search page. 
2) The user enter their search criteria (e.g. domain, subject, selected terms). 
3) The search returns a list of possible candidate matches. 
4) The user browses through the list and finds a possible candidate and selects it for further detailed inspection. 
5) The OOR starts another browser tab with the selected ontology displayed for the user to view.
Alternative Courses: a) The search of the local OOR returns no results. b) The search of federated OOR instances returns no results.
Post Conditions: The user finds an ontology and downloads it.    (1IWY)

Name: Add Comment for an Uncontrolled Review    (1HY3)

Goal: Allow a user to comment or review an OOR ontology in an uncontrolled fashion.
Summary: Describes how an interested party/user would would add an uncontrolled review of an OOR ontology.
Actors: User
Preconditions: A instance of an OOR accessible to the user. An OOR ontology whose identity is known to the user.
Triggers: User is interested in add their review of an existing OOR ontology.
Basic Course: 
0) The user logs on to an OOR instance. 
1) The user navigates to a/the search page. 
2) The user enter the identity/identifier of the ontology upon which they wish to add a comment. 
3) The search returns the identified ontologies page. 
4) The user browses on the ontologies' page to the comment section. 
5) The user adds their comments.
6) The user hits the 'Save' button.
7) The comments are added to the list of comments for the identified ontology and associated with the user's logon identity. 
Alternative Courses: The identified ontology no longer resides on the OOR instance. b) The identified ontology does not permit uncontrolled comments.
Post Conditions:    (1IWZ)

Name: Review an OOR Ontology    (1IX0)

Name: Add Change Request    (1HY4)

Ontology Designer    (1HY5)

Name: Specify Axioms via Examples / DB's    (2DN1)

Motivation: I am what an ontologist / knowledge engineer would call a "domain specialist" or a "subject matter expert." I have extensive experience in my field and want to formalize my knowledge. I don't have the time nor desire to become an expert in logic, but I want to be able to express my work in a machine readable format that is shareable with others in my field and might possibly ease interface with those in fields peripherally related to mine. {nid 2DMW}
Goal: Provide a mechanism for a SME to formalize intuitions.
Summary: Using the inbuilt advantages afforded with a formal language at least as expressive as first order logic, we can communicate with the SME using examples (tarski-models) only, and navigate the repository to find the best set of axioms which correspond to their intuition. {nid 2DMY}
Actors: User + Axiom Generation Tool
Triggers: Desire for formal axioms
Preconditions: An OOR instance with at least First Order expressivity, organized by modules (i.e. COLORE) {nid 2DMX}
Base Course:
0) The user logs onto compliant OOR instance (i.e. COLORE)
1) The user names the relation(s) she wishes to formalize
2) User provides at least one example of their relation in "action" - essentially a Tarski style model. The model can be represented visually, or inputted as a plain text (see referenced papers for more on this).
3) Axiom Generation Tool searches the ontologies in the repository (COLORE) to find "Core-Hierarchies" and bounds in each hierarchy that match the user's intuition.
4) For each Core Hierarchy, tool presents a *representation* of a Tarski style model in the same representation that the user inputted.
5) The user decides if this example corresponds to their intuition.
6) Repeat 5-6 until search space exhausted
7) Present user with axioms for their intuition. {nid 2DMZ}

Alternative Courses:
(a) OOR instance does not cover ontology designer's scope.
(b) Designer provides inconsistent models.

(a) Designer has formal axioms relating to their domain, which correspond to combinations of modules selected from repository.

(Chapter 4)    (2DN0)

Name: Upload Ontology    (1HY6)

Name: Update Ontology    (1HY7)

Name: Create Mapping among existing ontologies    (1HY8)

Case A: Ontologies in Same Domain
Motivation: I am an organization who has developed an ontology and would like to interface said ontology with one developed by others. I need to determine what / how and where our ontologies overlap. This works for any number of ontologies, not just two. {nid 2DN2}

Goal: Given test mapping axioms, determine how two or more ontologies are "similar" and "different."
Summary: Create an image for each target ontology in the repository. Exploit repository structure to determine "similarity" and "difference." Again, this only works on a repository that satisfies the specs outlined in the reference below (i.e. COLORE). {nid 2DN4}
Actors: User + Semantic Mapping Tool
Triggers:  Interoperability
Preconditions: An instance of OOR with at least first order expressivity. Organized into modules and hierarchies (i.e. COLORE) {nid 2DN3}

Base Course:
0) User logs onto compliant OOR instance (i.e. COLORE)
1) User provides candidate mapping axioms. I.e. the user guesses that A is related to B, but is unsure how and to what extent, wants to see how A is in fact related to B. (This can also be automated...)
2) Tool generates an image of the user's target ontologies in OOR instance, given the mapping axioms
3) Analyzes images to determine "Similarity" and "Differences" in the target ontologies
4) Tool provides user with partial interpretations of the ontologies into one another and into compliant OOR instance (in some cases, tool performs automatic abduction). {nid 2DN5}

Alternative Course: No image is found in the repository (repository has limited coverage). New modules are proposed to be added to the repository. Trigger repository update usecase.

(a) User has relative, partial or weak interpretations among target ontologies, including those in repository. 
(b) New modules are proposed to be added to the repository. Process of identifying where they fit begins.

For more on this, see chapter 5 of The definition of "Similarity" and "Difference" in the thesis are a bit outdated. Updated version will be available in Hashemi & Gruninger "Using Modular Repositories for Semantic Mapping" 2010.    (2DN6)
Case B: Ontologies in Disparate Domains
Motivation: I want to know if knowledge developed in some other domain is useful for me. Can I reuse work done by others in a seemingly disparate field? Is there a way to get around the research silos and specialized jargons that have popped up? i.e. cell diffusivity and permeability being similar to electrical resistivity... Essentially, I want to discover 'conceptual or structural metaphors' that connect disparate domains to one another.

Goal: Support interdisciplinary knowledge sharing.
Actors: User + Semantic Mapping Tool
Triggers:  Knowledge Discovery
Preconditions: An instance of OOR with at least first order expressivity arranged by modules into hierarchies (i.e. COLORE)

Summary: Same as Use Case 2, except the target ontologies are from different domains. Again this exploits a basic advantage that the medium of logic affords us :P

Base Course:
see above use case.    (2DN7)

Name: Download Ontology    (1HY9)

Name: Correct Ontology Errors    (1HYA)

Ontology Agent    (1IKZ)

Potential Ontologies for Use Cases from (early OOR adopters):    (189D)

Input & Comments    (1KD7)

References & Related Links    (1895)

The following is a high-level list of potential use cases (and activities desirable to support) that come from ISO/IEC 11179. They may contribute to OOR use cases. An underlying notion is that it is useful to make links between ontologies and other forms of metadata. Thus, there is a need to register both ontologies (and other concept systems) and other metadata that describes data. High level use cases include:    (1WWF)