1

OntologOntologOOR-BioPortal Comparative OOR-BioPortal Comparative AnalysisAnalysis

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

ManagementBioPortal• 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