OpenOntologyRepository: "OOR-Ontohub-Gatekeeper API" Hackathon Session - Tue 2013_06_25    (3TND)

Session Topic: The "OOR-Ontohub-Gatekeeper API" Hackathon    (3TNE)

Session Co-chairs: TillMossakowski & KenBaclawski    (3TNF)

This is the first of a series of regular activities for the OOR team. The plan is to devote one meeting a month to intense coding (or other low level development) work.    (3UFM)

Conference Call Details:    (3UFN)

Attendees:    (3UGK)

Agenda Ideas    (3UH1)

Resources    (3UO1)

Agenda & Proceedings    (3UH9)

Archives:    (3UHA)

1. Meeting called to order:    (3UHF)

2. Roll Call:    (3UHK)

3. Key discussion:    (3UHN)

4. Prior Discussions:    (3UIZ)

4.1 Discussion: tactically, what shall we be doing differently in the next 6 to 12 months    (3UJ0)

4.2 Setting the metrics - what does "success" look like    (3UJ6)

4.3 Action planning for "content drive" (getting people to upload ontologies) ... (deferred discussion of this item)    (3UJ7)

5. IM Chat Transcript captured during the session:    (3UJZ)

 see raw transcript here.    (3UK0)
 (for better clarity, the version below is a re-organized and lightly edited chat-transcript.)
 Participants are welcome to make light edits to their own contributions as they see fit.    (3UK1)
 -- begin in-session chat-transcript --    (3UK2)
	------
	Chat transcript from room: oor_20130625
	2013-06-25 GMT-08:00 [PDT]
	------    (3US7)
	[07:01] PeterYim: Welcome to the    (3US8)
	 = OpenOntologyRepository: "OOR-Ontohub-Gatekeeper API" Hackathon Session - Tue 2013_06_25 =    (3US9)
	Session Topic: The "OOR-Ontohub-Gatekeeper API" Hackathon    (3TNE)    (3USA)
	Session Co-chairs: TillMossakowski & KenBaclawski    (3TNF)    (3USB)
	This is the first of a series of regular activities for the OOR team. The plan is to devote one meeting 
        a month to intense coding (or other low level development) work.    (3USC)
	Session page: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2013_06_25    (3USD)
	Attendees: TillMossakowski (co-chair), KenBaclawski (co-chair), BobSmith, OliverKutz, PeterYim, ToddSchneider.    (3USE)
	 == Proceedings ==    (3USF)
	[07:11] KenBaclawski: please point your browsers to the Ontohub-OOR API working document (google-doc) 
        - at: http://tinyurl.com/onto-arch    (3USG)
	[07:19] TillMossakowski: We do not require the API to be minimal, but a minimal set of methods shall be identified.
        Derived methods can be implemented in terms of the minimal set; a reference implementation will show how to do this.    (3USH)
	[07:20] TillMossakowski: We will include also the methods from BioPortal not being in the OORService API    (3USI)
	[07:21] TillMossakowski: The API should not be specific to any kind of ontology framework.    (3USJ)
	[07:26] TillMossakowski: the method delivering all ontology latest version is take from 
        the BioPortal API: http://www.bioontology.org/wiki/index.php/BioPortal_REST_services    (3USK)
	[7:31] TillMossakowski: Ken: what about "latest draft version" vs. "latest released version"?    (3USL)
	[7:34] KenBaclawski: The API should incorporate the branching of a software repository service such as git.    (3USM)
	[7:35] TillMossakowski: we should incorporate some aspects of the git API, involving repositories and branches    (3USN)
	[7:36] TillMossakowski: Peter: ontologies provide a richer structure (classes, attributes, modules) than 
        files in a file system    (3USO)
	[7:42] KenBaclawski: Each ontology has a URI and it follows linked data principles.    (3USP)
	[7:45] PeterYim: ref. consensus from our Jun-18 OOR-Strategy meeting - we will focused on developing 
        three things (hopefully within the next 3 months): the set of metadata, the API, and some shared thoughts 
        on the UI - see: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2013_06_18#nid3UE6    (3USQ)
	[7:56] KenBaclawski: The method for retrieving symbols and sentences should have a filter parameter.    (3USR)
	[7:56] TillMossakowski:
	 <Ontology name="FamilyBase" logic="OWL2" refname="FamilyBase" relxpath="/">
	    <Declarations>
	      <Symbol kind="Class" name="Father">Class Father</Symbol>
	      <Symbol kind="Class" name="Female">Class Female</Symbol>
	      <Symbol kind="Class" name="Grandmother">Class Grandmother</Symbol>
	      <Symbol kind="Class" name="Hybrid">Class Hybrid</Symbol>
	      <Symbol kind="Class" name="Man">Class Man</Symbol>
	      <Symbol kind="Class" name="Married">Class Married</Symbol>
	      <Symbol kind="Class" name="MarriedMother">Class MarriedMother</Symbol>
	      <Symbol kind="Class" name="Mother">Class Mother</Symbol>
	      <Symbol kind="Class" name="MotherWithManyChildren>Class MotherWithManyChildren</Symbol>
	      <Symbol kind="Class" name="MotherWithoutDaughter>Class MotherWithoutDaughter</Symbol>
	      <Symbol kind="Class" name="Parent>Class Parent</Symbol>
	      <Symbol kind="Class" name="Person>Class Person</Symbol>
	      <Symbol kind="Class" name="Wife>Class Wife</Symbol>
	      <Symbol kind="Class" name="Woman>Class Woman</Symbol>
	      <Symbol kind="ObjectProperty" name="hasChild>ObjectProperty hasChild</Symbol>
	      <Symbol kind="ObjectProperty" name="hasHusband>ObjectProperty hasHusband</Symbol>
	      <Symbol kind="ObjectProperty" name="hasParent>ObjectProperty hasParent</Symbol>
	      <Symbol kind="Individual" name="clara>NamedIndividual clara</Symbol>
	      <Symbol kind="Individual" name="john>NamedIndividual john</Symbol>
	      <Symbol kind="Individual" name="mary>NamedIndividual mary</Symbol>
	    </Declarations>
	    <Axioms>
	   <Axiom>Class: Person</Axiom>
	      <Axiom>Class: Female</Axiom>
	      <Axiom>Class: Woman
	       EquivalentTo: Person and Female</Axiom>
	      <Axiom>Class: Man
	       EquivalentTo: Person and not Woman</Axiom>
	      <Axiom>ObjectProperty: hasParent</Axiom>
	      <Axiom>ObjectProperty: hasChild
	                InverseOf: hasParent</Axiom>
	      <Axiom>ObjectProperty: hasHusband</Axiom>
	      <Axiom>Class: Mother
	       EquivalentTo: Woman and hasChild some Person</Axiom>
	      <Axiom>Class: Father
	       EquivalentTo: Man and hasChild some Person</Axiom>
	      <Axiom>Class: Parent
	       EquivalentTo: Father or Mother</Axiom>
	      <Axiom>Class: Grandmother
	       EquivalentTo: Mother and hasChild some Parent</Axiom>
	      <Axiom>Class: MotherWithManyChildren
	       EquivalentTo: Mother and hasChild min 3 Thing</Axiom>
	      <Axiom>Class: MotherWithoutDaughter
	       EquivalentTo: Mother and hasChild only (not Woman)</Axiom>
	      <Axiom>Class: Wife
	       EquivalentTo: Woman and hasHusband some Man</Axiom>
	      <Axiom>Class: Married</Axiom>
	      <Axiom>Class: MarriedMother
	       EquivalentTo: Mother and Married</Axiom>
	      <Axiom>Class: MarriedMother
	       SubClassOf: Female and Person</Axiom>
	      <Axiom>Class: Hybrid
	       EquivalentTo: Woman and Man</Axiom>
	      <Axiom>Individual: mary
	            Types: Mother</Axiom>
	      <Axiom>Individual: mary
	            Facts: hasChild john</Axiom>
	      <Axiom>Individual: john
	            Types: Father</Axiom>
	      <Axiom>Individual: john
	            Facts: hasChild clara</Axiom>
	      <Axiom>Individual: clara</Axiom>
	    </Axioms>
	  </Ontology>    (3USS)
	[8:02] TillMossakowski: We want to have one single method for retrieval, with a lot of parameters for 
        controlling what is selected/filtered    (3UST)
	[8:07] KenBaclawski: There should be a minimum collection of metrics that every repository instance should provide.    (3USU)
	[8:07] TillMossakowski: metadata includes stored metadata, as well as computed metadata (like metrics)    (3USV)
	[8:09] ToddSchneider: The parameters for controlling what is selected/filtered will need to be tied 
        to 'metadata' maintained by the repository (hence available for individuation).    (3USW)
	[8:10] ToddSchneider: I thought we had considered using the 'metadata' as a template (via XSLT or 
        a similar translation) for filtering.    (3USX)
	[8:11] ToddSchneider: Each parameter in the metadata becomes a possible 'filter'.    (3USY)
	[8:12] TillMossakowski: OMG IDL 3.5 (tmp link): http://www.informatik.uni-bremen.de/~till/OMG-IDL-3.5-ptc-13-02-02.pdf    (3USZ)
	[8:20] KenBaclawski: The consensus is to formalize the API in IDL 3.5.    (3UT0)
	[8:28] KenBaclawski: Ken will formalize the gatekeeper in IDL.    (3UT1)
	[8:29] ToddSchneider: I really have to go. Cheers.    (3UT2)
	[8:31] KenBaclawski: Next hackathon session is on July 16 at the same time, same topic.  Till and Ken will be providing their IDL documents.    (3UT3)
	[8:32] KenBaclawski: Meeting is adjourned.    (3UT4)
	[8:32] vnc2: very productive session!    (3UT5)
	[8:32] PeterYim: -- session ended: 8:32am PDT --    (3UT6)
 -- end in-session chat-transcript --    (3UK3)

6. Action items:    (3UK4)

7. Any Other Business: ... (deferred to the next meeting)    (3UK6)

8. Schedule Next Meeting & Adjourn:    (3UK9)

 --
 notes taken by: PeterYim / 2013.06.25-6:29pm PDT
 All participants, please review and edit to enhance accuracy and granularity of the documented proceedings.    (3UKF)

Resources    (3UKG)