Discussion of possible requirements on the URI recommendations document

Put here your ideas on what needs to be covered in the recommendations document. Each topic that we agree to address means more work in preparing the document, so we need to be judicious about that; but a bit of brainstorming at first is probably not a bad thing.

Requirements can be of various kinds:

about the document (e.g. length, style, etc)
about what the document needs to address, i.e. a requirement that the document recommend a solution to some particular problem
requirements on solutions recommended by the document

Note that we can't require anything of one another, since this is a purely voluntary organization.

See [[/../../Recommendations:]] for context and [[/../Requirements:]] for a record of what we have agreed.

In scope

The document must attempt to have wide appeal and the potential for wide adoption within the HC & LS community. Therefore it has to be conservative, well-reasoned, and not gratuitously inconsistent with current practice.
Although the document does not always specify a single way to do things, options, when known and in scope, should be enumerated and weighed.
The doc must advise "average" HCLS RDF providers and consumers on how to choose and use URI's for things that their RDF talks about, including their own resources, resources that are not theirs but that don't have unique or obvious URI's, and classes and properties.

In scope?

Given a raw URI, what should one expect to be able to do with it, if anything? (e.g. HTTP GET)
Assuming URI dereferencing is deemed important, advice on what to do with broken links and local caching
Relationship between resource and meta-resource
URI "resolution" - how to get representations of info resources, and how to get statements about resources (definitional and otherwise)
Nonsense checking (e.g. static detection of use of non-info-resource as an info-resource)
Versioning (what exactly does this mean?)
The doc must have some kind of attitude about or discussion of AWWW and of LSID's

Not in scope

Satisfying anyone outside of the health care and life sciences communities
Data modeling

Basic recommendations we can agree on, maybe

AWWW is a null hypothesis; we endorse it except where we say otherwise (or stated as a requirement: "The recommendations doc. should endorse AWWW except...")
In order to use a URI, we need to know what it means (denotes). A URI should have associated documentation that is specific enough to guide the formation and interpretation of statements involving that URI.
No punning: a URI should denote one thing (resource), not two things. For example, a rat and a document describing that rat need different URI's.