On Wed, Apr 15, 2009 at 00:20, Jonathan Rochkind <[log in to unmask]> wrote:
> Can you show me where this definition of a "URL" vs. a "URI" is made in any RFC or standard-like document?
From http://www.faqs.org/rfcs/rfc3986.html ;
1.1.3. URI, URL, and URN
A URI can be further classified as a locator, a name, or both. The
term "Uniform Resource Locator" (URL) refers to the subset of URIs
that, in addition to identifying a resource, provide a means of
locating the resource by describing its primary access mechanism
(e.g., its network "location"). The term "Uniform Resource Name"
(URN) has been used historically to refer to both URIs under the
"urn" scheme [RFC2141], which are required to remain globally unique
and persistent even when the resource ceases to exist or becomes
unavailable, and to any other URI with the properties of a name.
An individual scheme does not have to be classified as being just one
of "name" or "locator". Instances of URIs from any given scheme may
have the characteristics of names or locators or both, often
depending on the persistence and care in the assignment of
identifiers by the naming authority, rather than on any quality of
the scheme. Future specifications and related documentation should
use the general term "URI" rather than the more restrictive terms
"URL" and "URN" [RFC3305].
As you can see, an URI is an identifier, and a URL is a locator
(mechanism for retrieval), and since a URL is a subset of an URI, you
_can_ resolve URIs as well.
> Sure, we have a _sense_ of how the connotation is different, but
> I don't think that sense is actually formalized anywhere.
It is, and the same stuff is documented in WikiPedia as well ;
> I think the sem web crowd actually embraces this confusingness,
No, I think they take it at face value; they(the URIs) are
identifiers for things, and can be used for just that purpose, but
they are also URLs which mean they resolve to something. What I think
you're coming at is that "something" thing it resolves too, as *that*
has no definition. But then, if you go from RDF to Topic Maps PSIs
(PSIs are URIs with an extended meaning), *that* thing it resolves to
indeed has a definition; it's the prose explaining what the identifier
identifies, and this is the most important difference between RDF and
Topic Maps (and a very subtle but important difference, too).
> they want to have it both ways: Oh, a URI doesn't need to resolve,
> it's just an opaque identifier; but you really should use http URIs
> for all URIs; why? because it's important that they resolve.
I smell straw-man. :) But yes, they do want both, as both is in fact a
friggin' smart thing to have. We all deal with identifiers all the
time, in internal as external applications, so why not use an
indetifier scheme that has the added bonus of adding a resolver
mechanism? If you want to be stupid and lock yourself in your limited
world, then using them as just identifiers is fine but perhaps a bit,
well, stupid. But if you want to be smart about it, realizing that
without ontological work there will *never* be proper interop, you use
those identifiers and let them resolve to something. And if you're
really smart, you let them resolve to either more RDF statements, or,
if you're seriously Einsteinly smart, use PSIs (as in Topic Maps) :).
> In general, combining two functions in one mechanism is a
> dangerous and confusing thing to do in data design, in my opinion.
Because ... ?
> By analogy, it's what gets a lot of MARC/AACR2 into trouble.
Hmm, and I thought it was crap design that did that, coupled with poor
metadata constraints and validation channels, untyped fields, poor
tooling, the lack of machine understandability, and the general
library idiom of "not invented here". But correct me if I'm wrong. :)
> Over in: http://www.w3.org/2001/tag/doc/URNsAndRegistries-50-2006-08-17.html
Umm, I'd be wary to take as canon a draft with editorial notes going
back 4 to 5 years that still aren't resolved. In other words, this
document isn't relevant to the real world. Yet.
> They suggest: "URI opacity 'Agents making use of URIs SHOULD NOT attempt to infer properties of the referenced resource.'"
Well, as a RESTafarian I understand this argument quite well. It's
about not assuming too much from the internal structure of the URI.
Again, it's an identifier, not a scheme such as an URL where structure
is defined. Again, for URIs, don't assume structure because at this
point it isn't an URL.
> If I get a URI representing (eg) a Sudoc (or an ISSN, or an LCCN), I need to
> be able to tell from the URI alone that it IS a Sudoc, AND I need to be able
> to extract the actual SuDoc identifier from it. That completely violates their
> Opacity requirement
I think you are quite mistaken on this, but before we leap into wheter
the web is suitable for SuDoc I'd rather point out that SuDoc isn't
web friendly in itself, and *that* more than anything stands in the
way of using them with the web. Also, having a unified resolver for
SuDoc isn't hard, can be at a fixed URL, and use a parameter for
identifiers. You don't need to snoop the non-parameterized section of
an URI to get the ID's ;
It's up to the server-side to deal with that URI and pick out the
parameters as it sees fit, not the creator of the URI (ie. the
> but it's entirely infeasible to require me to make an individual HTTP request
> for every URI I find, to figure out what it IS.
No it's not; if you design your system RESTfully (which, indeed, HTTP
is) then the discovery part can be fast, cached, and using URI
templates embedded in HTTP responses, fully flexible and fit for your
> But I just want a darn SuDoc in a URI -- and there are advantages to
> putting a SuDoc in a URI _precisely_ so it can be used in URI-using
> infrastructures like RDF, and these advantages hold _even if_ it's not
> resolvable and we ignore the 'opacity' reccommendation.
The trick isn't to do it; the trick is to have people agree on how to
do it. The mechanisms are there, ripe for the taking, but you still
need people to agree on how it's done. Off you go, start that
conversation with others that have an interest in SuDoc.
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
------------------------------------------ http://shelter.nu/blog/ --------