OpenOntologyRepository: Architecture & API Workshop-VII - Tue 2011_09_20    (2WIU)

Topic: "OOR Architecture & API Specification Development Workshop-VII"    (2WIV)

Session Chair: KenBaclawski & ToddSchneider    (2WQD)

Conference Call Details:    (2X1A)

Attendees    (2WQE)

Agenda Ideas:    (2WQP)

please insert any additional items below (along with your name for follow-up purposes)    (2WQQ)

Abstract:    (2WQW)

As a result of the two OOR Architecture and API panel sessions back in Oct & Nov-2010, we have been exposed to a large number of architecture and API candidates for ontology repositories. We have had requirements for the OOR, at least in broad outline form, since the Ontology Summit 2008. We have been running an OOR sandbox based on BioPortal. Most recently, we have forked from the BioPortal code base with the intention of proceeding separately with the development of a reference implementation.    (2WQX)

At this series of meetings, we are going through the process of producing the actual OOR specification. It will be run as a workshop where the straw man proposal will be discussed and modified as needed.    (2WQY)

The various architectures and APIs for ontology repositories presented for consideration are available at OpenOntologyRepository_Architecture    (2WQZ)

Here is the straw man architecture: OpenOntologyRepository_Architecture/Candidate03    (2WR0)

In addition, there is an API of the core services that was obtained from BioPortal, which is not entirely compatible with the straw man architecture, but furnishes a starting point. This API will also be discussed and modified as needed.    (2WR1)

Here is the API expressed in WSDL:    (2WR2)

Here is the API expressed in Java:    (2WR3)

Finally, we need to agree on a plan for completing the development of the specification.    (2WR4)

Here is the proposed organizing plan: OpenOntologyRepository_Architecture/GettingOrganized    (2WR5)

We encourage all participants to update your candidate contributions to ensure your ideas are known and understood.    (2WR6)

The following are relevant prior meetings:    (2WR7)

Agenda & Proceedings    (2WRI)

Archives:    (2XCW)

1. Meeting called to order:    (2WRJ)

2. Roll Call & Adoption of last meeting's minutes:    (2WRN)

3. Key items for review and discussion today:    (2WRR)

... items below are mostly from the previous workshop, and will be updated as this session progresses.    (2WRX)

 --- Chat transcript begin: ---    (2XC9)
 PeterYim: Welcome to the    (2XCA)
 = OpenOntologyRepository: Architecture & API Workshop-VII - Tue 2011_09_20 =    (2XCB)
 Topic: "OOR Architecture & API Specification Development Workshop-VII"    (2XCC)
 Session Co-chairs: KenBaclawski & ToddSchneider    (2XCD)
 Session page:    (2XCE)
 == Proceedings: ==
 .    (2XCF)
 ToddSchneider: Ken, I was able to login.    (2XCG)
 KenBaclawski: Tejas set up a VMWare on a machine in my office at NEU. I can give access to anyone 
               who needs it. The main machine is, and the domains we can use are 
      and    (2XCH)
 PeterYim: please use this page to capture customization details -    (2XCI)
 KenBaclawski: The static IP address of is  The one for is    (2XCJ)
 ToddSchneider: where are we with the discussion ... ref.    (2XCK)
  = The interface for searching ontology metadata will consist of a single method:    (2SSS)
    * The method will be called find.    (2SST)
    * The method will have a single parameter consisting of a SPARQL query.    (2SSU)
    * The return value of the method will be a SPARQL result set.    (2SSV)
    * Metadata will be represented using a named RDF graph.    (2SSW)
    * The metadata RDF graph will use the following name:    (2SSX)
    * Metadata will be based on an extension of OMV.    (2SSY)
          o The OMV extension may include a notion of domain specification or topics, represented as text.    (2SSZ)
    * Metadata will be federated, so it is a single named RDF graph, no matter how many OOR instances there are.    (2XCL)
 ToddSchneider: also ref.
          o Quality and Gatekeeping. We distinguish between gatekeeping and quality control. 
            Gatekeeping criteria are a set of minimal requirements that any ontology within 
            the OOR has to meet. The latter are intended to enable the users of the OOR to 
            find quickly ontologies that fit their needs; the criteria are not supposed to 
            ensure the quality of the ontologies.    (2VB8)
          o Gatekeeping impacts metadata    (2VB9)
          o Gatekeeping will need to vet the metadata to ensure entrance criteria are met.    (2VBA)
          o Syntax checking is the responsibility of the language module.    (2VBB)
          o Each OOR instance must declare the representation languages    (2VBD)
          o Each OOR instance must declare the representation language module it spports.    (2VBE)
          o Will OOR Metadata be represented in OWL?    (2VBF)
          o Every OOR shall support RDF    (2VBG)
          o Correction: Every OOR shall support RDFS    (2VBI)
          o OMV is written in OWL    (2VBK) - From Chapter 5 of the OMV Report 2.4.1: As aforementioned, OMV is formalized as an OWL ontology.    (2VBO)
          o Gatekeeping criteria will include an attribute to indicate whether the ontology exists or the metadata represents an advertisement.    (2VBR)
          o The location of the actual ontology is the responsibility of Administration.    (2VBT)
          o Metadata needs to include an attribute for the 'availability' of the ontology    (2VBW)
          o 'Location' of the ontology must be provided.    (2VBX)
          o Representation language of the ontology is a required attribute.    (2VBY)
          o Michael will provide a preliminary list of required metadata attributes.    (2VBZ)
          o Submission process will be asynchronous    (2VC0)
          o Minimal language dependency submission is syntax validation    (2VC1)
          o Consistency checking, to some extent, will be required for submission    (2VC2)
          o Need an attribute to represent that it is consistent, which then will require 
            another field to identify the reasoner used to do the consistency checking    (2VC3)
          o Ken has already developed the gatekeeper module which should provide enough to specify it for OOR    (2VC4)
          o Ken's gatekeeper module already has a mechanism to configure the registration workflow for a community    (2VC5)    (2XCM)
 ToddSchneider: Gatekeeper - notification(), subscription(), register()?    (2XCN)
 ToddSchneider: subscription is for particular ontology and particular user    (2XCO)
 ToddSchneider: subscription - sends notices about events related to ontology    (2XCP)
 TerryLongstreth: Create ontology == prepare system for new ontology?    (2XCQ)
 ToddSchneider: registrar - creates the entry in the OOR; to do so the required metadata needs to be created    (2XCR)
 PeterYim: -- session ended: 9:41am PDT --    (2XCS)
 --- Chat transcript end: ---    (2XCT)

Consensus, Conclusions & Follow-up Actions:    (2WSC)

4. Any Other Business:    (2WSE)

5. Action items:    (2WSF)

6. Schedule Next Meeting & Adjourn:    (2WSG)

 notes taken by: PeterYim / 2011.09.20-9:41am PDT
 All participants, please review and edit to enhance accuracy and granularity of the documented proceedings.    (2WSK)

Resources    (2WSL)