URI Practices main page . URI Note main page . Versioning . Metadata . Use Cases . Issues
URI Note - Main Page
The purpose of the planned URI note is to advise practices around choice and use of URIs that will help us (HCLS IG members and other members of the HC & LS community) build on one another's work. That is, it will describe practices that we agree to follow, and that we respectfully request others to follow.
Active documents as of 2008-05-27
The current draft will always be found here
/URI_Resolution - URI resolution vocabulary
- and the seven trouble spot pages listed just below
Major remaining trouble spots
/DenoteVsDereference - how to explain the relationship between denotation and dereference
/RacineSharing - tolerate or discourage?
/DeclarationDelineation - how strongly to encourage?
/AttitudeTowardMigration - tolerate ephemeral locations (deal via resolution rules) or discourage (SHOULD use only highly stable URIs such as purls)?
/Purls - how strongly can we recommend purl.org?
/PublicResources - exactly what URIs to use for NCBI records, journal articles, etc?
/AttitudeTowardNonlocators - ok to use info:, urn:lsid:, tag: ?
Documents
Requirements - what this URI Note will have to provide to the community
/UriNoteRequirements - what we're trying to accomplish
Process documents / pages
/../Work Plan for preparing a recommendations document, including timeline
/../Status 2007-06-08 gives overview of work to date on this task
Drafts
Version from October 2007 before rewrite
/ShorterSputnikDraft 2007-10-18
/SputnikDraft - JAR's URI note draft starting Sputnik Day 2007-10-07
/DraftTalk - discussion of the proposed recommendations document
Analysis and ideas (from within HCLS)
/MeaningOfaTerm - discussion of issue of URI meaning, consistency, caching, and so on
HCLS/HCLS_URI_matrix - comparison matrix of URI proposals
DereferenceURI describes the "follow your nose" approach to description harvesting (Chimezie)
HCLS/WebClosureSocialConvention a social convention (through vocabulary usage) for "getting stuff" from an RDF Graph (Chimezie)
Ontology-based URI Resolution - presentation by Matthias Samwald and Alan Ruttenberg, Amsterdam Oct 2006
About the URIs used in the Banff demo (see also http://sw.neurocommons.org/2007/uri-explanation.html)
Manifesto of Francois and Marc-Alexandre
Some pro-LSID arguments (Mark Wilkinson, semanticmusings blog)
LSID skepticism (Benjamin Good)
"The battle for LSIDs and the obsession with browsers" - Cartik Kothari
Reference
Web Architecture Illustrated (Dan Connolly)
On Linking Alternative Representations To Enable Discovery And Publishing (TAG finding)
Rethinking LSIDs versus HTTP URI (Rod Page)
URI Resolution Description using RDF (Dan Brickley)
Past discussions
These links point to the majority of last year's URI discussion.
http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jun/
http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Jul/
http://lists.w3.org/Archives/Public/public-semweb-lifesci/2006Aug/
Issues
- Is URI resolution (to definitions, descriptions, and/or "representations") "crucial"? [A: You need the definitions. Provide separate links if you have to.]
- Do we care what kinds of URIs are minted for our resources?
- Follow TAG recommendations ("cool" http URI's)
- Use LSID's
- Use another kind of URN (Francois)
- Doesn't matter a lot (URI string has no inherent meaning, resolution if any can be expressed in RDF) [JAR's preferred answer]
- Do we care about sharing URI resolution information (e.g. URN-to-URL rewrite rules, broken link repair, etc.)? If so, what should the shared information look like?
Rules represented in RDF [JAR's answer, see /URI_Resolution]
- Use some other notation
- Not important enough to worry about
- If current URIs are prototypes, but could become de facto, should we use 'purl re-direction' from the beginning? [TAG: yes, JAR: No]
- How to balance the need for durable access with the need for casual minting? (We don't necessarily know when we mint whether we will need citability; we may not even be in a position to publish on the web.) [JAR: resolution ontology]
I believe that we will need to choose or invent a convention, API, and/or protocol for accessing term definitions and other RDF related to terms. We need something that works predictably (not heuristically); for all resources (including 200-responders); from any source (not just the URI's owner). See /URI_Resolution
I think we'll be much better off if we separate the definition (declaration) of a term from other related RDF, such as description of the resource. It's not obvious how to best do this. See /DeclarationDelineation
I think we will need to establish a new structure (committee or organization) for managing whatever URIs we agree on for public database records, or else cultivate some existing entity. The issue is trust - everyone needs to be comfortable using the new URIs. See /PublicResources
- I think a service providing consistency and accessibility would be highly desirable - analogous to genbank but for arbitrary digital information.
- I think a journal-like review process for assessing quality of RDF will be highly desirable.
- Are we really trying to deal with archivally viable RDF, or just short time horizons? I think we may need to abandon archival RDF for now, although a genbank analog and journal would go a long way towards enabling it. [JAR: If it's not going to promote eventual archiving, it's not good enough.]
- Where to recommend minting - urn:lsid: or http: ? LSID seems to be poorly supported, but perhaps it could be revived and perhaps exported outside of life sciences. On the other hand if we can get the main benefits of LSID for all URIs, and not just LSIDs, then there will be fewer reasons to prefer LSIDs to other schemes. [JAR: We should win people over, not bully them.]