ppy/oor_chat-transcript_20101015b_edited.txt PeterYim: . Welcome to the OpenOntologyRepository: OOR Team Conference Call - Fri 2010-10-15 . PeterYim: session page is at: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2010_10_15 PeterYim: . anonymous morphed into JouniTuominen KenBaclawski: Here is the architecture diagram we propose (as presented on 17-Sep-2010): http://ontolog.cim3.net/work/OpenOntologyRepository/2010-09-17_OOR-Dev-Take-4/OOR-Architecture--KenBaclawski_20100917.png KenBaclawski: This is the current OOR API (in Java) based on BioPortal: http://ontolog.cim3.net/work/OpenOntologyRepository/2010-09-17_OOR-Dev-Take-4/OOR-API--KenBaclawski_20100917.java PeterYim: all new contributions to the OOR software (except for existing non-BSD contributions that will, hopefully, be migrated over), as well as content (i.e. ontologies) uploaded to the public instance of the production OOR, operated by the OOR-team, will be made under the "Simplified (2-clause) BSD License" - see: http://opensource.org/licenses/bsd-license.php PeterYim: Let's step through the questions we need to address at this session (below) PeterYim: == Key requirements of the new OOR architecture? == MichaelGruninger: support for multiple ontology specification languages PeterYim: I think it must accommodate both the existing codebase (BioPortal) and new contributions KenBaclawski: The use cases are certainly important. The posted architecture is based on the use cases. MichaelGruninger: services of the OOR should be independent of the ontology specification language TillMossakowski: It should be flexible enough in order to easily integrate new formats and services PeterYim: as per OntologySummit2008_Communique ... we want to be on a Service Oriented Architecture MichaelGruninger: support for ontology metdata PeterYim: metadata should be an extension of OMV too PeterYim: robustness, scalability, etc. for the repository is definitely important YuriyMilov: Java based ... I agree to discuss the Java implementation later (as a recommendation, when we come to the choice of platform discussion, as PeterYim suggests) PeterYim: == Who are the immediate software contributors that we will need to accommodate? == PeterYim: NCBO / BioPortal KenBaclawski: My team at Northeastern University (NEU) MichaelGruninger: CameronRoss is leading the architectural design of COLORE TillMossakowski: at Bremen, we have a BioPortal clone and the Hets system TillMossakowski: the BioPortal clone is at http://ontologies.informatik.uni-bremen.de/ (which is AlexGarcia has been working on) TillMossakowski: We might want to use tntbase.org (but we have close contact to them) MikeDean: contributions from Raytheon-BBN PeterYim: NeOn project? .... (of course, OMV is from the NeOn project, and that is definitely in) PeterYim: ref. NeOn involvement I will continue the conversations with AldoGangemi, MathieuDaquin, AndreasHarth and EnricoMotta to solicit their involvement JouniTuominen: ONKI ontology service http://www.onki.fi, project page http://www.seco.tkk.fi/services/onki/ BartGajderowicz: My contribution would be library development BartGajderowicz: so code part BartGajderowicz: As part of my thesis, I have been working on ontology matching, and have developed an application, which I would like to contribute to the OOR architecture PeterYim: == Enumerating our options and candidate architectural approaches == TillMossakowski: slide no. 7 of Immanuel's presentation http://ontolog.cim3.net/file/work/OpenOntologyRepository/2010-09-17_OOR-Dev-Take-4/SOA-for-OOR--ImmanuelNormann_20100917.pdf YuriyMilov: Is Google's AppEngine an appropriate platform? I'd like to add some stuff from there TillMossakowski: I think a good thing is define a RESTful interface of services. We have implemented one for Hets, see http://trac.informatik.uni-bremen.de:8080/hets/wiki/RESTfulInterface . I am not meaning to use this one, but just want to give an idea of what a RESTful interface is. PeterYim: ref. BioPortal high level architecture - http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository_Architecture#nid2J32 KenBaclawski: I have posted an architecture which is based on the use cases, but I am open to suggestions especially concerning how to accommodate multiple specification languages for ontologies. JouniTuominen: +1 for RESTful interface. We have developed LOOS API (Linked Open Ontology Services, in spirit of LOD) for ONKI, see http://www.yso.fi/onkirest . Actually the intefrace it's not that RESTful, more like a method-based HTTP API KenBaclawski: @Till - Concerning the slide in Immanuel's presentation, this is not an SOA architecture diagram. In fact the entire diagram is just two diagrams: the GUI and the core services. KenBaclawski: @Till - I have the experience of developing web services for a military contract, and SOAP/WSDL was much easier to develop than REST. TillMossakowski: We have a bit of experience with SOAP, but have not implemented one project with both REST and SOAP. KenBaclawski: The current trend in SOA is for REST and SOAP to converge, so the distinction may disappear. TillMossakowski: Can WSDL be used together with either of them? KenBaclawski: Yes, it is possible for a single service to support both SOAP and REST at the same time. KenBaclawski: In my previous post about Immanual's presentation, I mean the diagram is two components, not two diagrams. MichaelGruninger: Architecture for COLORE can be found in slide 5 in the presentation at http://ontolog.cim3.net/file/work/OpenOntologyRepository/2010-09-10_CL-support-for-OOR/An-OOR-Implementation-for-COLORE--CameronRoss_20100910.pdf YuriyMilov: http://www.memo.in.th/wp-content/uploads/2010/09/Service-Oriented-Cloud-Computing-Architecture.pptx YuriyMilov: SOCCA supports easy application migration from one cloud to another and service redeployment to different clouds by separating the roles of service logic provider and service hosting/cloud providers. It promotes an open platform on which open standards, ontology are embraced. PeterYim: == decision: let's delegate the workout of architectural details to a committee == PeterYim: the committee is to run with an open transparent process, and will keep all of us in synch PeterYim: committee meetings to be announced so others can join as observers PeterYim: only code contributors will participate in making the final decisions ... other "architecture only" suggestions will only be provided as references to the committee PeterYim: the precepts agreed earlier as "Key requirements of the new OOR architecture" will drive the committee's work and decisions PeterYim: on the committee: rep from NCBO, NEU, UToronto, Bremen, Raytheon-BBN, NeOn ... (to be decided) ONKI, YuriyMilov, ... (BartGajderowicz agreed that he will just observe and work with what comes out of the committee) PeterYim: Architecture Committee will work up a architecture first ... and then develop the API PeterYim: each party in the committee to nominate their committee member ... Peter to contact those who are not here today PeterYim: we will defer discussion on development platform PeterYim: we will continue to discuss regular meeting times on the [oor-forum] list ... please provide input into the doodle poll if you haven't already - goto: http://doodle.com/a2snxkpkd8hhxek4 PeterYim: as discussed previously, this is almost about time we start this - have alternate Friday OOR team meetings - one for OOR high level issues, content, admin etc., and the other for deep-water technical meetings. PeterYim: ALL: agreed ... we can possibly even have alternate (Friday) start-times for each of these meeting sets PeterYim: thanks everyone ... very productive meeting indeed! PeterYim: -- session ended 8:10am PDT -- PeterYim: The unedited chat-transcript is now online ... I will be posting the audio archive and a lightly edited (and re-organized) version of the chat transcript (for clarity and better intelligibility) later. PeterYim: see under: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2010_10_15#nid2J3M