HCLSIG BioRDF Subgroup/Meetings/2007-06-11 Conference Call
From W3C Wiki
- Date of Call: Monday June 11, 2007
- Time of Call: 11:00am Eastern Time
- Dial-In #: +1.617.761.6200 (Cambridge, MA)
- Dial-In #: +33.4.89.06.34.99 (Nice, France)
- Dial-In #: +44.117.370.6152 (Bristol, UK)
- Participant Access Code: 246733 ("BIORDF")
- IRC Channel: irc.w3.org port 6665 channel #BioRDF (see W3C IRC page for details, or see Web IRC)
- Duration: ~1 hour
- Convener: Susie Stephens
- Scribe: Matthias Samwald
- Select additional data sets for incorporation into the demo - all
- Overview of URI design decisions - Jonathan
- Review of demo ontology - Matthias, et al.
- Attendees: Elizabeth Wu, John Barkley, Ray Hookaway, Susie Stephens, Matthias Samwald, Jonathan Rees, Eric Prud'hommeaux, Alan Ruttenberg, Scott Marshall, Helen Chen
Topic: URI design decisions
Jonathan: has made a status report. The topic of URIs is multi-faceted and contains many questions: how to mint URIs in general, how do we get information about the URIs etc. The task has no clear boundaries. It might not be possible to address all things in our task force (versioning, how do we get persistent solution of URIs etc.). We need a clear structure of what we are NOT discussing. Alan made a proposal for ontology based expression of rules for expressing URI resolution, i.e. relation between the URI of a resource and the URI you can use to retrieve additional information about the resource. The distinctions are not necessarily clear. What does HTTP-GET mean? What kind or resolution ontology do we want?
Matthias: right now we need to have URIs, everything else is secondary at the moment
Jonathan: PURL URIs might end up sticking.
Eric P: they [Science Commons] are not promising to serve it infinitely
Alan: Maybe it is a good development. Maybe we should not rely on data providers themselves to mint URIs.
Susie: At the F2F in Amsterdam we seemed to agree on using HTTP URLs (and not on LSIDs, for example). Maybe BioRDF should invest more into this. SWEO Interest Group might be interested in something like this
Eric P: There is not too much commercial interest at the moment. This might be a solution "in this particular environment", but it might not make sense for everybody.
Susie: If we focus on what our best-practices are, maybe we can make progress.
John: Why don’t we like LSIDs?
Jonathan: There are different reasons for different people. It is not clear what the LSID denotes (biological entity, data or metadata?). We should try to separate this. LSIDs seem not to be too well-supported.
Alan: The latest version of Uniprot uses LSIDs, but they don’t resolve, and the semantics are not well-specified.
Jonathan: The Biopathway resolver works for some LSIDs, but the metadata that came back was not specified and quite opaque.
John: As I understand it, is very similar to the Domain name service.
Jonathan: There is a lot of work to do, and I am willing to invest work, but we really have to decide on what our priorities are.
John: The library business has ISBN, for example.
Alan: A lot has been written about web architecture, there is a lot of discussion and consensus behind it.
Matthias: Our main priority right now is to get the PURL-based URIs for database records, and think about their resolution mechanism later on
Jonathan: maybe we should discuss the requirements first, since the basic discussions like LSID vs. URL are still coming up
Alan: we should have page of proposed requirements, that page should refer to other pages we came up with as responses to these requirements
ACTION: Jonathan sets up a wiki page, advertises it
Alan: we should go through our mailing list archive and collect the main discussions on this subject.
ACTION: Susie collects relevant mails about URIs
Alan: we should come up with a document for the W3C. Of course it will be hard to reach consensus.
Scott: I thought there were some mechanisms you already have in mind
Jonathan: This still was not discussed enough
Topic: Demo ontology review
Matthias: Sent out mail about the ontology as agreed last week. The main points related to maintaining evidence, and the relation between data sets, e.g. the logical entities themselves versus the documents about the entities.
Alan: Agrees that evidence needs to be re-considered. Properties were more a solution to clarify their meaning. Information resources will probably be generically dependent continuants in the next version of BFO.
Matthias: We should wait longer for more input. To date most people agree evidence needs work. DOLCE uses a property called ‘about’ to relate information resources to the things that are described by the resources.
Alan – If someone interested in doing a prototype re-expression then that would be useful. Could press OBO about what relations to use for this.
Matthias – I brought this up on the BFO mailing list, but there wasn’t much discussion.
Alan – We could set up telco with interested parties?
General consensus: We need to review these issues further before discussing about it in the teleconference. We will discuss about it in the next teleconference.
Topic: Adding new datasets
Susie: We have identified several data sources, but not all have been converted at the moment.
Alan: Homologene has been converted, MGD is still in the works. MGD has some overlapping entities with the OBO evidence ontology, we need to do mappings. PURLs for MGI identifiers have to be created. Entrez Gene: Gene summaries are missing, review should be done, more actual data needs to be integrated, we need to coordinate people with actual query requirements (Ray Hookaway).
Ray: the Entrez Gene ontology should be influence by the Sequence Ontology – stuff.
Alan: many people have tried transliterations of Entrez Gene into RDF, we want to concentrate on good re-modelling.
Susie: Phenotype association datasets?
Alan: I try to involve Chris Mungall, because he knows more than I do. Disease ontology is also in the works.
Jonathan: works on Medline – scripting is easy, but modelling is hard.
Alan: looking into "Hermit" reasoner, can classify ontologies that no other reasoner can classify (e.g. because of size or specific patterns). Compromises on expressiveness – does not handle full OWL.