Re: URIs, used in RDF, that do not have associated documentation

2012/4/2 Pat Hayes <phayes@ihmc.us>:
>
> On Apr 1, 2012, at 4:46 AM, Tore Eriksson wrote:
>
>>> On Mar 30, 2012, at 7:24 PM, トーレ エリクソン wrote:
>>>> <rant>My problem is that people assume that the default case is that the
>>>> HTML document "resides" (I don't know a better word, hope you understand
>>>> what I mean) on the other end of the wire, when it might just exist
>>>> locally through the octet stream.</rant>
>>
>> 2012/4/1 Pat Hayes <phayes@ihmc.us>:
>>> <rant> My problem is that some people are incredibly sensitive to things like the piddling difference between a document versus a byte stream, when at the same time they are quite happy to treat them as being in the same category as galaxies and dead Roman emperors and Platonic abstractions. There ought to be a name for this, we could call it http tunnel vision: a condition where everything in every possible universe looks like a very small piece of network architecture. </rant>
>>
>> Excuse me for being a piddling pedant with tunnel vision
>
> It was meant to be lighthearted. Sorry if it came across as an attack (Email is dangerous, of course.)

No problem.

>> , but I though
>> we *were* discussing how network architecture affects RDF. The RDF and
>> the HTTP universes are, by design, very similar.
>
> I profoundly disagree. The HTTP universe, if it can be said to have one, consists of byte streams, response codes and endpoints. The RDF universe consists of everything that can be referred to by a name, i.e. everything.

Why don't you consider resources to be in the HTTP universe? That on
caught me off guard. Both the RDF specification and httpRange-14 said
that resources denoted/identified by HTTP URIs can be anything.

>> Neither cares what a
>> resource *is*. They leave that part to the user. If the distinction
>> between galaxies and documents is that important, then why doesn't the
>> RDF specification mention it? Instead it defines a class for all
>> resource that can be mapped to a unicode string.
>
> Named by a unicode string, not mapped to it.

I see, the L2V(d) mapping gives a unicode string that denotes the resource.

>> Literals are there to
>> solve an important technical problem when serializing RDF.

> Not when serializing. They are there to fix classes of referents. The difference between "1" and "1"^^xsd:integer has to do with what those character sequences denote.

Correction noted.

>> Likewise,
>> octet streams are an essential part of HTTP. A lot of people, even in
>> this forum, mixes up "1" and "1"^^xsd:integer. This doesn't matter
>> most of the time, but I suspect it would bother you (it bothers me) if
>> people make this mistake when discussing RDF semantics.

> Yes, quite. It doesn't matter most of the time in HTTP, because HTTP does not concern itself with what messages denote. It matters a lot in RDF because RDF is concerned with that. Without that concern, in fact, there would be very little point in having RDF at all.

That seems a bit harsh. RDF works very well for talking about the
resources that are denoted by the URIs, Messages are harder though.
Let's ignore the relationship between URI target resources and
messages for now and focus on the messages.

>> Representations/octet streams are not just a very small piece of HTTP
>> architecture, they are the messages in a message passing protocol.
>
> No doubt. But HTTP does not concern itself with what these messages are *about*. Don't get me wrong: I'm not saying it should. After all, it is a transfer protocol, not an ontology language. Which is exactly my point.

It might not care what the resources are about, but it is concerned
with how to interpret messages. Media types is an important part in
HTTP messages, and as Noah explained in [1], if you want to know what
a message body with a specific media type denotes, you just have to
find the right specification. For text/html, this process lets you
know
that the message denotes a HTML document. This is what I meant saying
that the HTTP document exists locally through the octet stream.

Maybe one could model this as a variant of RDF datatypes. The
specification of a media type defines a mapping function from octet
streams to resources, L2O(m), or something like that. An interesting
consequence would then be that xsd:string and text/plain would have
almost identical maps:
<data:,A%20brief%20note> owl:sameAs "A brief note"
Neat, isn't it!

Tore

[1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments

Received on Monday, 2 April 2012 14:08:08 UTC