1 Ontolog OOR-BioPortal Comparative Analysis Todd Schneider 15 October 2009.
-
Upload
tamsyn-gibbs -
Category
Documents
-
view
218 -
download
0
Transcript of 1 Ontolog OOR-BioPortal Comparative Analysis Todd Schneider 15 October 2009.
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