1

OntologOntologOpen Ontology RepositoryOpen Ontology RepositoryReviewReview

19 February 2009

2

Agenda/Expectations

• Inventory/Review of Existing Artifacts

• Identify Gaps

• Assumptions

• Architecture Principles

• Suggested Prioritization – Core Needs

• Draft Plan

3

Artifacts Inventory

• OOR Scope• Definition• Goals (Expectations)• OntologySummit2008 Communiqué: Towards an

Open Ontology Repository• Requirements• Use Cases• Architecture Principles• Prototype • OOR "sandbox" based on the NCBO BioPortal

4

Gap Analysis

• Incomplete Use Cases

• No Requirements Analysis & Decomposition

• No (complete) Architecture or Artifacts

• No Action Plan

5

Definitions

Repository (WordNet)

• A facility where things can be deposited for storage or safekeeping

Ontology Repository (Ontolog)

• An ontology repository is a facility where ontologies and related information artifacts can be stored, retrieved and managed

6

Goals

Provide an architecture and an infrastructure that supports

• Creation, sharing, searching, and governance/management of ontologies, and

• Linkage to database and XML Schema structured data and documents.

Complementary goals• Fostering the Semantic Web community • Identification and promotion of best practices • Provision of services relevant to the RDFS and OWL

ontologies and RDF instance stores.

7

Assumptions

• OOR Supports Evolutionary Development• Partitioning of Functionality• OOR does not store instance data apart from

that of the OOR infrastructure (not resolved)• OOR Supports arbitrary representation

languages– Repository architecture (mostly) independent of

language– Initial support for OWL

• Meta/Provenance information crucial• Standards based to extent possible

8

Architecture Principles

• OOR shall support evolutionary development • OOR shall support distributed instances• OOR shall be scalable• OOR shall support federation• OOR shall provide services decoupled from core

repository functionality• OOR shall have no hierarchical dependencies• OOR shall support arbitrary ontology representation

languages• OOR shall be ontologically driven• OOR shall be platform independent

9

Q&D Decomposition - Core• Storage

– Ontologies– Meta/Provenance data– Instance Data – ONLY that pertaining to OOR operations (not resolved)– Basic DB operations (read, write, delete): – ‘Put’ & ‘Get’ Returns entire ‘ontology’ or metadata

• Discovery/Search– Via Metadata

• Management – Access Control / Policies– Versioning and audit/access trail– Governance

• Submission – metadata completion; syntax checking

• Metadata – Levels 0 – 5 (similar to maturity levels)– Supports discovery/search, governance, management

10

Goals of Metadata

• Metadata should support    – Provenance information

• Author, author credentials • Institutional/Organizational affiliation or support• Source of ontology reference material   • Ontology design rationale

– Determination of suitability for a user purpose – Retrieval of ontologies by domain or application

 – Ontology Integration and mapping– Dependencies  

11

Plan – What’s Necessary?

• Core Repository– Specify core/minimal functionality

• Specify core search functionality• Specify core ‘put’ and ‘get’ operations• Applicable to both ontologies and ontology metadata (i.e. symmetry).

– Specify initial meta/provenance data– Continue use case, requirements, architecture development

• Preliminary Services– Syntax validation– Policy enforcement – Governance, Metadata, ???

• Extended Services

• Roadmap – What’s next??