- From: Ivan Herman <ivan@w3.org>
- Date: Sat, 21 Jul 2007 09:35:43 +0200
- To: public-semweb-lifesci@w3.org
- CC: William Bug <William.Bug@DrexelMed.edu>, Susie Stephens <susie.stephens@gmail.com>, Jonathan Rees <jonathan.rees@gmail.com>, Susie M Stephens <STEPHENS_SUSIE_M@lilly.com>
- Message-ID: <46A1B74F.2020704@w3.org>
Bill & all your attachments exceeded the mailing list size limits. I have put the two attachments on the web instead: http://www.w3.org/2007/07/purl_IRIs.pdf http://www.w3.org/2007/07/purl_IRIs.svg Ivan William Bug wrote: > Hi All, > > I have a quick question related to this issue. > > We'd been working on the attached figure for the ISMB poster. > > I was primarily designed to build from the following earlier document > you wrote on the use of PURL for IRIs: > http://wiki.neurocommons.org/CommonNaming > > The figure attempts to provide an overview of what some HCLS IG > participants have done so far to implement PURLs as IRIs. It requires > more detail in terms of the individual resource layer at the bottom, I > believe. In particular, I'd point out the description of what BIRN is > doing in clustering BIRNLex the ontology along with related artifacts > (XSLT translators and XSD export schemas) would requires a bit more > detail in order to state how this relates to the issue of using PURL for > IRIs. In fact, in general, the caption requires more info on how and > why these 3 implementations differ - and this figure should probably be > put side-by-side with something that more completely represents the > current consensus emerging from these most recent debates on the list, > the TCons, and at the F2F. > > Do we want to add this to the Wiki somewhere for others to provide input. > > I've included both the editable SVG version and a PDF version, since > I've noticed some SVG viewers (the Firefox plugin, for instance) seem > not to render some of the objects in the SVG XML. > > Cheers, > Bill > > > ------------------------------------------------------------------------ > > > ------------------------------------------------------------------------ > > > On Jul 20, 2007, at 2:36 PM, Susie Stephens wrote: > >> I've added your notes to the wiki. >> >> Cheers, >> >> Susie >> >> >> >> On 7/20/07, *Jonathan Rees* <jonathan.rees@gmail.com >> <mailto: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. >> >> > > > > Bill Bug > Senior Research Analyst/Ontological Engineer > > Laboratory for Bioimaging & Anatomical Informatics > www.neuroterrain.org > Department of Neurobiology & Anatomy > Drexel University College of Medicine > 2900 Queen Lane > Philadelphia, PA 19129 > 215 991 8430 (ph) > 610 457 0443 (mobile) > 215 843 9367 (fax) > > > Please Note: I now have a new email - William.Bug@DrexelMed.edu > <mailto:William.Bug@DrexelMed.edu> > > > > -- Ivan Herman, W3C Semantic Web Activity Lead Home: http://www.w3.org/People/Ivan/ PGP Key: http://www.ivan-herman.net/pgpkey.html FOAF: http://www.ivan-herman.net/foaf.rdf
Received on Saturday, 21 July 2007 07:35:47 UTC