A Modular Software Architecture for OOR Mike Dean

Roadmap Summary • 1 public site + public/private instantiations – Emphasis on federation, including

OOR Project • OOR software development is now hosted as a�project on the Sem.

Initial implementation • Java interfaces (incomplete) and stub implementations • Generated Javadoc presented at

Module Hierarchy • Standard composable interfaces and (currently) stubbed example implementations • Each site

Abstraction • Try to incorporate as many options in modules, to maximize flexibility –

Event Model • Modules register handlers for lifecycle events • Handlers may preclude state

Terms • Generalization of things that can be searched for and maintained in OOR

Next Steps • Continue refinement of interfaces • Start on implementations – Encapsulate existing

Slides: 9

Download presentation

A Modular Software Architecture for OOR Mike Dean mdean@bbn. com OOR panel 22 August 2008

Roadmap Summary • 1 public site + public/private instantiations – Emphasis on federation, including loose ontologies and collaborative editing sites • Apache Server-like modular software architecture – Sites select languages, metadata, repository, IPR and other policies, governance, etc. they want to support • Initial support for OWL and Common Logic • Leverage and “cross reference” related efforts while seeking dedicated funding • More details in slides 55 -64 of Ontology Summit 2008 OOR Team Presentation 2

OOR Project • OOR software development is now hosted as a�project on the Sem. Web. Central. org GForge site • http: //projects. semwebce ntral. org/projects/oor/ • Register for an account using New Account and send email to mdean@bbn. com to be added 3

Initial implementation • Java interfaces (incomplete) and stub implementations • Generated Javadoc presented at http: //ontolog. cim 3. net/file/work/OORprototype--Mike. Dean_20080606/doc/ – Hasn’t yet evolved much past this point – Helpful feedback from Ravi Sharma and Carlos Rueda

Module Hierarchy • Standard composable interfaces and (currently) stubbed example implementations • Each site selects which modules they want to support • Each module supports its own configuration options • Developers can “vote with their code” • Code available at http: //oor. projects. semwebce ntral. org/ 5

Abstraction • Try to incorporate as many options in modules, to maximize flexibility – Metadata vocabulary (e. g. OMV) – was originally part of core – Lifecycle model • States: created/submitted, accepted, edited, deprecated, etc. • Transitions • Modules can specify dependencies on other modules (e. g. language-specific gatekeepers)

Event Model • Modules register handlers for lifecycle events • Handlers may preclude state transitions (e. g. gatekeepers) • Execution order based on module dependencies?

Terms • Generalization of things that can be searched for and maintained in OOR – Person, Event, has. Father, owns, … • Each language defines its own Term. Types – OWL classes, properties, individuals – Common Logic concepts, predicates, … – SKOS concepts, labels, schemes, collections�

Next Steps • Continue refinement of interfaces • Start on implementations – Encapsulate existing components, e. g. from Bio. Portal, XMDR, etc. – Develop federation interfaces to other repositories – (Both are main motivations for this panel) • Initial operating capability – Downloadable software – Public instantiation on openontologyrepository. net (infrastructure provided by CIM 3)