Hi Ian,

You raise two issues: 1. Whether there is need to use different URIs for the toucan versus the toucan's web page; and if so (2) how to get from one URI to the other.

ISSUE 1: Whether there is need to use different URIs for the toucan versus the toucan's web page. Some time ago I showed that there is no *architectural* need to distinguish between the two: http://dbooth.org/2007/splitting/ (Sorry that page is a bit messy, but the reasoning is sound.) The essential reason is that the ambiguity created by using the same URI for both is not fundamentally different from the ambiguity that *always* exists when a resource is defined. Ambiguity depends on the application: a description (or "URI declaration") that is perfectly unambiguous to one application may be ambiguous to another application that needs to make finer distinctions.

For a fairly clear explanation of how ambiguity works in RDF semantics, see "Resource Identity and Semantic Extensions: Making Sense of Ambiguity": http://dbooth.org/2010/ambiguity/

However, given that many applications *will* wish to distinguish between the toucan and its web page (or between the toucan's age and the age of it's web page), it is a *good* *practice* to use a different URI for each, as recommended, for example, in both the W3C Architecture of the World Wide Web: http://www.w3.org/TR/webarch/#URI-collision and in Cool URIs for the Semantic Web: http://www.w3.org/TR/cooluris/#distinguishing

ISSUE 2: How to get from the URI of the toucan to the URI of the toucan's web page. You state that "we should link the thing to its description using a triple rather than a network response code". While I agree 100% that a triple like

<Utoucan> :isDescribedBy <Upage> .

is far more efficient than a network response code, and *should* be used when available, it is *also* useful to make the Utoucan URI dereferenceable for those times when: (a) you have Utoucan but not that triple; or (b) you wish to verify that Upage *is* the correct page for the Utoucan declaration.

Also please note that if you mint your URIs using a 303-redirect service such as http://thing-described-by.org/ then the extra network hop from the 303 redirect could be optimized away by parsing the URI, as described here: http://thing-described-by.org/#optimizing For example, you would have the relationship:

<http://t-d-b.org/?http://example/toucan-page> :isDescribedBy <http://example/toucan-page> .

so if the toucan were denoted by the URI http://t-d-b.org/?http://example/toucan-page the you know that its description is located at http://example/toucan-page and there is no need to actually dereference the other URI.

Your blog post states:

Not if you use a 303-redirect service such as http://thing-described-by.org/ and optimize them away as described at http://thing-described-by.org/#optimizing

True, but that's far better than zero, if you only have the toucan URI and it returns 404!

Yes, that's a problem. The trade-off is ambiguity.

It is trivial to mint your URIs if you use a 303-redirect service such as http://thing-described-by.org/

I addressed the server configuration issue above, but the other issue -- how do I know whether something should be considered an "information resource" or not -- does cause confusion. But in fact it boils down to the inherent problem of ambiguity that will never go away: what's ambiguous to one application may be ambiguous to another application that requires finer distinctions.

Agreed, but it can be done using a standard service, as mentioned above.

I don't buy this argument. While I agree that explicit statements such as

<Utoucan> :isDescribedBy <Upage> .

is helpful and should be provided, that does *not* mean that links are not *also* useful. Just because links do not *always* work does not mean that they are useless.

Of course you can, but you do it the opposite way:

UspreadsheetMetadata --303--> Uspreadsheet

Or in RDF:

<Uspreadsheet> :isDescribedBy <UspreadsheetMetadata> .

Yes, that is a problem.

Opinions expressed herein are those of the author and do not necessarily reflect those of Cleveland Clinic.