1 / 22

Ontolog OOR-BioPortal Comparative Analysis

Ontolog OOR-BioPortal Comparative Analysis. Todd Schneider 15 October 2009. Agenda/Expectations. Review of Preliminaries Assumptions Definitions Review of Core OOR Requirements Requirement/Capability Comparison Analysis Challenge. Ignorance Disclaimer.

emmanuel-hale
Download Presentation

Ontolog OOR-BioPortal Comparative Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. OntologOOR-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 OOR • Memory • File • Database/TripleStore • Other BioPortal • File • URL/URI • Database

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

  12. Knowledge Domains OOR • Any BioPortal • Any – Focus on Biology

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

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

  15. Management 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 BioPortal • Configuration Management • Access Control

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

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

  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 Notional Functionality/Namespace Partition • 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

  22. OOR Challenge Start Development of OOR Ontology

More Related