Here is an extract from an email conversation I had earlier, where U is a URI.
Likewise, Moby Dick is not a function, however X being a function from requests to responses, and the functions instantiation as a locus of computation could well be correct.
U can still identify Moby Dick, and all you do is request that X gives you a representation of Moby Dick bearing Y characteristics (content type etc), where U can be resolved to an address for X.
Bearing in mind of course that U can be dereferenced in any number of ways, and doesn't always "point to"/"address" X (stick U in a sparql query, or wayback machine for instance).
The common theme though, which I have to agree with, is that we always use a URI to refer to a source of information (static or computed), whether it's modifying it, or getting some version (representation?) of it.
A representation of information, and U refers to that information (format agnostic) and we retrieve that information by using U as name for the purpose of referencing.
So U is always used to refer to information about a thing, and that thing can be anything.
I'm interested to know, if anybody disagrees?
ps: please don't quote any specification when replying, if the specs had the answers we wouldn't have questions.
Well, I would further make use of the term 'description', because somebody likes to always assign 'representation' with a "sequence of bits". When you say "we always use a URI to refer to a source of information", then I would fully agree. Furthermore, I would use the term 'information resource' for "source of information" / "information about a thing". In its nature this is an abstract description that needs to be realized via a concrete description (which can of course be serialized in a representation). One can called concrete descriptions or representations then maybe also concrete information resources that realize and embody that abstract information resource. However, I think this leads sometimes to even more confusion. So for myself it is better to keep these abstractions in mind ;)
I think, 'description' is the issue Roy T. Fielding probably forgot to talk about in his dissertation. However, describing is the thing we mainly do. Representing in the sense from above is just a necessity.
(cf. http://infoserviceonto.smiy.org/2010/11/25/on-resources-information-resources-and-documents/)
in my opinion uri have a dual nature, can be a name, expressing a implicit prior knowledge about a entify, so we can later assign what we know and what is relevant about this entity at any moment we need. Second is somenthing, a url, :), who point to some information about entity or it's relations with the world.
I don't think this two can be separated, we can talk about second if first doesn't exists, and first is nothing without second.
I don't completely disagree
but I would still consider URI as a 'location', eg. "U identify the location of Moby Dick"
I don't see how a URI could represent a 'source of information'
(note that I consider 'information' as something that is content)
in those following cases
* root of server
* an empty directory
* the dot and dotdot reference
* the path of an executable
even if you don't consider 'information' as being content,
and take a broader interpretation of the term
using expressions like "U can be resolved to an address for X",
"U refers to that information", etc.
to me, it imply a "location"
as what kind of question does U answer: "where it is located ?"
so I agree with
"we always use a URI to refer to a source of information (static or computed), whether it's modifying it, or getting some version (representation?) of it."
but I don't think it works in all situations (eg. File System vs Server/Network)
The normative definition of what a URI belongs to RFC 3986 until it is obsoleted by some other future RFC. In particular, I would highlight two sentences from 3986.
First, the definition of a URI -
"A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource."
and second, a clarification of what a "resource" is.
"the term "resource" is used in a general sense for whatever might be identified by a URI. "
It is just an identifier.
I fully agree that "U is always used to refer to information about a thing, and that thing can be anything". And I hope I got your point ;-)
The most important word for me is "used" here. Because the URI as a string can be used as an globally unique identifier for anything. But if it is used to retrieve a representation, it is always interpreted as a identifier of an information resource.
Although it is a technically solvable problem to dereference a URI that identifies a non-information resource (303, hash), it alters the semantics of a URI. The string "http://dbpedia.org/resource/Moby-Dick" can be used as a globally unique identifier for the concept "Moby Dick". But when I make use of the string by typing it into my browser I always get back information *about* "Moby Dick". That is exactly what I expected. So why 303 here? Let's take a URI in a write scenario where I can update the information. I don't expect to alter "Moby Dick" itself, but the information the owner of dbpedia.org has about "Moby Dick". The point is here: only the party issuing the URI identifying an abstract resource has the authority to alter the information or 303 me to another resource. But there isn't such a concept of "information authority" in the thing itself.
Maybe we should use non dereferencable identifiers by intention to identify non-information resources. And use URIs only if they are a reference to an information resource. Does that break anything? I don't think so, because we only treat the two strings "http://dbpedia.org/resource/Moby-Dick" and "http://dbpedia.org/page/Moby-Dick" as a reference to the same information resource. The reference (e.g. the uuid) to the non-information resource should be enclosed in the "body" of the information resource.