1 Ontolog OOR-BioPortal Comparative Analysis Todd Schneider 15 October 2009

2 Agenda/Expectations Review of Preliminaries –Assumptions –Definitions Review of Core OOR Requirements Requirement/Capability Comparison Analysis Challenge

3 Ignorance Disclaimer The material in this presentation related to BioPortal is derived mostly BioPortal source code version tag 1016 and a bit from version tag 1018

4 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

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

6 Architecture Principles OOR shall support evolutionary development OOR shall support distributed instances OOR shall provide services decoupled from core repository functionality OOR shall have no hierarchical dependencies OOR shall be ontologically driven OOR shall be platform independent

7 Assumptions OOR Supports Evolutionary Development Partitioning of Functionality OOR instance data not stored apart from infrastructure data (e.g. polices, rules) Repository architecture (mostly) independent of knowledge representation language Initial support for OWL Meta/Provenance information ontology based Standards based to extent possible Not Near-Real Time Federatable

8 Core OOR Requirements Storing, Management, Governance of Ontologies & Related Items Discovery/Searching Ontologies Scalable (Parallelism, Federation) Multi-Language Support Arbitrary Knowledge Domain Platform Independent [Don’t impede storing of instance data]

9 BioPortal Assumptions –Knowledge Domain – Any (currently focused on Biology) –Interactions – Primarily Human –Support for REST Services –Not Near Real-Time

10 Persistence BioPortal –File –URL/URI –Database OOR –Memory –File –Database/TripleStore –Other

11 Content BioPortal Ontologies URIs/URLs Ontology Metadata Infrastructure Ontology Instances OOR Ontologies Ontology Metadata Rules Policies Infrastructure Ontology Instances

12 Knowledge Domains BioPortal Any – Focus on Biology OOR Any

13 Representation Languages BioPortal OWL –Lite –DL –Full OBO Protégé LexGrid_XML RRF OOR OWL –Lite –DL –Full RDF/RDFS Common Logic ??

14 Content-Ontology Services BioPortal Browsing Search Visualization Alert/Notification Subscription Mapping Ranking (rudimentary) OOR Browsing Search Visualization Syntax Validation Consistency Checking Modularization Editing Creation Mapping Alert/Notification Subscription Ranking

15 Management BioPortal Configuration Management Access Control OOR Content Configuration Management –Policy Based Access Control –Policy Based –Role Based Auditing –Access Repository Ontology –Logging Infrastructure Management –Process Status & Control –Policy Status, Control, Editing Policy Enforcement

16 Discovery BioPortal Language/Format Author Version Upload Date Status Category Group Term Free Text OOR Language Metadata Author Domain Application Usage Version Creation/Edit/Update Time Concept Relation Term Local/Global

17 Interfaces BioPortal Human –Web Machine –REST Services OOR Human –Web –Thick Client/GUI Machine –Web Services –REST Services –Platform Specific Services Federation

18 Content – Representation Implementations necessitate (meta) representation of content Should not be closely coupled with –Persistence mechanism –Search mechanisms –Ownership Should be related with –Discovery Related/coupled with –Representation Language –Knowledge Domain –Relations –Concepts –Terminology/vocabulary –Management Related/coupled with –Ownership –User IDs –Policy Enforcement –Governance Related/coupled with –Access Control –Policy Enforcement

19 Discovery/Search Should be symmetric among concepts and relations –Service::ConceptService – No similar service for relations Weak coupling with Ontology RIR Close coupling with Metadata –Bean::MetaDataFileBean OntologyBean –getContactName –getIsReviewed –getUserID –Service::OntologyService findAllOntologyVersionsByxxx() findOntology() findProperties() –Infrastructure – close coupling with Lucene Service::AbstractSearchService

20 Analysis - Recommendations OOR needs to be defined by well specified interfaces OOR interfaces need a platform independent expression –Avoids embedding development colloquialisms/paradigms OOR interfaces need to be partitioned by functionality –Simplifies understanding –Facilitates integration and extension Ideally, OOR interfaces derive from ontological representation of OOR

21 Analysis - Recommendations –Access Web (based) Client (based) Machine (based) Federation –Storage File – local, remote Database/Triplestore –Content Language Dependent Content Infrastructure Content –Management –Governance Content Services –Syntax Validation –Consistency Checking –Discovery Language Dependent Services Metadata Discovery Services Infrastructure Discovery Services –Management Management Services Enforcement –Governance License Validation Policy Services Notional Functionality/Namespace Partition

22 OOR Challenge Start Development of OOR Ontology