Re: [Fwd: Re: Issue-57]

Hi David,

On Mon, Jun 27, 2011 at 8:21 PM, David Booth <david@dbooth.org> wrote:
> Oops!  I made an important mistake in my last message -- I included a
> rule in the wrong place.  Please ignore my previous message and read
> this one instead.

> As the httpRange-14 decision is currently stated,
> http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
> it does cause one to attempt to distinguish between an IR and a non-IR,
> and as we all know, that leads straight to a rat hole.  But please note
> that the nice thing about the way Jonathan has recently framed the
> problem is that it recasts the problem as a question of how to write
> metadata, and this allows one to largely side-step the IR/non-IR
> question:
> http://lists.w3.org/Archives/Public/www-tag/2011Jun/0119.html
> http://lists.w3.org/Archives/Public/www-tag/2011Jun/0130.html
>
> The crux of the idea is that instead of taking the 200 response code to
> mean that <http://128.252.39.97/SnapshotJPEG> identifies an IR (thus
> forcing you to think about whether it is or isn't an IR), instead take
> the 200 response code to imply something like the following (in n3):
>
>  {
>     ?rep h:isRepFrom "http://128.252.39.97/SnapshotJPEG" .
>     <http://128.252.39.97/SnapshotJPEG> ?p ?v .
>  }
>    => { ?rep ?p ?v . } .
>
> assuming that h:isRepFrom has been suitably defined to mean that ?rep is
> a representation (in the AWWW sense) obtained from
> http://128.252.39.97/SnapshotJPEG , i.e., ?rep is the content returned
> in the HTTP response.
>
> Some notes:
>
>  - Whether you choose to accept the above RDF is a different question.
> For example, if you think that the server has been misconfigured or
> compromised or the URI owner ignored the httpRange-14 rule, then you
> might choose to ignore this RDF.
>
>  - Notice that what's being concluded is not a simple set of statements,
> but a new rule -- a rule that allows you to make useful metadata
> inferences if you choose to accept it.  For example, if you already
> knew:
>
>  <http://128.252.39.97/SnapshotJPEG> xhv:license <http://example/l1> .
>
> and you obtained a representation ?rep from
> http://128.252.39.97/SnapshotJPEG then you could conclude that the
> license applied to that representation:
>
>  ?rep xhv:license <http://example/l1> .
>
>
> Granted, this recasting of the problem still leaves open the question of
> whether RDF data publishers should be encouraged (or to what extent they
> should be encouraged) to issue a 200 status code only if they want
> clients to draw the above conclusions.  I.e., your suggestion of
> allowing the content in the response body to override the above
> conclusions would still be on the table.  But it at least (to my mind)
> would help us avoid the IR/non-IR rat hole in that discussion.  What do
> you think?
>

There are quite a few situations where the representations of a
resource do not share its properties. For example, the generator of a
resource might be OpenOffice, but the generator of its representation
could be Apache. And of course intermediaries could be modifying the
representations along the way without permission by publisher or
consumer. For example, many mobile ISPs transcode images to save
bandwidth and even inject javascript into pages to provide tooltips on
those images saying "click image to improve quality". This risks
confusion when the representations include license information as the
end user could easily assume wrongly that the license covers the
injected script.

There is an efficiency argument here: we _could_ model the entire
message flow including all software and hardware components, naming
each stage and each transformation of information and disambiguating
them all. But unless we're doing formal provenance analysis it's a
ridiculous waste of effort.

Your rule is one approach to simplify the problem but another way
could simply be to define that behaviour at the property level. For
example, I could define a license property to mean "the subject and
all its http representations are licensed as follows". That could be
backed up with an appropriate domain, e.g. ex:InformationResource.


Ian

Received on Friday, 1 July 2011 10:18:18 UTC