Re: NIR SIDETRACK Re: Change Proposal for HttpRange-14

On Fri, Mar 30, 2012 at 10:32 AM, Jeni Tennison <jeni@jenitennison.com> wrote:
>
> I see best practices as being separate from normative requirements, and thought that the proposals were for the normative requirements. We did recognise in the proposal the requirement for a best practice document to supplement the normative requirements:
>

This is a helpful discussion because I'm still trying to figure out
the right way to say what I want to say, and with each iteration I
think I come a bit closer to the point.

My opinion is that any proposal needs to specify a way to say how you
get from a resource to its content. I do a SPARQL query and find a URI
for a resource based on metadata (stored in the triple store) that
make it seem interesting; title, license, rating, whatever. Then I
want to *look at it*. What do I do? httpRange-14(a) (or its intended
stronger form) says you do a GET on its URI, and if you get a 200,
that's the content, that's what I want to look at. So that's
successful communication. If you delete HR14a, which is fine, you
need, IMO, to replace it with some other way - normative and
actionable - to express the same information, and that method has to
be provided normatively, not as a best practice. Tim's proposal does
this, my "SHOULD not MUST" proposal does, yours doesn't.

And a reminder that I *do* understand content negotation; you don't
actually get "the content" but rather "a content" or "one of its many
contentses".

The normative part would be the specification of this property; the
"best practice" would just be that you should use it, if the resource
has content on the web. Of course there are many situations where you
wouldn't use it, because you don't have the content, want to hide it,
don't want to be bothered, don't know where it is, etc. That's OK.

Sure, it's nice to be able to GET a description, as you have
specified, but that doesn't help in general, e.g. in the PICS/POWDER
use cases and what I gave above.

This is an easy fix to your proposal. You just add a normative section
that defines a property that people *may* use to provide this
information:

   <http://example/foo> baz:hasContentUri "http://example/foo-content".

or whatever you want to call it (Larry suggested 'location', I
suggested 'hasInstanceUri'). This means that to get the content do a
GET on that URI, and if the result is a 200 then you got content,
otherwise all bets are off. (Well, dealing with 301/302/307 would be
gravy.) Then the proposal will not be a net loss as far as expressive
power goes.

Opt-in to HR14a looks like this:

   <http://example/foo> baz:hasContentUri "http://example/foo".

but nobody *has* to do that.

There are problems with this idea, such as what if an agent can't
parse the particular flavor of RDF that's in use, but before we get
into that I want to see if you understand what I'm suggesting.

Jonathan

On Fri, Mar 30, 2012 at 10:32 AM, Jeni Tennison <jeni@jenitennison.com> wrote:
> Jonathan,
>
> On 30 Mar 2012, at 01:51, Jonathan A Rees wrote:
>> On Tue, Mar 27, 2012 at 6:01 PM, Jeni Tennison <jeni@jenitennison.com> wrote:
>>> Good practice would be for Flickr to use separate URIs for 'the photograph' and 'the description of the photograph', to ensure that 'the description of the photograph' was reachable from 'the photograph' and to ensure that any statements referred to the correct one. Under the proposal, they could change to this good practice in four ways:
>>>
>>> 1. by adding:
>>>
>>>  <link rel="describedby" href="#main" />
>>>
>>> to their page (or pointing to some other URL that they choose to use for 'the description of the photograph')
>>>
>>> 2. by adding a Link: header with a 'describedby' relationship that points at a separate URI for 'the description of the photograph' (possibly a fragment as in 1?)
>>
>> Sorry, I didn't get why these are said to be better practice than the
>> current Flickr page - how the document distinguishes the two cases.
>> Does it say there 'should' or 'must' be a describedby? If the info
>> resource assumption is gone, won't the Flickr page [still?] be
>> understood the way Flickr intends? I'll have to study the proposal
>> again (sorry, very hurried now, can't keep up)
>
>
> I see best practices as being separate from normative requirements, and thought that the proposals were for the normative requirements. We did recognise in the proposal the requirement for a best practice document to supplement the normative requirements:
>
>  We also recommend that a clear guide on best practices when publishing
>  and consuming data should be written, possibly an update to [cooluris].
>
> I don't see this proposal as changing the current best practice recommendations, which are to have separate URIs for documents about things from the things themselves.
>
> I'm not sure I've understood your second question, but perhaps you're saying that using hash URIs for fragments of the page that contains descriptions doesn't work when mixed with the assumption that you get the description of that hash URI by looking at the page (it gets too circular).
>
> Anyway, the fundamental point is that if Flickr decide they do want to start distinguishing between the URIs they are using (for 'the photograph'), and the page about the photograph, they can introduce a new URI (for 'the description of the photograph') and add a link to it from the existing page without having to change all their and other peoples' existing URI usage.
>
> Cheers,
>
> Jeni
> --
> Jeni Tennison
> http://www.jenitennison.com
>

Received on Friday, 30 March 2012 17:11:22 UTC