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

Location

• Room 346, Stata Center, MIT, at 32 Vassar Street, Cambridge, MA
• Directions to Stata
• Street map showing Stata
• Building map showing room 346

Telcon Details

• 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)

Agenda

• Progress on URI work (see HCLSIG_BioRDF_Subgroup/Tasks/URI_Best_Practices/Recommendations )

The editor proposes the following:

1. Review reasons for putting effort into this project
2. Review objectives and target audience
3. Discuss process (consensus and closure)
4. 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:

1. participants understand the issue
2. endorsement or rejection of work so far
3. some progress (e.g. agreeing on requirements, elucidation of issues)
4. agreement on plan for further work
5. individual commitments to help out

Minutes

IRC http://www.w3.org/2007/07/16-BioRDF-minutes
Meeting Notes:

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

1. accessing document versions
2. accessing RDF descriptions of resources

        (definitions, identifications, specifications, documentation...)

1. 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:

1. LSID compatibility
2. 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

publishers.

 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

 Skipped

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.