Re: [Fwd: Re: Issue-57]

Hi Ian,

On Fri, 2011-07-01 at 11:17 +0100, Ian Davis wrote:
> 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.

True.  When we say that the license applies to "all http
representations" that should be understood to mean "all *authorized*
http representations", since the publisher cannot be held responsible
for changes made to the representation by intermediaries during
transport.

> 
> 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.

But is there a need to talk about the license for "the subject *and* all
of its http representations"?  I think the point of Jonathan's approach
is that it is really the *representations* that one is trying to talk
about, in an aggregate way, when one writes metadata such as licensing
assertions.  So if (as you suggest) we define a license property to mean
"all of the subject's http representations are licensed as follows", I
think that may amount to the same idea that Jonathan is proposing.  Does
that make sense?  I'm not even sure what it would mean for the license
to apply to "the subject" if it doesn't mean that it applies to the
subject's http representations.  When we write a license statement,
don't we mean it to apply to the representations?  Or is it actually
intended to apply to something else in addition, and if so, what?



-- 
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 Friday, 1 July 2011 15:43:39 UTC