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-requestw3.org
[mailto:public-semweb-lifesci-requestw3.org] On Behalf Of
Jonathan Rees
Sent: Friday, July 20, 2007 10:40 AM
To: Susie M Stephens
Cc: public-semweb-lifesciw3.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 foafocument
       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.