Re: Change Proposal for HttpRange-14

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

Received on Friday, 23 March 2012 16:26:32 UTC