Attitude Toward Nonlocators

Should the URI note take a stand on acceptability of particular URI schemes, such as http: or urn: ?

locator: a URI for which most web browsers, and other web-accessing agents, have a dereference capability (i.e. they know how to try to dereference the URI). http:, https:, and ftp: URIs are locators, the data: scheme probably qualifies, and there may be other schemes such as news: that are widely handled - I don't know. Determining the boundaries is an empirical question, not a principled one, and there are no precise definitions of 'browser' or 'most'.

I give you three options: neutral, http OK, http not OK.

Status Quo

People use a variety of schemes in RDF, and everyone has a favorite scheme and complains about all the others.

Note should take no stand

I propose that the URI note take no stand on this issue. In other words, you can use whatever URIs you want and not be considered to be inconveniencing others too much -- assuming you do the other things you are supposed to do, such as relate them (via 'defines' links or rules) to definitional-RDF-document locators when the URI isn't a locator.

If the note does take a stand either way, significant audiences will be alienated, and the goal of using this note to get LSID and HTTP users to cooperate and use one another's work may fail.

If we change our minds, we can always issue a revision.

This battle has consumed vast human resources and is unlikely to go anywhere. Better to try to do something concrete than attempt to persuade anyone. The [[/../URI_Resolution]] ontology is designed to do exactly that. It lets you express the practice of using http-based LSID proxies, lets you deal with segments of the info: URI space, has the potential for dealing with handles, gives a way to assign a location to a tag: URI, and so on.

A stand I am willing to take in favor of http: is to say you need to provide a locator for a definition for any URI that is not itself a locator of its own definition. This is similar (in broad strokes) to the LSID solution taken by TDWG, which advises relating the urn:lsid: URI to an http: URI pointing to TDWG's LSID proxy.

And at the same time, I am trying to rehabilitate http: space by fixing some of the things it has been criticized for (as Mark W might say: mopping up after the train wreck). Here are things I think can be fixed fairly easily with a [[/../URI_Resolution]] ontology ("insert hack" in Carole Goble's recent talk):

second sourcing
content moved elsewhere (see [[/../AttitudeTowardMigration]])
local caching
simultaneous data/metadata forks
a way to distinguish unchanging documents (LSID "piece of data") useable for repeating analyses from random web documents that change out from under you
a way to recognize versions of something and relate them to one another

Given all this, it's conceivable that some people might be seduced back into http:-land away from LSID-land. But http: (as enriched by a resolution ontology) should stand on its own merits, not made a requirement of good citizenship.

One reason I'm proposing a resolution ontology is as a way to build trust in the http: scheme, by showing that you can deal with failures, should failures happen in spite of your best efforts to establish durable, principled locator/identifiers in http-land.

Why do I like locators at all? Because of the massive installed base, both of so-called "documents" and of software. Anything that's remotely programmable nowadays can be programmed to do a GET. Another argument is that if you're playing the semantic web game (playing nicely with the work of others), you have no choice but to accept http: URIs - all the core ontologies (RDF, RDFS, OWL, OBO, ...) use them, as does a rapidly growing number of others. So if you can stomach those URIs, why would additional http: URIs be problematic?

Note should say that you should only mint locators

The case for http: has been stated and restated many many times by many people.

JAR's version: Yes, the unpleasant parts of http: space have tainted the rest of it. But get over it. You should just learn that if you restrict yourself to the nice neighborhoods, then you will be happy. Etc. etc. And besides the resolution ontology makes it a lot better.

(I will let the proponents of this view insert their arguments here (AlanRuttenberg? DavidBooth?) - or maybe link to their favorite expositions, since it's difficult to imagine anything new could be said.)

Note should say you should only mint nonlocators

The case against http: has been stated and restated many many times by many people. One of many: "The battle for LSIDs and the obsession with browsers".

(I will let the proponents of this view insert their arguments here (Mark Wilkinson?) - or maybe link to their favorite expositions, since it's difficult to imagine anything new could be said.)