[Top] [All Lists]

[oor-forum] Thoughts on OOR architecture possibilities

To: OpenOntologyRepository-discussion <oor-forum@xxxxxxxxxxxxxxxx>
From: Evan Wallace <ewallace@xxxxxxxxxxxx>
Date: Thu, 17 Apr 2008 15:51:19 -0400
Message-id: <4807AA37.4080609@xxxxxxxxxxxx>

I have seen little discussion exploring architectures for an OOR.  
Perhaps this
is because the requirements are still in flux.  Still, I think we can 
safely make
some assumptions about minimum requirements and start exploring options.
The remainder of this email does just this.    (01)

***************************************************************    (02)

    Open Ontology Repository Architecture possibilities    (03)

  Bare minimum requirements:    (04)

  1) Need to support ontologies in at least OWL and Common Logic (CL).
  2) Need to provide means for users to Discover content via browsing
    and query of exposed elements of the content and metadata related to
    that content.
  3) Need to serve content reliably in an appropriate standard exchange 
    and using protocols associated with each content type.
  4) Need to provide persistent and available access to this content
    and associated metadata for multiple versions as the content evolves.    (05)

  I would characterize requirements 1 and 2 as requirements on a
  Registry functionality and 3 and 4 as requirements on a Repository
  functionality of an OOR.    (06)

  Below I discuss some possible architectures for an OOR to meet these
  requirements.  I am somewhat familiar with ebXML RegRep and XMDR, so
  below are some architectures for repositories that would use these
  specifications.  There may well be other, as good or better,
  alternatives.  If there are, people should decribe them as well, so
  that we can flesh out all the alternatives and compare them.    (07)

  Some possible OOR architectures:    (08)

  A) Reuse and extend OMV infrastructure to add CL specific
    enhancements.  OMV already provides rich support for the above
    needs (not sure about version management) for OWL based content.
    This is built on an ebXML based RegistryRepository.    (09)

  B) Create a MOF (Meta Object Facility) profile for ebXML RegRep and
    then use metamodels defined in the OMG Ontology Management Metamodel
    (ODM) to store content. 
     Would need to:
     - define models for related metadata (use and extend OMV?) which
       would work across supported content metamodels,
     - find or develop software to convert between MOF and exchange
     - build query/browse front-end that works with content and metadata,    (010)

  C) Use an XMDR repository. 
     Not sure what is needed to extend the infrastructure for XMDR (as
     described in Bruce's slides [1]) to meet the above requirements. 
     XMDR should be able to support a range of forms for conceptual
     models including CL and OWL, but with OWL and RDF tools sprinkled
     around the diagram on slide 16, I am not sure if all functions
     would work on all formats.  Clearly the MDR pedigree should mean
     excellent support for some kinds of metadata at both the model
     and model element level.  But some extensions will be required to
     support language specific notions like Description Logic expressivity.    (011)

  D) Use multiple distinct infrastructures supporting different
     formats which would then be federated to appear as a single
     repository via one of any of number of mechanisms (redirection,
     front-ending by a single system, front-ending by a federation of
     systems each of which wrap specialized systems).    (012)

  We probably should create a set of questions to ask about each
  OOR alternative architecture, the answers to which could be used to
  evaluate the alternatives.    (013)

  BTW - I don't think that the OWL Lite profile for ebXML RegRep should
  be used for OOR.  The profile provides both more and less than what we
  need even for managing OWL-only content and doesn't address any FOL
  content forms.    (014)

  BTW2 - There was some email discussion about exploiting the
  relationship of OWL as isomorphic with a fragment of First Order Logic
  to simplify some part of this infrastructure, say the Repository, by
  supporting only a FOL form (such as CL).  This could work, but I am
  not sure that it buys you much.  Most users and tools for OWL ontologies
  will want to browse, refer to, and import OWL forms so we will have to
  provide interfaces and export forms in OWL anyway.  But we will have
  created the task of defining the fragment and dealing with new 
  issues that the transformations between OWL and this fragment will create.
  Also, will not the difference in semantics between OWL DL and OWL Full 
  complicate this approach?    (015)

-Evan    (016)

Evan K. Wallace
Manufacturing Systems Integration Division
NIST    (017)

http://ontolog.cim3.net/file/work/OpenOntologyRepository/2008-02-28_Ontology-Repository-Landscape/XMDR-input-to-Open-Ontology-Registry_v2--BruceBargmeyer_20080228.pdf    (018)

Message Archives: http://ontolog.cim3.net/forum/oor-forum/  
Subscribe: mailto:oor-forum-join@xxxxxxxxxxxxxxxx 
Config/Unsubscribe: http://ontolog.cim3.net/mailman/listinfo/oor-forum/  
Shared Files: http://ontolog.cim3.net/file/work/OOR/ 
Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository     (019)
<Prev in Thread] Current Thread [Next in Thread>