Re: [httpRange-14] What is an Information Resource?

>On mån, 2007-12-17 at 17:34 -0800, Pat Hayes wrote:
>>  >.... I think an RDF graph is not a
>>  >document, but is an IR.  I believe that an RDF graph is pretty completely
>>  >characterized by a set of triples.
>>
>>  An RDF graph is *defined* to be a set of triples in the normative RDF
>>  spec, so your belief has some support :-)
>>
>>  >  I believe I can, with suitable
>>  >agreements between sender and receiver about the encoding (as we require
>>  >for all information transmission), I can transmit those triples with
>>  >complete fidelity, and a receiver could reproduce them with no loss at
>>  >all.  Q.E.D.
>>
>>  Hmm. You can transmit some textual encoding of the triples in a
>>  lossless way, yes. But you can't actually transmit the triples
>>  themselves.
>
>Well, you're not supposed to send the resource itself, wasn't that the
>point? You're supposed to transmit the "essential characteristics" in a
>MIME message.
>
>If RDF/XML fails to be a representation in that sense of an RDF graph, I
>must say I'm completely lost. Let's say you set up a resource
>http://example.org/myrdf and conneg between application/rdf+xml and
>text/n3 (or whatever the MIME type is supposed to be) - what is the
>resource?  How can you ever serve RDF/XML with 200 Ok?
>
>Can we please have some clarification here?

Im as confused as you are. It seems to me that 
the whole story about 'information resources' is 
muddled. I don't know what an "essential 
characteristic" is. I was just responding to the 
ideas as best I can.

I would prefer to simply say that some HTTP 
endpoints are considered to be resources, while 
others are not. The first kind should emit 200 
responses, the second kind should not. Never mind 
trying to characterize in some metaphysical sense 
exactly what makes something be one of the first 
kind or not: we will never get this perfectly 
straight, so why bother trying. We can give some 
canonical examples, to wit, web pages; but we 
have to recognize that there can be others, and 
the category has to be open-ended as technology 
keeps changing it. However, its easier to find 
examples of the second kind, viz. any 'resource' 
which cannot possibly be an HTTP endpoint. 
Examples include shoes and ships and sealing-wax, 
and cabbages and kings. And numbers and RDF 
graphs. So if an URI is intended to denote one of 
these, and if you GET that URI, you should *not* 
get back a 200 response. Everything else in the 
http-range-14 decision follows from that.

It also follows that no XML document actually 
*is* an RDF graph, which I think would also be a 
helpful fact to recognize. XML is a wonderful 
thing, but it is ultimately just a bunch of 
unicode character streams. An RDF graph, a number 
and other Platonic mathematical entities are all 
a different kind of thing. Its OK to serve 
RDF/XML with a 200 provided that we all agree 
that the URI denotes the RDF/XML, not the graph 
it is a surface notation for. And what you get 
back is a webarch:representation of that in 
exactly the same sense that what you get back 
from an HTML file is a webarch:representation of 
that HTML. There is no such thing, I suggest, as 
a webarch:representation of an RDF graph, just as 
there is no such thing as one of the number zero 
or the fourth moon of Jupiter.

Pat

>
>/Mikael
>
>
>
>
>>   Compare sending a numeral in some text, using some
>>  numerical convention, vs. sending an actual number. Maybe if
>>  'lossless' is the sole criterion, then numbers are IRs also, since
>>  the literal "123"^^xsd:number seems to be an encoding of the number
>>  one hundred and twenty three with perfect fidelity. But I'm betting
>>  that this isn't what was originally intended by the IR idea.
>>
>>  Pat
>>
>>
>--
><mikael@nilsson.name>
>
>Plus ça change, plus c'est la même chose


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes

Received on Tuesday, 18 December 2007 09:58:42 UTC