OpenOntologyRepository: OOR Team Conference Call - Fri 2010-11-19    (2JLK)

Session Title: "(Post-BioPortal fork) OOR Architecture and API panel session - Take-II"    (2JS8)

Session Co-chairs: KenBaclawski (NEU) & MichaelGruninger (U of Toronto)    (2JS9)

Panelists:    (2JSA)

... Please refer also to the notes from the last regular meeting at: OOR/ConferenceCall 2010_10_01 and the three recent pertinent sessions:    (2JQK)

Archives:    (2JSG)

Conference Call Details:    (2JPC)

Attendees    (2JPZ)

Resources:    (2JT0)

Agenda & Proceedings    (2JQ8)

Session Topic: "Getting OOR Development Going - Take-IV"    (2JLN)

Abstracts:    (2JTK)

we have decided to organize a second panel session: "(Post-BioPortal fork) OOR Architecture and API - Take-II" to continue discussion on the (post-BioPortal fork) OOR Architecture and API, and explore more proposals and options. In particular, we want, especially, to hear from those who are planning to contribute code to OOR, but have not had a chance to present their work, and tell us what they plan to bring to the table, and have suggestions about the system architecture.    (2JTM)

Panel Member Talks:    (2JTN)

Abstract: ... Ken Baclawski's initial OOR decomposition is slightly revised and expanded to identify specific component interfaces.    (2JTQ)

ref. Proposed Domain Model - xml html    (2JTU)

Abstract: KReS is a RESTful infrastructure for managing ontology networks with pluggable KR components. In this briefing, I will provide an overview of KReS and answer questions people may have.    (2JTT)

Abstract: ... We propose an OOR architecture consisting of simple APIs, ontology repository implementations conforming to these APIs and a registry of these repositories. Together these components create an OOR network that can be used to build services utilizing content from different ontology repositories. The approach is based on an observation that there are different kinds of use cases, ontologies, ontology service providers, etc., and therefore it may not be possible to implement a single OOR server that addresses all possible needs. We suggest that the OOR initiative should focus on APIs and enabling an ecosystem of ontology repositories, not on doing everything by ourselves. Test suites and baseline implementations for APIs are needed for validating API implementations on different ontology repositories and testing the APIs.    (2JTX)

Abstract: ... The Open Ontology Repository provides repository services for a wide range of ontological resources. The OOR architecture should provide spaces for discussion, creation, maintenance, and collaboration on those resources. That will require general content management repositories and collaboration services. Two OASIS TC’s, namely Content Management Interoperability Services (CMIS) TC and OASIS Integrated Collaboration Object Model (ICOM) for Interoperable Collaboration Services TC, are defining standards to promote interoperability of content management repositories and collaboration services. CMIS v1.0 is an approved standard with an open source implementation provided by Apache Chemistry.    (2JU3)

ICOM is a framework for integrating a broad range of domain models for collaboration. ICOM adopts the CMIS domain model for Folder, Document, Version Control, and Relationship. ICOM complements the content management domain with Community, User, Group, Role (directory domain of LDAP), Space (team workspace), Category (taxonomy), and Tag. ICOM extends the content management domain to represent Unified Message, Calendar, Task List, Address Book, Blog, Wiki, Forum, Conference, Presence, Social Network, and other collaboration artifacts. ICOM TC members are editing a draft of that standard and incubating a Java Persistence API (JPA) prototype framework. The ICOM POJO classes are portable to any JPA provider. It is appropriate to release the POJO classes independently of the JPA prototype framework under an appropriate open source library license.    (2JUZ)

I will be providing an overview of the ICOM model and the JPA prototype framework to illustrate the value-add that ICOM can bring to the services of the Open Ontology Repository.    (2JV0)

Transcript of the online chat during the session:    (2JU4)

 see raw transcript here.    (2JU5)
 (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.    (2JU6)
    -- begin of chat session --    (2JU7)
	PeterYim: Welcome to the OpenOntologyRepository: OOR Team Conference Call - Fri 2010-11-19    (2JU8)
	Session Title: "(Post-BioPortal fork) OOR Architecture and API - Take-II"    (2JXP)
	Session Co-chairs: KenBaclawski (NEU) & MichaelGruninger (U of Toronto)    (2JXQ)
	Panelists:    (2JXR)
	* KenBaclawski (NEU) + ToddSchneider (Raytheon) * AldoGangemi + AlessandroAdamou (STLab, Rome) 
	* JouniTuominen + KimViljanen (Aalto U, Finland) * MathieuDaquin (NeOn, Open University, UK) * 
	EricChan (ICOM)    (2JXS)
	please refer to details on the session page at:    (2JXT)
	.    (2JXU)
	anonymous morphed into JouniTuominen    (2JXV)
	JouniTuominen: Peter: are you controlling the presentation slides in the shared vnc and the 
	presenter tells everyone (including you) to advance on slides, or how does it work?    (2JXW)
	PeterYim: yes ... just tell me when to advance slides ... and call out the slide number as well    (2JXX)
	JouniTuominen: Peter: ok, thanks    (2JXY)
	anonymous morphed into MichaelGruninger    (2JXZ)
	anonymous1 morphed into MyCoyne    (2JY0)
	KimViljanen: hello    (2JY1)
	MyCoyne: Where would I be able to obtain the presentation?    (2JY2)
	MyCoyne: Does anyone has a problem with audio: the speaker voice is very faint    (2JY3)
	PeterYim: I can hear them ok ... Ken seems to be fading in and out a bit, though    (2JY4)
	KimViljanen:    (2JY5)
	KimViljanen: LOOS (workshop in ESWC2009):    (2JY6)
	MyCoyne: Questions for LOOS: (1) does LOOS use any underline grid or enterprise service bus for its 
	registration? (2) Is there any API allows for merging of ontologies? (3) is LOOS available for 
	dowloading trials?    (2JY7)
	anonymous morphed into BartGajderowicz    (2JY8)
	PeterYim: very well thought through presentation, Jouni and Kim ... thank you!    (2JY9)
	KimViljanen: Peter: thanks for the positive feedback above    (2JYA)
	ToddSchneider: ONKI seems to provide more capabilities than envisioned by the OOR    (2JYB)
	KimViljanen: Todd: e.g.?    (2JYC)
	ToddSchneider: Annotation    (2JYD)
	KimViljanen: but the main question we wanted to present is: is the OOR application needed or the 
	APIs to connect existing ontology repositories?    (2JYE)
	KimViljanen: ok, so we are now planning the OOR Architecture (global) _and_ the Architechture of the 
	reference implementation    (2JYF)
	KenBaclawski: Yes, Kim, that is the idea.    (2JYG)
	ImmanuelNormann: @ONKIs: I like the openess in your proposal w.r.t. technical solutions like REST 
	vs. SOAP, different programming languages, etc. But I get the impression that you are committed to 
	OWL-ontologies only. How open are you w.r.t. to different ontology languages?    (2JYH)
	KimViljanen: Immanuel: our idea in LOOS was to support "simple" ontologies in the spirit of SKOS. 
	that is, we think there are common features shared among different ontology languages such as 
	concepts have labels    (2JYI)
	KimViljanen: Immanuel: and for example if the user is searching for "fish", the user can then 
	continue using the specific ontology repository for ontology specific functionalities, which may be 
	ontology language dependent, require inference etc    (2JYJ)
	ImmanuelNormann: as said before I like the openess w.r.t to technical means to implement an OOR. But 
	at some point we need to specify some service APIs - and finally we have to commit to some format to 
	define service APIs. One option would be WSDL. What is your opinion?    (2JYK)
	KimViljanen: I would support many: e.g. in ONKI we provide both a REST, Web Service and JavaScript 
	API --- the last two automatically created from the same java classes    (2JYL)
	KimViljanen: (which mean WSDL can be used describing the APIs)    (2JYM)
	MyCoyne: Is ICOM a licensed product from Oracle?    (2JYN)
	PeterYim: ICOM is an OASIS Technical Committee (TC) ... it is being developed as an open standard    (2JYO)
	MyCoyne: Thanks, Peter. This is very helpful.    (2JYP)
	ImmanuelNormann: @Kim: REST, SOAP, Java, JavaScript, ..., are rather specific language specific 
	solutions. I think it wouldn't make sense to specify e.g. one API in two or more languages. I was 
	rather thinking about programming language independent spec like e.g. IDL is used at W3C for 
	specifying the DOM model, or WSDL for web services or WADL for the REST world. So is WSDL your 
	favourite?    (2JYQ)
	KimViljanen: @Immanuel: well... typically we have made so simple APIs that just writing them in a 
	(free form) human readable document has been enough    (2JYR)
	KimViljanen: @Immanuel: btw, we forgot to say in our presentation that we were discussing whether 
	OOR could initiate / produce a W3C recommendation of this OOR API issue, as a member contribution or 
	something (not fully familiar with the W3C procedures on this)    (2JYS)
	PeterYim: @Kim - International standardization is definitely a medium to long term goal ... whether 
	it is W3C or OASIS or ISO, as the SDO (standard development organization) infrastructure we should 
	leverage would depend on other pragmatic factors (e.g. who is on the team, experience of the members 
	with the particular SDO process, expedience, which approach can best help us reach our ultimate 
	goals ... etc.)    (2JYT)
	anonymous morphed into MattHettinger    (2JYU)
	MikeBennett: Standardization of metadata about ontologies - agreed, very important. There are a 
	number of common problems currently implemented in different ways by different ontologies. We could 
	start by cataloguing these. Provenance is one such.    (2JYV)
	KimViljanen: could the first step for aligning the ontologies be that each of us provides a document 
	on their APIs (I suppose everybody have a somekind of a document existing), to get an overview    (2JYW)
	ToddSchneider: Yes. I'd suggest placing the artifacts on the OOR Architecture Wikipage    (2JYX)
	ToddSchneider: If possible, UML models would be optimal.    (2JYY)
	KimViljanen: [on Ken's remark that BioPortal (on which the OOR sandbox is running now) features 
	about 126 methods]  (ONKI LOOS API has ca. 10-15 methods)    (2JYZ)
	KenBaclawski: Here is the suggestion for followup action items: 1. Post your artifacts on the OOR 
	Architecture wikipage, 2. Review the artifacts on the wikipage, 3. Schedule a new meeting.    (2JZ0)
	KenBaclawski: Those who were not at the Take I architecture meeting should review that wikipage.    (2JZ1)
	PeterYim: that Architecture & API (take-1) meeting would be at:    (2JZ2)
	KenBaclawski: Everyone should create their own subpage of the architecture wikipage.    (2JZ3)
	KimViljanen: thanks for an inspiring meeting!    (2JZ4)
	YuriyMilov: Thanks for the great presentations    (2JZ5)
	PeterYim: nice session ... thank you!    (2JZ6)
	PeterYim: -- session ended: 8:06am PST --    (2JZ7)
     -- end of chat session --    (2JU9)

Audio Recording of this Session    (2JUA)

Proposed Architectural Approaches:    (2JUI)    (2JUK)    (2JUM)    (2JUO)    (2JUS)

For the record ...    (2JUT)

How To Join (while the session is in progress)    (2JUU)