Actions

Ontolog Forum

Revision as of 07:31, 9 January 2016 by imported>KennethBaclawski (Fix PurpleMediaWiki references)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

OpenOntologyRepository: Architecture & API Workshop-VI - Fri 2011_06_17

Topic: "OOR Architecture & API Specification Development Workshop-VI"

Session Co-chairs: Ken Baclawski & Todd Schneider

Conference Call Details

  • Date: Friday, 17-Jun-2011
  • Start Time: 9:00pm EDT / 6:00am PDT / 3:00pm CEST / 2:00pm BST / 13:00 UTC
  • Expected Call Duration: 1.0~1.5 hours
  • Dial-in Number:
    • from a US telephone (US): +1-218-844-8060 (domestic long distance cost will apply)
    • When calling in from a phone, use Conference ID: "4389979#"
    • from Europe, call:
      • Austria 0820-4000-1577
      • Belgium 070-35-9992
      • France 0826-100-280
      • Germany 01805-00-7642
      • Ireland 0818-270-037
      • Italy 848-390-179
      • Spain 0902-886-056
      • Switzerland 0848-560-327
      • UK 0844-581-9148
    • callers from other countries please dial into either one of the US or European numbers
  • RSVP to peter.yim@cim3.com appreciated, ... or simply just by adding yourself to the "Expected Attendee" list below (if you are a member of the team.)
  • Please note that this session may be recorded, and if so, the audio archive is expected to be made available as open content, along with the proceedings of the call to our community membership and the public at-large under our prevailing open IPR policy.

Attendees

  • Expecting:

Agenda Ideas

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

  • The specifications to be discussed at the these workshops are the following (not necessarily discussed in this order):
    • the OOR Architecture
    • the OOR API
    • the Organizing Plan
    • the default development platform

Abstract

As a result of the two OOR Architecture and API panel sessions, we have seen a large number of architectures and APIs 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.

The various architectures and APIs for ontology repositories are available at OpenOntologyRepository_Architecture

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.

Here is the straw man architecture: OpenOntologyRepository_Architecture/Candidate03

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.

Here is the API expressed in WSDL: http://www.ccs.neu.edu/home/kenb/oor/OORService.wsdl

Here is the API expressed in Java: http://www.ccs.neu.edu/home/kenb/oor/OORI.java

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

Here is the proposed organizing plan: OpenOntologyRepository_Architecture/GettingOrganized

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

The following are relevant prior meetings:

Agenda & Proceedings

1. Meeting called to order:

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

3. Key items for review and discussion today:

  • "OOR Architecture & API Specification Development Workshop-VI:" (Archives)
  • Gatekeeping specifies the 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.
    • Each OOR instance declares what ontology languages it supports.
    • Every OOR instance MUST support RDFS.
      • This is required because the metadata is expressed in OMV.
      • OMV is written in OWL, but it may be sufficient to require only RDFS. This needs to be investigated.
    • Other ontology languages MAY be supported.
    • For each metadata attribute, it will be specified whether it is required or optional.
      • It MUST be specified whether the ontology is available (or to be available in the future).
      • The ontology language MUST be specified.
      • Other attributes will be handled offline by Michael Grüninger based on the OMV specification.
    • An ontology must satisfy other requirements depending on the ontology language.
      • Syntax checking is always required.
      • Consistency checking is required with some time limit.
  • [ chat transcript of the session]
    • Todd Schneider: 4. 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.
    • Todd Schneider: Gatekeeping impacts metadata
    • Todd Schneider: Gatekeeping will need to vet the metadata to ensure entrance criteria are met.
    • Todd Schneider: Syntax checking is the responsibility of the language module.
    • Todd Schneider: Each
    • Todd Schneider: Each OOR instance must declare the representation languages
    • Todd Schneider: Each OOR instance must declare the representation language module it spports.
    • Todd Schneider: Will OOR Metadata be represented in OWL?
    • Todd Schneider: Every OOR shall support RDF
    • Tim Darr: I do not see why metadata would need to support OWL. RDF should be sufficient.
    • Todd Schneider: Correction: Every OOR shall support RDFs
    • Tim Darr: RDFS, I should say.
    • Todd Schneider: OMV is written in OWL
    • Tim Darr: I don't think that OMV really takes advantage of OWL features.
    • Todd Schneider: Tim, I don't know if Michael is reading the chat.
    • Tim Darr: OK, I have a bad connection and am just putting in my two cents.
    • Michael Grüninger: From Chapter 5 of the OMV Report 2.4.1: As aforementioned, OMV is formalized as an OWL ontology.
    • Tim Darr: sorry - i just lost my connection. will call back
    • Tim Darr: Let me ask my question here (cell phone connection is bad).
    • Todd Schneider: Gatekeeping criteria will include an attribute to indicate whether the ontology exists or the metadata represents an advertisement.
    • Tim Darr: Are we assuming that the ontology (files) will be physically present in the repo, or can the repo contain the URL of the ontology that a user can use to access the ontology?
    • Todd Schneider: The location of the actual ontology is the responsibility of Administration.
    • Tim Darr: Thanks! I am back on the call, but cell phone signal is not good.
    • Tim Darr: Gone again ...
    • Todd Schneider: Metadata needs to include an attribute for the 'availability' of the ontology
    • Todd Schneider: 'Location' of the ontology must be provided.
    • Todd Schneider: Representation language of the ontology is a required attribute.
    • Todd Schneider: Michael will provide a preliminary list of required metadata attributes.
    • Todd Schneider: Submission process will be asynchronous
    • Todd Schneider: Minimal language dependency submission is syntax validation
    • Todd Schneider: Consistency checking, to some extent, will be required for submission
    • Todd Schneider: 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
    • Todd Schneider: Ken has already developed the gatekeeper module which should provide enough to specify it for OOR
    • Todd Schneider: Ken's gatekeeper module already has a mechanism to configure the registration workflow for a community

3.0) Adopting (formally) the work from the last workshop, modulo any discussion/modifications entered on the wiki page.

3.1) Resolve / Finalize the first method proposed

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

Consensus, Conclusions & Follow-up Actions:

4. Any Other Business:

5. Action items:

6. Schedule Next Meeting & Adjourn:

  • Next Meeting:
    • Session on ISO 19763 with Elisa Kendall [chair: MichaelGruninger] to be scheduled
    • 2011_07_01 Friday: regular OOR Team meeting
    • 2011_07_08 Friday: Architecture & API Workshop-VII [co-chair: Ken Baclawski & ToddSchneider] ??
  • Call adjourned at: 7:00 am PDT

Resources