• GoodURIs

What qualities make a URI work well in RDF and on the web in general?

Unambiguous. Is there a consensus of meaning, where everyone using the URI as a name uses it to refer to essentially the same thing? Or is there confusion and disagreement among reasonable people? If you use an ambiguous URI in some RDF content, that content becomes (additionally) ambiguous, which is rarely what you want.

• Are file: URIs (with the hostname omitted, as it usually is) unambiguous?

  One can imagine "file:///etc/passwd" as denoting some platonic thing with multiple realizations around the world, but this is pretty sketchy. (If you're not sure whether something is ambiguous, it is.) With the hostname omitted, file: URIs are essentially relative (context-dependent); they are not GoodURIs.

  • What about http://localhost ?

• There are two kinds of ambiguity. The okay kind, which is unavoidable, is where the receiver doesn't know exactly what the sender meant. This is different from the bad kind, sometimes called overloading, where the sender uses the same name (URI) for two or more different things in the same communications context. With the first kind, the ambiguity can gradually be reduced by making more and more statements using the name. With the second kind, it's easy to make a statement which is logically inconsistent, as in this sentence using the name "Tim" in an overloaded manner: "Tim [Bray] is not the same person as Tim [Berners-Lee]."

• It's possible to have subsets of the meaning available in

  certain situations but not others, as in ConcentricSemantics. This is weird if you ask "what is identified?", but works fine.

• I take issue with the idea that good URI are, or should be, if used properly, unambiguous. I believe that I have proved, in my post Problems Identifying Information that, as names, some ambiguous URI are powerful and useful. Furthermore, that post shows that the W3C itself, in spite of what is stated in its Architecture document, utilizes the power of ambiguous URI in its basic operation, that of creating and promoting technology standards. Also, in my post Anatomy of a Reference, I question the basic idea that just "having a URI" for something is sufficient to identify that something. I believe it takes more, as I suggest in that post. Finally, it is often assumed that the uniqueness of an HTTP URI somehow prevents ambiguity. But this is not case as I show in Ambiguity and Identity. My point in all this is to say, yes, HTTP URI make good names, but names do not function the way the W3C says URI should. These are not the same: access keys in an information retrieval system and names in a language. - JohnBlack

While there are perhaps other ways to achieve a consensus of meaning, the most widely deployed, by far, is navigability:

Navigable (or Browsable). Does an ordinary user agent (e.g. browser) provide useful, relevant content when told to visit this URI? Can this URI be used as a normal hypertext link in HTML, without giving a 404, "<server> could not be found" message, or unintelligible content? The served content should be judged in the context of the intended application area: who might see this URI, and will they get what they want if they click on on it?

Persistent. Will it remain navigable and relatively unambiguous into the future, for as long as you want your RDF content to be useful? Does the agent which controls what content is served for that URI (loosely, the URI's "owner") have reason to keep it navigable for a long time? In contrast: Is ownership likely to change hands or are the owners likely to change their minds? Is there a community which is motivated to help maintain the consensus of meaning?

Descriptive. Is the URI mnemonic? Is it easy to copy, transcribe, or dictate? Do people reading it get the right idea about what it means? Does it follow conventions such as using a RoleNoun for properties? (No URI is easy to type or read, but some are much easier than others.)

• IRIs and internationalization issues add some subtleties here. Friendly to one person is not necessarily friendly to another.

Note that this is mostly a robustness issue; trying to get at the meaning of a URI by looking at it is a debugging feature, not a normal usage.

See: DescriptiveName, GlobalNaming, UniversalNames, NameIt, DefineYourTerms, ....

If you have trouble making a single good URI, sometimes making several RedundantUris will suffice. This tradeoff may be like the tradeoff between having one highly-reliable server and several unreliable ones.

nearby: WhenBrowsableAndUnambiguousCollide. It describes some problems and relates to some solutions but its't a problem/solution pattern in and of itself.

Some of the issues around being Unambiguous can be finessed, as with a DualUseUri.

trying 'navigable' in place of 'browsable'... considered 'followable'... hard to find a single word that means "useful as a key into the globally deployed information store." -- DanConnolly

• The spelling "browsable" is preferred to "browseable"

  by a 3:1 margin in Google. Alternative terms are: clickable but that only makes sense in some kinds of browsers, and retrievable but in normal English usage that would refer to the associated content, not the URI itself.

not bad, but I don't think I agree. we might as well use "explorable". (browsers: navigator and explorer). Maybe we should say Browsable/Clickable/Navigable/Explorable and listen for which terms end up getting used in conversation. "Weblike". -- SandroHawke

The word "navigable" doesn't come from Netscape Navigator. (For example, UML has the concept of navigable associations.) Also, "traversable" might be another candidate. -- Daniel Barclay

Then there's "Dereferenceable", following the language of rfc:2396. Oh, but that includes POST. -- SandroHawke

Hmmm. Connect more explicitely to ideas of SemanticWeb URIs, somehow? Some thoughts in a TAG email.

Also, narrow the gap from here to SelfAnsweringQuestion! -- SandroHawke --

Hmm... migrate URI scheme index here? Perhaps: GoodURIs use good UriSchemes.

What about the UriCrisis or Identity crisis ???

I will add this !

• URI have to indicate, where is a good place to find Metadata triples about the uri. Not only browsable, also RDF-Queryable !!!

-- LeoS