HCLSIG BioRDF Subgroup/Meetings/2007-07-16 Conference Call
Informal F2F Details
- Date of Meeting: Monday July 16, 2007
- Time of Meeting: 1:00pm-4:00pm Eastern Time
- Room 346, Stata Center, MIT, at 32 Vassar Street, Cambridge, MA
- Directions to Stata
- Street map showing Stata
- Building map showing room 346
- 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)
- Progress on URI work (see HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Recommendations )
The editor proposes the following:
- Review reasons for putting effort into this project
- Review objectives and target audience
- Discuss process (consensus and closure)
- JAR's proposals, see HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Recommendations/DraftTalk
- a) Conceptual framework: descriptions, documents, versions, access, etc.
- b) Bibliographic reference analogy
- c) Retrieval ontology and well-known retrieval rules
- d) Identifiers for public database records
- e) Administrative options
For each item, I'd like to see:
- participants understand the issue
- endorsement or rejection of work so far
- some progress (e.g. agreeing on requirements, elucidation of issues)
- agreement on plan for further work
- individual commitments to help out
1. Review reasons for putting effort into this project
- we want to use same URI for same thing, so that joins work - URIs should have clear meaning
- Punning is definitely not OK. E.g. a gene and its descriptive
record must have different URIs, if both have URIs at all. -- No disagreement from anyone present. - reusing a URI for different purpose worse than breaking link -- No disagreement from anyone present. - recommendations document must have a story about accessing stuff
- accessing document versions
- accessing RDF descriptions of resources
(definitions, identifications, specifications, documentation...)
- RDF statements that are otherwise about something, e.g.
non-description statements such as instrument readouts
2. Review objectives and target audience
Objectives: a document meeting above goals. HCLS primarily, others if possible. No one expressed an opinion on question of whether HCLS = those active in the public-semweb-lifesci list, or HCLS = the W3 SIG members, or HCLS = the larger health care & life sciences community.
3. Discuss process (consensus and closure)
Alan: what kind of endorsement, attached to the document, would make a difference to a life sciences "consumer" such as a pharma? [e.g. endorsed by editor only, by BioRDF, by HCLS mailing list, by
HCLS IG, by TAG or SWEO, ...] -- No particular answer.
Eric P: process = editor submits draft to the IG; draft is published on W3C site iff IG gives approval. Draft must specify its approval status, e.g. "editor's opinions only", "approved by IG", etc.
4. Make sure everyone understands the conceptual framework, and gets a
chance to critique JAR's approach of descriptions, documents, versions, access, etc.
Document: group's advice to JAR: augment definition with the nonintuitive examples such as news, instrument readout. Aims of defining this term:
- LSID compatibility
- opportunity to be different (or same) from foaf:Document
or AWWW "information resource" [3. Enable abstraction away from particular location methods such as HTTP] Alan: please consult with OBI on choice of term and/or definition General advice: please coin a new term, perhaps a qualification or refinement of "document".
There are groups of pieces-of-data, and some people use various terms for different purposes... Someone noted that different people implement LSIDs differently. Someone said that the LSID notion of version is impractical since it disallows trivial changes such as spelling corrections.
The "meaning" of document may be constant, but there is a need to provide variant representations. Bill gets stuck on the terms "version" and "variant". Advice to JAR: clarify definitions and give examples. Explicitly discuss issue of variants in meaning vs. variants in representation.
EN: Clear policy expression [of range of possible versions as a function of time and HTTP headers] is very important. AR: OBO has a reasonable framework for ontology evolution.
JAR explained to Bill Bug about versioned LSID denotations: an LSID that has a version component denotes a piece-of-data; otherwise it has no data, only metadata. (According to the spec that is.) Bill wants definitions that are clearer or more constrained; not necessarily different terms. AR: avoid using "version" and "variant" altogether. E.g. restrict
to language like
"An access at time t retrieves the document at time t..." [JAR: so
what do you
call what was retrieved? Is the definition (policy) of a document
tied to a concept
of "accessing"? ...]
JAR reiterated the non-punning principle: A piece of data and the document that of which it's a version need to have different names, or else no name at all. [On the web we name documents, and do GETs of those names to retrieve pieces-of-data, which we don't name. With LSIDs we name both the document (LSID with no version component) and the piece-of-data (LSID with version component).]
Dereference: JAR was advised to change the definition to the following: a particular way of getting a piece-of-data, using web protocols, given a URI. [N.b. the URI might name the piece-of-data, or it might name a document of which the piece-of-data is a version; or there may be no relation between the piece-of-data and the identified resource, if the server is behaving foolishly.]
There was some hesitation around "meant" statements, but the phrasing was reluctantly accepted.
Editor was advised to put in a heading to divide the NLM terms from the others. JAR proposed moving them out of the definitions section altogether.
AR: Put this principle up for discussion: Names should outlive their
Here is our first take at a strategy for a community process.
Daniel: ontology versioning.
EN: put in a link to POWDER.
5. Retrieval ontology and well-known retrieval rules
6. Identifiers for public database records
[I had to leave while this was being discussed]
7. Administrative options [for a naming authority, if we decide we need one]
Meeting adjourned before this item was reached.