Re: BioRDF Informal F2F

I've added your notes to the wiki.

Cheers,

Susie



On 7/20/07, Jonathan Rees <jonathan.rees@gmail.com> wrote:
>
>
> 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.
>
>