ppy/chat-transcript_20100917c_edited.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 Professor MichaelGruninger (U of Toronto; IAOA) - "Concerns from the vantage point of COLORE" 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 PaulAlexander anonymous1 morphed into ToddSchneider anonymous morphed into Nikkia Anderson AlanRector: Todd - could you speak louder? thanks anonymous morphed into ElizabethFlorescu 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? SimonSpero: Github (and git in general)++ SimonSpero: But can track svn repository CameronRoss: @NatashaNoy - Is all BioPortal data stored as triples within MySQL? PaulAlexander: @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: @PaulAlexander - Is the Protege back-end just and XML file, or is it some kind of database? PaulAlexander: It's a database PaulAlexander: 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. PaulAlexander: 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. CameronRoss: @PaulAlexander - 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. CameronRoss: @NatashaNoy - Thanks... I tend to agree. SimonSpero: Q: What do you mean by "SKOS-based"? 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 SimonSpero: @NatashaNoy: So you just want to use it for labeling of ontologies, right? NatashaNoy: for labeling of ontology concepts, not ontologies themselves SimonSpero: @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 PaulAlexander: @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). CameronRoss: @PaulAlexander - The resource difference on the interface tier might be manageable, but representing CL in a triple store would probably be futile. NatashaNoy: @Paul: MichaelGruninger 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 PaulAlexander: @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. 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?) CameronRoss: @NatashaNoy - I guess it depends on the CL theories you're considering, but in general, I believe so. SimonSpero: @ImmanuelNormann: Does using a version control repository that deals in files make properly tracking provenance of assertions harder? SimonSpero: @NastashaNoy: 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 SimonSpero: @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: Simon: Sorry, still confused. What is the relationship between concepts A, B, and C in your example SimonSpero: A broader B , B broader C 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. SimonSpero: @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? SimonSpero: @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. SimonSpero: @Natasha: can take off line SimonSpero: 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) AlanRector: Apologies - I must go to catch a train CameronRoss: @All - If we're talking about platform independence, then we should focus on the specification... +1 CameronRoss: @Ken - Are the non-functional requirements documented beyond the 2008 communique? 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 ToddSchneider: Cameron, there has been little additional work on the requirements. anonymous morphed into FrankOlken FrankOlken: Hi 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 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? 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 PeterYim: Key content pages for OOR are listed at: http://ontolog.cim3.net/cgi-bin/wiki.pl?OpenOntologyRepository#nid293Q CameronRoss: @PeterYim - Thanks Peter. SimonSpero: 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) SimonSpero: @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: @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 ... 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 ToddSchneider: 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. SimonSpero: [May I comment on the meta first] SimonSpero: [on the multiple view problem the issue comes up when different viewers have different sets of people who are willing to view for example Wiki/DBPedia timeliness v. reliability issues SimonSpero: [Which protege?] SimonSpero: [reference to frame based] SimonSpero: Q: Is there a BioPortal git repository right now, or is this currently proposed? PaulAlexander: @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). PaulAlexander: Re: Git. We would definitely love comments if people have opinions. SimonSpero: Paul: git svn fetch works reasonably well PaulAlexander: @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. TerryLongstreth: new term for me - 'git'. Can you explain or provide a URL? SimonSpero: git svn dcommit SimonSpero: @Paul: also git svn commit-diff and git patch PaulAlexander: 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 TerryLongstreth: Thanks. Source code control is very complicated when your managing individual items (concepts, data elements... TerryLongstreth: c/your/you're/ PeterYim: can't hear you any more Immanuel ImmanuelNormann: I lost telephone connection - don't know why - sorry 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! CameronRoss: @Ken - What exactly is "the issue"... to be clear? 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. CameronRoss: @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. CameronRoss: @Ken - Shouldn't we start with the "API" and not the implementation? KenBaclawski: @Cameron - Yes, I think the discourse should be at the architecture and API level for now. CameronRoss: @Ken - Great! I couldn't agree more. SimonSpero: [Quick compare/contrast use case: https://www.nescent.org/sites/hive/Main_Page] 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" 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. PeterYim: Please continue the conversation on the [oor-forum] & [oor-dev] list ... and come to the next (and future) OOR-team meeting SimonSpero: Good bye and good yomtov YuriyMilov: Thanks, bye PeterYim: -- session ended: 11:03am PDT --