On 23/03/12 15:40, Kingsley Idehen wrote:
On 3/23/12 10:59 AM, Dave Reynolds wrote:
On 23/03/12 14:33, Pat Hayes wrote:
On Mar 23, 2012, at 8:52 AM, Jonathan A Rees wrote:
I am a bit dismayed that nobody seems to be picking up on the point
I've been hammering on (TimBL and others have also pointed it out),
that, as shown by the Flickr and Jamendo examples, the real issue is
not an IR/NIR type distinction, but rather a distinction in the
*manner* in which a URI gets its meaning, via instantiation (of some
generic IR) on the one hand, vs. description (of *any* resource,
perhaps even an IR) on the other. The whole
information-resource-as-type issue is a total red herring, perhaps the
most destructive mistake made by the httpRange-14 resolution.
+1000. There is no need for anyone to even talk about "information
resources". The important point about http-range-14, which
unfortunately it itself does not make clear, is that the 200-level
code is a signal that the URI *denotes* whatever it *accesses* via
the HTTP internet architecture.
Quite, and this signal is what the change proposal rejects.
The proposal is that URI X denotes what the publisher of X says it
denotes, whether it returns 200 or not.
In those cases where you want a separate URI Xrdf to denote "the
document containing the steaming pile of RDF triples describing X"
then (in addition to use of 303s) you have the option to include
X wdr:describedby Xrdf .
Thus if X denotes a book then you can describe the license for the
book and the license for the description of the book separately.
Dave
Dave,
What developer profile is going to perform the following:
1. make the relation -- at resource creation time
2. comprehend the relation -- at resource consumption time.
They don't have to. That's the point. This is removing a tax, not adding
one.
A developer who wants to use a URI to denote something can just publish
RDF at that URI and they are done. They don't *have* to enter the world
of 303's and httpRange-14.
However, *if* that developer wants to also say something about the RDF
document they have published (e.g. provenance or licensing) *then* they
have the option to create a second URI for that and relate the two by
any of the three mechanisms described (303, link header, wdr:describedby
relation).
A particular beauty of the change proposal is that it allows the
developer to take the easy path first and then, if later they find a
need to reference the RDF document itself, they can refactor to do that.
The entity URIs don't change.
Lower barrier to entry, but you don't get trapped into a corner if you
enter this way.
Dave
