90 likes | 107 Views
This presentation discusses a modular software architecture for the Open Ontology Repository (OOR), emphasizing federation, collaborative editing sites, and support for various languages and policies. It also highlights the initial implementation and future plans for the project.
E N D
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
OOR Project • OOR software development is now hosted as aproject on the SemWebCentral.org GForge site • http://projects.semwebcentral.org/projects/oor/ • Register for an account using New Account and send email to mdean@bbn.com to be added
Initial implementation • Java interfaces (incomplete) and stub implementations • Generated Javadoc presented at http://ontolog.cim3.net/file/work/OOR/OOR-prototype--MikeDean_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.semwebcentral.org/
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, hasFather, owns, … • Each language defines its own TermTypes • 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 BioPortal, 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 CIM3)