[[/../../Recommendations|URI Note main page]]

What the URI Note must do

This is a meta-meta-document, giving not particular techical solutions but rather the questions that any technical proposal must solve for the community. Ideally it is written so that URI resolution ontology, HTTP protocol, LSID protocol, combinations of the above, etc. would provide alternative answers to the questions. Once we decide what our common concerns are, we can compare apples to apples, and choose rationally.

The "authoritative" requirements are here: [[/../Requirements]] - this is what the BioRDF subgroup agreed to at a telecon in summer 2007. (Some discussion at "[/../RequirementsTalk"]). What follows is JAR's elaboration on what the group decided.

The examples are given only to illustrate what's meant by the requirement, not to state a position.

Here are appropriate responses to this page:

"this doesn't make any sense to me"
"a URI Note meeting these requirements won't ask enough of other people to satisfy me"
"a URI Note meeting these requirements may ask me to do things I won't want to do"
"I know how these requirements can be met - here is what the URI Note would say were I to write it"

Use cases

We have not been very good about writing use cases. In JAR's opinion the main use is that of producing relatively durable RDF (i.e. stored for 5 years) that is to be combined with other RDF produced by someone whose only connection to the producer of the first RDF is that they have both read this document. (I say 5 years to be concrete; 5 seconds and 30 years are also cases of great interest.) But please tell me others or flesh this one out.

General

The URI Note should be of interest and of use to a broad cross-section of consumers and producers of RDF within the HCLS community
Technical aspects of the Note must be easily implemented based on off the shelf tools

URI choice and minting

The Note must advise the community on the following:

When and how to mint URIs (e.g. http:, purl:, urn:lsid:, info:, #)
What practices to follow regarding well-definedness and documentation (e.g. 'declarations', 303s, lsid metadata)
What particular URI's to use for resources related to public databases
- Naming scheme (bio2rdf, purl.org/commons, urn:lsid:, info:, wait for publisher's URIs, new domain name)
- What is named (record, xml version of record, entity described, etc)
- How the terms are defined (how documented to specify correct use in RDF)
- What entity is responsible for choosing and maintaining these URIs (w3c, new organizational entity, some current hcls member, org, publisher, etc)
- Whether/how to name particular versions of records (versioned database, versioned records, by date, lsid version number component, etc)

Resolution

The Note must advise the community on

How to get stuff
- How to use a URI to get a definition and/or description (RDF) of an identified resource (http GET to 303, http 200, lsid getMetadata, URI resolution ontology, some combination)
- How to use a URI to retrieve the contents of a document (http GET to 200, lsid getData, resolution ontology, etc)
How to relate similar names
- When to use/not use particular relations (sameAs/equivalentFoo, uri resolution rules)
- Infrastructure (30x, http proxy, etc)

Other

Other issues that the document needs to discuss (but not necessarily solve):

How to deal with unusual situations while getting stuff (see above)
- broken links (e.g. 404 due to moved content, LSID location independence)
- non-http URIs (e.g. urn:, info:, data:)
- mirrored or cached information (http proxies, LSID resolvers, resolution ontology)
Versioning and updates policy
- When a new name is needed (for any change, allow reuse for equivalent vs. monotonic vs. inconsistent update)
- How to find versions and relate them to one another (use SPARQL, look at "metadata", look inside URI synax e.g. lsid version component)
- Nature of "version families" (bunch of things that are all versions of same thing)