OpenOntologyRepository Architecture/Candidate01

OpenOntologyRepository_Architecture - Candidate01    (184Z)

Started by: FarrukhNajmi/2008.01.28    (1850)

Architecture of a Single OOR Node    (189Y)

The following are some key aspects of the architecture (need to create a picture)    (1A4R)

• The centeral component of the architecture is a single OOR Server node    (1A4S)
• The server is capable of storing Ontological content at the granularity of Classes, Individual and Properties    (1A4T)
• The server supports abstract service interfaces for Publish and Discovery of stored ontological artifacts    (1A4U)
• The server exposes concrete service endpoints for its abstract services over HTTP/S    (1A4V)
  • The concrete service endpoints have a SOAP binding for Publish endpoint    (1A4W)
  • The concrete service endpoints have a SOAP and REST binding for Discovery endpoint    (1A4X)
• The server provides a Service Provider Interface (SPI) to plug in an external reasoning engine    (1A4Y)
• The server is accessible via a Graphical User Interface (GUI) specifically designed for OOR use cases    (1A4Z)
  • The GUI is accessible over the web and supports secure access to the server over HTTP/S    (1A50)
• A Java Client API is available to rapidly develop OOR clients in the Java programming language    (1A55)

Federated Architectecture    (18A0)

• The OOR will support a federated architecture    (18A1)
• Multiple OOR instances may belong to a federation    (18A2)
• Membership of an OOR in a Federation is driven by shared interest    (18A3)
• A federation typically maps to a community of interest which is often a vertically specialized domain (e.g. Healthcare, Ocean Science, Automotive, Telco etc.)    (18A4)
• During development Ontological content may be authored and stored in a local OOR instance    (18A5)
• Finished Ontological content may be promoted / deployed to a shared community repo. This process should have human review and approval process    (18A6)
• Changes to shared community repo are notified to interested subscribers (other authors)    (18A7)
• Local repos may synchronize with communtiy repo and community repo may synchronize with root repo periodically    (18A8)
• Root repo will not have replica of all community repos. It will only have the ontological content that is common to more than one community. It will also have a catalog of community repos and what they have to offer.    (18A9)
• There will be a process to request that certain ontological content be promoted / deployed to root repo if it seems valuable to more than one community.    (18AA)
• There will be a broader and tighter governance process at the root repo and will likely have reviewers from multipel communities    (18AB)

[[image: Distrubuted Ontology Repository Architecture]]    (189X)

• Comment by RaviSharma / 2008.02.06    (192Y)
  • I like what I see proposed by FarrukhNajmi.    (19IF)
  • Federated can also imply peer or equal access authority - peer type of organizations sharing access to the repository. Distributed repository example can be more general if FarrukhNajmi could kindly modify the diagram (visual) to include at least one place where the author can write to more than one local repository - this would imply distributed repository for a given ontology and not necessarily all local only, some could be remote.    (1930)
  • Could we get more visuals for conceptual architectures that are implementation oriented with known IT elements and also showing Gaps that exist for repository architecture to be completed, at least for simply authenticated open repositories?    (192Z)