ppy/oor-call_chat-transcript_edited_20111011b.txt


Welcome to the

= OpenOntologyRepository: Architecture & API Workshop-VIII - Tue 2011_10_11 =

Session co-Chairs: KenBaclawski & ToddSchneider 

see session page at: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2011_10_11 

.

= Proceedings: ==

.

ToddSchneider: Here's where we are at, in terms of consensus arrived at from the previous "OOR Architecture and API" workshops:

    0) The interface for searching ontology metadata will consist of a single method
    0.a) The method will have a single parameter consisting of a SPARQL query.    
    0.b) The return value of the method will be a SPARQL result set.
    0.c) Metadata will be represented using a named RDF graph.         
    0.d) Metadata will be based on an extension of OMV.    
         o The OMV extension may include a notion of domain specification or 
           topics, represented as text.   
    0.e) Metadata will be federated, so it is a single named RDF graph, no matter 
         how many OOR instances there are. pics, represented as text.   
    0.f) Metadata will be federated, so it is a single named RDF graph, no matter 
         how many OOR instances there are.
 
1) Each OOR instance must declare the representation language module it supports.   

2) Every OOR shall support RDFS 

3) Quality and Gatekeeping. We distinguish between gatekeeping and quality control.

   Definition: 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 do not ensure the quality of the ontologies.

   3.a) Gatekeeping will vet the metadata associated with an ontology to ensure
        entrance criteria are met.
   3.b) For each metadata attribute, it will be specified whether it is required 
        or optional.     
        
        3.b.i)   It MUST be specified whether the ontology is available (or to be
                 available in the future).  
        3.b.ii)  The ontology language MUST be specified.   
        3.b.iii) Other attributes will be handled offline by Michael Gruninger 
                 based on the OMV specification.   

   3.c) An ontology must satisfy other requirements depending on the ontology
        language.
    
   3.d) Syntax checking is always required and the responsibility of the language
        module

   3.e) Consistency checking is required with some time limit.

   3.f) Gatekeeping criteria will include an attribute to indicate whether the
        ontology exists or the metadata represents an advertisement. 

   3.g) The location of the actual ontology is the responsibility of Administration.   

   3.h) Metadata needs to include an attribute for the 'availability' of the ontology  

 
   3.i) 'Location' of the ontology must be provided.   
   
   3.j) The representation language of the ontology is a required attribute. 
   
   3.k) Michael will provide a preliminary list of required metadata attributes.  
   
   3.l) Submission process will be asynchronous

PeterYim: moving us forward ...

PeterYim: now that we have the partitioning (architecturally), we need to adopt a development platform (say, something like "eclipse"), and start having team members claim ownership to developing specific modules

KenBaclawski: Look at http://www.eclipse.org/stp/

ToddSchneider: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository_Architecture/Candidate03

PeterYim: also (important), please refer to the BioPortal "tab" implementation details - see: http://palexander.posterous.com/extending-bioportals-rails-ui

ToddSchneider: The 'administration' module is responsible for advertising which representation languages an instance supports.

PeterYim: All: we might want to partition some of the work to sizes that fit, say, work by a student in 3-months (which might mean work that takes an experienced developer a couple of weekends or a month to do)

ToddSchneider: The next Architecture meeting will focus on development platform and work partitioning

ToddSchneider: The next meeting will be on Tue 1 November 2011, same time 

ToddSchneider: Homework: learn more about the Eclipse and its capabilities; Read Paul Alexander's page on tabs (URL posted by Peter above).

PeterYim: we'll make that (choice of platform and work partitioning) as the main focus of our next team meeting (Tue 2011.11.01)

ToddSchneider: We need to motivate contributors to provide 'comic' book level descriptions of their work

PeterYim: -- session ended 9:38am --