RE: Uniform access to descriptions

> From: Pat Hayes [mailto:phayes@ihmc.us]
>
> At 12:52 PM +0000 4/13/08, Booth, David (HP Software - Boston) wrote:
> [ . . . ]
> >     Imagine that you have some information, I, that you
> > wish to provide through your Web server.
>
> [ . . . ] What do you mean by 'information' here? [ . . . ]
> Any input to a computational process has to be encoded
> in bits somehow, because bits are what computations work on.

Right.  For the purpose of this discussion, it doesn't matter how I is expressed, provided that it can be viewed as a set of distinct pieces of information, so that we can talk about RI being a subset of I, and of course provided that it is the right type for then encode/decode functions.   If you wish you could think of set I as being a set of RDF statements, for example.

> [ . . . ]
> > However, content negotion is *only*
> > for sending information that is in I.  Content negotiation is
> > *not* for sending arbitrary information (or metadata) that is
> > not already in I, such as the fact that the photograph was
> > taken by "David Booth" and the cat depicted in the photograph
> > is named "Cheshire".
>
>
> BUt if this metadata were part of I, then this would be OK,
> right?

Correct.

> So, here one is on the receiving end, and I get handed
> a lossy JPEG image and some RDF metadata about it. What
> should one do? Protest to the Gods of the Internet about this
> mis-use of conneg, or simply assume that I - to which one has
> no other access - did after all contain the metadata. The
> fact that one has not seen it before can be chalked up to the
> other kinds of lossyness inherent in the other encodings one
> had previously chosen.

Correct.  Unless you have more information about what I is supposed to contain, you won't know.  On the other hand, the owner *might* have told you, in some other document, what it was supposed to contain.

>
> The point Im getting at is that this strict doctrine which we
> keep hearing about, regarding what conneg MUST be used for
> and MUST NOT be used for, seems to be nothing but doctrine.
> There is no way to determine that it is being obeyed. If we
> all just go on assuming that it is, then some resources will
> seem to have more information in them than they previously
> seemed to have. As long as this extra information is useful,
> why should anyone complain about this outcome? To hell with
> doctrine when it ceases to be useful and becomes simply an
> encumbrance.

Hold it.  I'm not quite following your point here.  I thought the issue was that Xiaoshu was suggesting that it should be okay to use a URI to denote a non-awww:InformationResource (such as a sumo:Human) while using content negotiation to return a 200 response with either HTML or RDF.  It's perfectly fine for content negotation to return either HTML or RDF.  The only part that is *not* okay is when he tries to use that same URI to denote both a person and an awww:InformationResource.  That causes URI collision:
http://www.w3.org/TR/webarch/#URI-collision

For example, suppose a GET on URI http://example/mycat sometimes returns a 200 status with the following HTML:

        <html>
        <body>
        This is a page about my cat.
        </body>
        </html>

and, because of content negotiation, sometimes returns a 200 status with the following RDF (shown in N3):

        <http://example/mycat> a :MysteryType .

If :MysteryType is awww:InformationResource, then there is no problem.  But if :MysteryType is sumo:Human, and sumo:Human is disjoint with awww:InformationResource, then there is a URI collision, because in essense, the 200 response implicitly declared URI http://example/mycat as denoting an awww:InformationResource, whereas the RDF content declared URI http://example/mycat as denoting a sumo:Human.  In such case the URI owner has done something wrong, but whether you consider the error to be a misuse of content negotiation or something else is a matter of interpretation: however you choose to atribute the cause, the parts don't fit together.



David Booth, Ph.D.
HP Software
+1 617 629 8881 office  |  dbooth@hp.com
http://www.hp.com/go/software

Opinions expressed herein are those of the author and do not represent the official views of HP unless explicitly stated otherwise.

Received on Monday, 14 April 2008 10:51:42 UTC