RE: BioRDF Informal F2F

Johnathan,

Thank you so much for taking the lead and putting so much time into this
extremely important project. So far I haven't been able to contribute but
your work is helping me get up to speed on the issues. The entire SW
community will benefit from your prodigious effort.

Don

-----Original Message-----
From: public-semweb-lifesci-request@w3.org
[mailto:public-semweb-lifesci-request@w3.org] On Behalf Of Jonathan Rees
Sent: Friday, July 20, 2007 10:40 AM
To: Susie M Stephens
Cc: public-semweb-lifesci@w3.org
Subject: Re: BioRDF Informal F2F


Here are my notes on Monday's meeting.  [Bracketed] phrases are my
after-the-fact clarifications and don't necessarily reflect anything
that happened at the meeting.

This should go into the wiki, but I'm too busy to do the formatting
right now, and I will probably forget later. If someone else does it I
won't complain.

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...)
     3. 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.

Received on Friday, 20 July 2007 15:26:01 UTC