Presentation on theme: "1 Ontolog Open Ontology Repository Review 19 February 2009."— Presentation transcript:
1 Ontolog Open Ontology Repository Review 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 RepositoryOntologySummit2008 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 – Whats 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 – Whats next??
Your consent to our cookies if you continue to use this website.