ppy/chat-transcript_20100917b_unedited.txt PeterYim: . Welcome to the OOR Panel Discussion: "Getting OOR Development Going - Take-IV" - Fri 17-Sep-2010 This session is sometimes referred to as the "fork" session. The key issue being addressed at this virtual workshop session is on how we should manage to incorporate various ongoing OOR-related software development efforts, and how best to "fork" from the BioPortal codebase while staying synergistic. * Co-chairs: Professor MichaelGruninger (U of Toronto) and Dr. ToddSchneider (Raytheon) * Panelists: (2H0V) o Dr. ToddSchneider (OOR; Raytheon) - "Getting OOR Development Going - a proposal" o Mr. MikeDean (OOR; Raytheon-BBN) - "The OOR Code Repository" - to be presented by PeterYim on MikeDean's behalf o Dr. NatashaNoy (NCBO; Stanford-BMIR) - "Forking OOR Development: Thoughts from NCBO" o Dr. ImmanuelNormann (Bremen U; BORG) - "More Service Orientation to open Ontology Repositories - HeTS, TNTBase, and OOR" o Professor KenBaclawski (Northeastern U) - "OOR: Architecture and Interfaces" o Dr. AlexanderGarcia (Bremen U BORG) - "The ORATE Contribution" o Professor MichaelGruninger (U of Toronto; IAOA) - "The COLORE Contribution" Please refer to details on the session page at: http://ontolog.cim3.net/cgi-bin/wiki.pl?OOR/ConferenceCall_2010_09_17 . anonymous morphed into Paul Alexander anonymous1 morphed into ToddSchneider anonymous morphed into Nikkia Anderson AlanRector: Todd - could you speak louder? thanks anonymous morphed into ElizabethF CameronRoss: @NatashaRoy - Is all BioPortal data stored as triples within MySQL? CameronRoss: +1 OMV CameronRoss: @All - The BioPortal resource model seems oriented around OWL-based(?) terms like concepts, instances and properties etc. This doesn't seem to align well with general CL theories. Does anyone have ideas on how to rationalize this? Simon Spero: Github (and git in general)++ Simon Spero: But can track svn repository Paul Alexander: @Cameron: BioPortal data is not currently stored as triples, but that's where we'll be moving in the future. Currently OWL/Protege ontologies are stored in a Protege back-end. OBO, RRF, etc are stored using LexEVS. Metadata is stored in a Protege back-end as well. CameronRoss: @Paul Alexander - Is the Protege back-end just and XML file, or is it some kind of database? Paul Alexander: It's a database Paul Alexander: MySQL with one table per ontology and another table for the metadata CameronRoss: Thanks CameronRoss: @All - I think storing general CL in a triple store will be a challenge. Simon Spero: Q: What do you mean by "SKOS-based"? Paul Alexander: RE: Common Logic fitting the OWL model. It wouldn't be difficult to have a separate set of REST services to handle common logic. Of course this would make it so there is no common method for accessing all of the resources in the repository. NatashaNoy: @Simon SKOS-based: when we move to a triplestore, we want to have a simple model for representing ontologies and terminologies, including things like preferred names, synonyms, definitions, etc. This will be a unifying layer among the different formats that we have. SKOS provides this layer, and we may need to extend it with a few additional properties CameronRoss: @Paul Alexander - I wonder if the resource interface could be generalized... if not then supporting unique resource interfaces would be useful. NatashaNoy: RE: Common logic: it is true though that our user interface is very much class-centric, and so are our REST services. That's what *our* users needed. Adapting it to CL is definitely a challenge as it is a very different view of ontologies. Simon Spero: NatashaNoy: So you just want to use it for labeling of ontologies, right? CameronRoss: @NatashaNoy - Thanks... I tend to agree. NatashaNoy: for labeling of ontology concepts, not ontologies themselves Simon Spero: NatashaNoy: good - have had a lot of problems with people confusing the word "butterfly" with butterflies. NatashaNoy: @Simon: yes we have that model now as well. But it is a bit idiosyncratic. So, we want something more thought-out and standards based for the next major version. SKOS is a perfect standard for that Paul Alexander: @Cameron: I'm not very familiar with common logic. If there are enough commonalities between CL and OWL/OBO/RRF it should be do-able. However, it would be a major change and require a significant amount of work to restructure all of the service signatures and XML responses (assuming you can't shoe-horn CL into the existing resource model). Simon Spero: ImmanuelNormann: Does using a version control repository that deals in files make properly tracking provenance of assertions harder? CameronRoss: @Paul Alexander - The resource difference on the interface tier might be manageable, but representing CL in a triple store would probably be futile. NatashaNoy: @Paul: Mike Gruninger looked at trying to shoe-horn CL into the class-centric model of BioPortal, and I think the conclusion was that it pretty much didn't work. CL is axiom-based and so it is a very different focus Simon Spero: NastashNoy: As long as you ignore the SKOS support for of Non-Transitive hierarchical relations which was forced in due to butterfly/"butterfly" confusions NatashaNoy: @Simon: not sure i understand Paul Alexander: @Cameron: Sure, but there's nothing stopping running a different store alongside the triplestore. We very much respect OOP and already have our code handling different formats/stores. Very soon we'll have MySQL, LexEVS, Protege Server, and a triple store all running different parts of BioPortal. Simon Spero: Natasha: SKOS was changed so that everything about Concept A is always also about Concept B, everything about Concept B is always also about Concept C. but it is possible for something to be about Concept A but not about Concept C NatashaNoy: On CL: I think it is the UI that is more of a problem. Our UI is coompletely focused on browsing classes and class hierarchies. My understanding is that it's pretty useless for CL (Cameron, am I right?) NatashaNoy: Simon: Sorry, still confused. What is the relationship between concepts A, B, and C in your example Simon Spero: A broader B , B broader C CameronRoss: @NatashNoy - I guess it depends on the CL theories you're considering, but in general, I believe so. NatashaNoy: There are two "broader" properties in SKOS: one is transitive, one is not CameronRoss: @Immanuel - The general architecture I think you're proposing sounds very familiar to John Sowa's Flexible Modular Framework for Intelligent Systems. Simon Spero: Natasha: yes - that was a bug introduced after the SMEs left NatashaNoy: Simon: Still don't see why this is a bug. As long as you choose the appropriate "broader" property, you are ok, aren't you? There are cases for both of them, aren't there? CameronRoss: @All - If we're talking about platform independence, then we should focus on the specification... +1 Simon Spero: NatashaNoy: when you add the note that you're not supposed to assert the (tradtional KOS) BT relationship, which was called broader until 2004, but then renamed to broaderTransitive. Simon Spero: Natasha: can take off line CameronRoss: @Ken - Are the non-functional requirements documented beyond the 2008 communique? AlanRector: Apologies - I must go to catch a train ImmanuelNormann: I absolutely agree with Cameron: we should focus on the specification ... and consider the BioPortal of one possible instance, satisfying this spacification to a certain extend ToddSchneider1: Cameron, there has been little additional work on the requirements. PeterYim: @Ken - ref. your slide#14 - the link to the "OOR Interface" doesn't seem to be active ... please advise what the URL should be anonymous morphed into FrankOlken FrankOlken: Hi Simon Spero: To take this point further: a lot of the functionality being described generalizes across all kinds of Repositories of Semantic data (not just repositories of Ontologies) KenBaclawski: Here is the link to the OOR Interface page: http://www.ccs.neu.edu/home/kenb/oor/index.html CameronRoss: Re: CL - The BioPortal presentation tier, interface tier and persistence tier all require 'thought' for CL. KenBaclawski: @Cameron I believe that they have, but I don't recall what the link is. Perhaps Peter could find this? Simon Spero: Isn't that orthogonal to federation? PeterYim: @Simon - this conversation is going to be archived ... therefore, please provide some context when making a comment (otherwise it will not mean much to someone going through the archives) Simon Spero: PeterYim: (adding context) Isn't the issue of handling CL and OWL separate from federation (which is more a distributed architecture) NatashaNoy: sorry, will have to sign off in a couple of minutes PeterYim: @Cameron & Ken - ref. the question on non-functional requirements - the slides from Todd and Ken today are good ... some of those may also have been captured into the "OOR_Requirement" page at: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository_Requirement CameronRoss1: @PeterYim - Thanks Peter. Simon Spero: [May I comment on the meta first] PeterYim: Key content pages for OOR are listed at: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository#nid293Q ToddSchneider1: All, I'll need to leave this meeting at 13:45 EDT. Thanks to all presenters. Let's press on. TerryLongstreth: on provenance- not all artifacts will be necessarily be generated by individuals. Provenance tracking should include provisions for stowing identifiers for automated functions. Simon Spero: [on the multiple view problem the issue comes up when different viewers have different sets of people who are willing to iew PeterYim: @Todd and All - ref. an earlier presentation by KenBaclawski and MaximoGurmendez of NEU on "Quality and Gatekeeping Use Cases for the OOR" at: http://ontolog.cim3.net/cgi-bin/wiki.pl?ConferenceCall_2010_04_01 Simon Spero: [cont] for example Wiki/DBPedia timeliness v. reliability issues PeterYim: their slides are at: http://ontolog.cim3.net/file/work/OOR-Ontolog-Panel/2010-04-01_OOR-Use-Cases-III/QualityAndGatekeepingUseCasesForOOR--KenBaclawski-MaximoGurmendez__20100401.pdf Simon Spero: [Which protege?] Simon Spero: [reference to frame based] Simon Spero: Q: Is there a BioPortal git repository right now, or is this currently proposed? Paul Alexander: @Simon: We're exploring migrating to Git, especially if there is a broader community interested in participating using some of the tools out there that would seemingly enable easier community development (like GitHub). CameronRoss1: @Ken - What exactly is "the issue"... to be clear? Paul Alexander: Re: Git. We would definitely love comments if people have opinions. Simon Spero: Paul: git svn fetch works reasonably well Paul Alexander: @Simon: One of the reasons we're considering switching is so we can more easily roll changes that are being made back into our master repository. I don't think the svn-git conversion would help us there. PeterYim: can't hear you any more Immanuel TerryLongstreth: new term for me - 'git'. Can you explain or provide a URL? Simon Spero: git svn dcommit CameronRoss1: @All - I agree with Immanuel. We could really use Use Cases that describe the reasoning related functionalities, as this is the part that seems to have more uncertainty associated with it. ImmanuelNormann: I lost telephone connection - don't know why - sorry Simon Spero: Paul: also git svn commit-diff and git patch PeterYim: Please continue the conversation on the [oor-forum] & [oor-dev] list ... and come to the next (and future) OOR-team meeting KenBaclawski: @Cameron regarding "the issue". I see the issue as being whether the fork should remain consistent with the BioPortal code base or should we diverge so that we would not be able to remain consistent with their code base. Paul Alexander: Git is one of a number of solutions for a new paradigm for source control management where the code gets distributed rather than centralized in a single repository. Similar to SVN but not centralized. http://en.wikipedia.org/wiki/Distributed_revision_control ImmanuelNormann: My telephone seems to be broken - I will put my comments on the OOR mailing list - and leave the session now. Thanks and good bye! TerryLongstreth: Thanks. Source code control is very complicated when your managing individual items (concepts, data elements... TerryLongstreth: c/your/you're/ CameronRoss1: @Ken - Shouldn't we start with the a"API" and not the implementation? KenBaclawski: @Cameron - Yes, I think the discourse should be at the architecture and API level for now. Simon Spero: [Quick compare/contrast use case: https://www.nescent.org/sites/hive/Main_Page] Simon Spero: Good bye and good yomtov CameronRoss1: @Ken - Great! I couldn't agree more. YuriyMilov: Thanks, bye PeterYim: @Ken - ref. the comment about robustness - it *is* an objective of the OOR initiative to provide (at least one instance of a) robust OOR ... therefore, we (the OOR-team) are not deferring that to "commercial enterprises" PeterYim: -- session ended: 11:03am PDT -- KenBaclawski: @Peter re: robustness. I misspoke. The reference implementation must be robust. My intention was to distinguish a reference implementation which has only the required functionality from an "industrial-strength" implementation which has much more. In other words, the reference implementation is only a starting point for other groups, whether they are open source or commercial.