110 likes | 126 Views
Ontolog Open Ontology Repository Review. 19 February 2009. Agenda/Expectations. Inventory/Review of Existing Artifacts Identify Gaps Assumptions Architecture Principles Suggested Prioritization – Core Needs Draft Plan. Artifacts Inventory. OOR Scope Definition Goals (Expectations)
E N D
OntologOpen Ontology RepositoryReview 19 February 2009
Agenda/Expectations • Inventory/Review of Existing Artifacts • Identify Gaps • Assumptions • Architecture Principles • Suggested Prioritization – Core Needs • Draft Plan
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
Gap Analysis • Incomplete Use Cases • No Requirements Analysis & Decomposition • No (complete) Architecture or Artifacts • No Action Plan
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
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.
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
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
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
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
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??