OpenOntologyRepository (OOR) Initiative - Use Cases

This page introduces some use cases for OOR.

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.

Use Case Diagrams

Use Cases which OOR will support

Ontology User

Name: Find Ontology

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:

Name: Browse a single Ontology

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.

Name: Add Comment for an Uncontrolled Review

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:

Name: Review an OOR Ontology

Name: Add Change Request

Ontology Designer

Name: Specify Axioms via Examples / DB's

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.

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.

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)

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.

Alternative Courses:

(a) OOR instance does not cover ontology designer's scope.

(b) Designer provides inconsistent models.

Postconditions:

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

Ref:

http://stl.mie.utoronto.ca/publications/design-repository.pdf

(Chapter 4) https://tspace.library.utoronto.ca/bitstream/1807/17512/1/Hashemi_Ali_200906_MASc_thesis.pdf

Name: Upload Ontology

Name: Update Ontology

Name: Create Mapping among existing ontologies

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.

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).

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)

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).

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.

Postconditions:

(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.

References:

For more on this, see chapter 5 of https://tspace.library.utoronto.ca/bitstream/1807/17512/1/Hashemi_Ali_200906_MASc_thesis.pdf. 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.

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.

Name: Download Ontology

Name: Correct Ontology Errors

Ontology Agent

• ...

Potential Ontologies for Use Cases from (early OOR adopters)

• Bio Caster ontology

• Woundontology

• see (also) use cases for MMI ontology repository (Google doc, currently under development).

Input & Comments

• "View" is misspelled. Katherine Goodier

• User Access Modes: Could describe various modes of accessing 1. a single local repository with one or more ontologies, 2. a single distributed and geospatially dispersed repository containing single or multiple repositories, 3. multiple distributed repositories owned by different owner organizations, 4. federated users from federated repositories. Some of these have been covered by Farrukh Najmi and Ravi Sharma and yet there is a need to make visual use cases for the same which are being considered by Community And also by RaviSharma.

• Repository access and functionality uses cases: In the categories above, the Browse capability and upload and update categories are already listed. Other modes could include for example 1. Browse only the Metadata about ontology, 2. Browse the Types of Ontology by any of selected metadata such as language, topic, domain or 3. By specific semantically meaningful "joins" or "Shared Concepts" for multiple ontologies 4. Use of external Ontology engines, search and inference engines and 5. External Tools from specific vendors or industry standard compliant solutions. 6. Developmental and production orientation for run time (say triples and SPARQL) considerations depicted as use cases, etc. RaviSharma.

• Comment from Ravi Sharma: from OMV Report 2.4 http://ontoware.org/frs/?group_id=39&release_id=404 we get an idea of the predefined ontologies and we need to analyze if our usecases are in congruence or are there any additional types.

5.2.1 Pre-defined ontology types. Individuals of the class OntologyType refer to well-known classifications for ontologies in the literature. Currently the OMV model resorts to a classification on the generality levels of the conceptualization [5, 16]:

• • upper level ontologies describing general, domain-independent concepts e.g. space, time.
  • core ontologies describing the most important concepts in a specific domain
  • domain ontology describing some domain of the world
  • task ontology describing generic types of tasks or activities e.g. selling, selecting.
  • application ontology describing some domain in an application-dependent manner The class can be extended to support additional classifications (e.g. the one in [9]).

• Include Use Case to Merge and Split selected ontologies for local requirements (with ability to escalate in ontology-governance for broader audience). Example: Have ontologies that correspond to Standard Occupational Code (SOC) jobs (or OPM Job Series or Military Specialties) and sub-ontologies for job tasks. The Job ontologies could be merged for non-standard job assignments, with some job tasks split out that do not apply. The same notion would apply to Standard Industry Codes (SIC) or NAICS codes, where ontologies of entire organizational or functional operations could be merged and split to fit individual organization requirements (as in Military Force Structure activities). This capability would have the benefit of increasing standardization and reuse of job skills for Human Capital management and development, and standardization and reuse of practices for organization development, effectiveness, and efficiencies. Perform the Merge and Split by linking the selected diverse ontologies to a subject-neutral integrating ontology. RoyERoebuck

References & Related Links

• Ontology repository use cases from ebXML RegRep Semantic Content Management work
  • Access to ebXML reference. This Reference requires OASIS membership as this is probably still a work in process and not yet a published standard? Comment from Ravi Sharma

• The eXtended Metadata Registry (XMDR) project (see xmdr.org) is concerned with the development of improved standards and technology for registering, linking, and retrieving the semantics of data elements, terminologies, and concept structures in metadata registries. Much of the work is directed toward developing proposals for the next edition of the ISO/IEC 11179 family of Metadata Registry standards. Uses of Extended Metadata Registries are suggested at: http://www.xmdr.org/overview.html. High-level, mid-level and some specific use cases are documented at: http://www.xmdr.org/use-cases.html. These use cases overlap with and extend other use cases identified on this wiki page.

• Use cases relating to OOR and Metadata Registries:

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:

• • a) the definition, specification and contents of metadata registries, including interchanging or referencing among various collections of data elements;
  • b) the design and specification of application-oriented data models, databases and message types for data interchange;
  • c) the actual use of data in communications and information processing systems;
  • d) interchange or reference among various collections of metadata;
  • e) the registration and management of semantic artifacts that are useful for data management, data administration, and data analysis;
  • f) the interrelation and mapping of concept systems with other concept systems, e.g., to support efforts to converge on consistency through harmonization and vetting ** activities;
  • g) the interrelation of concept systems with data held in relational databases, XML databases, knowledgebases, text, and possibly graph databases deriving from natural language text understanding systems;
  • h) the provision of services for semantic computing: Semantics Service Oriented Architecture, Semantic Grids, semantics based workflows, Semantic Web, etc.;
  • i) support for addressing semantic web considerations such as AAA (anyone can say anything about anything), non-unique names, and open world assumption;
  • j) the capture of semantics with more formal techniques (in addition to natural language) -- First Order Logic (e.g., Common Logic), Description Logics (such as OWL-DL);
  • k) support of Application Development and Maintenance;
  • l) support of data migration, data mediation;
  • m) support of portals, data marts, and data warehouses;
  • n) support of data grids and online transaction networks;
  • o) ontological reasoning with metadata;
  • p) ontology entry point for browsing and searching metadata registries;
  • q) capture of associations between the published identifiers used in the ontology(s), and the concepts registered in the registry;
  • r) support for Ontology-driven Data Translation;
  • s) support for data integration & data interoperation;