[Fwd: Re: Issue-57]

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.

-------- Forwarded Message --------
From: David Booth <david@dbooth.org>
To: Ian Davis <lists@iandavis.com>
Cc: Tim Berners-Lee <timbl@w3.org>, www-tag@w3.org List <www-tag@w3.org>
Subject: Re: Issue-57
Date: Mon, 27 Jun 2011 14:07:51 -0400

Hi Ian,

On Mon, 2011-06-27 at 17:07 +0100, Ian Davis wrote:
[ . . . ]
> >> <ex:i>   <fb:like>    <http://128.252.39.97/SnapshotJPEG>.
[ . . . ]
> That URI belongs to a webcam,  
[ . . . ]
> My position is that we should avoid forcing publishers to understand
> the distinction between an IR and everything else, 
[ . . . ]

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?




-- 
David Booth, Ph.D.
http://dbooth.org/

Opinions expressed herein are those of the author and do not necessarily
reflect those of his employer.

Received on Monday, 27 June 2011 19:21:38 UTC