W3C home > Mailing lists > Public > public-awwsw@w3.org > May 2010

Re: [pedantic-web] Re: The OWL Ontology URI

From: Pat Hayes <phayes@ihmc.us>
Date: Thu, 13 May 2010 16:08:30 -0500
Cc: Jonathan Rees <jar@creativecommons.org>, AWWSW TF <public-awwsw@w3.org>
Message-Id: <C5312ACF-0AD9-499A-B1B7-3DC4AE8B65D7@ihmc.us>
To: Dan Connolly <connolly@w3.org>

On May 13, 2010, at 11:48 AM, Dan Connolly wrote:

> On Thu, 2010-05-13 at 10:53 -0500, Pat Hayes wrote:
>> On May 13, 2010, at 10:18 AM, Dan Connolly wrote:
>>
>>> On Thu, 2010-05-13 at 00:03 -0500, Pat Hayes wrote:
>>>> Dan, I don't think I've got my point across, and its getting lost  
>>>> in
>>>> all this confusion about information resourceness. Its really a  
>>>> very
>>>> simple point, and I can make it with a very simple example.
>>>> Suppose A
>>>> is an RDF graph, and B is an RDF/XML file which encodes/is a  
>>>> surface
>>>> syntax of/represents (choose your favorite terminology) that  
>>>> graph A.
>>>> And suppose U is a URI which "identifies" B, in the sense that what
>>>> you get back, when you do an HTTP GET using U, is a
>>>> 'representation' (in the REST sense) of B with a 200 code attached.
>>>> That is, the relationship between U and B is exactly like that
>>>> between
>>>> the URI of a web page, and the web page itself.
>>>
>>> That's perhaps a different architecture; i.e. a different way of
>>> looking
>>> at things than is in webarch and REST.
>>>
>>> A typical web page has various representations over time, and
>>> when we link to the web page, we don't link to any one of them,
>>> but to all of them (indexed by time). So (in webarch/REST) U
>>> isn't a URI for B, but for something that B represents.
>>
>> Yes, I know. But lets take a very very simple case, to make the  
>> point,
>> where the resource does NOT change over time. Many  Web resources are
>> like this; and the point being discussed here doesn't seem to depend
>> on B being dynamic in this way.
>
> OK, but even in the case where the resource is not dynamic, U
> is a URI for the resource, not for the representation.
>
>>  (Although, if it is part of the
>> nature of a REST-identifiable resource that it is dynamic, then that
>> is even more reason why an RDF graph - a mathematical set - can't be
>> one of them.)
>
> No... as far as I'm aware, a constant function is fine.
>
>>> Again, please take a look at the figure in the webarch intro
>>> http://www.w3.org/TR/webarch/#intro
>>>
>>> There we see that http://weather.example.com/oaxaca identifies
>>> a weather report (a web page) which is represented by
>>> an HTML document.
>>
>> And when that document was first drafted, I asked, what exactly IS
>> this thing called a 'weather report'? And the only answers I got
>> (other than being told not to ask such questions) were along the  
>> lines
>> of it being a computational entity which emits XHTML when prodded  
>> by a
>> GET, ie a Web page. I know in REST it is, formally, a function from
>> times to representations (of it), which is mathematically correct but
>> wholly uninformative as to what kind of thing it is, as it can be
>> applied to any function from times to anything.
>
> Indeed, REST doesn't constrain what resources are.
>
>>>> My point is simply that under these circumstances, we are pretty  
>>>> much
>>>> obliged by http-range-14, as I understand it, to say that U denotes
>>>> B;
>>>> that is, it denotes the thing it HTTP-identifies.
>>>
>>> You keep saying that, and I keep asking how you come to that
>>> conclusion. I thought perhaps using more formal terms and going
>>> slower would help, but evidently not. Oh well.
>>
>> If this understanding of http-range-14 is wrong, then please tell me
>> exactly how, and what I should understand it to mean. But please do  
>> so
>> without using the term "information resource".
>
> Umm... I don't see how that's possible. The only content of the
> httpRange-14 decision is that resources with representations
> (i.e. that give 200 responses) are information resources
> (whatever that means). Literally:
>
>   a) If an "http" resource responds to a GET request with a
>      2xx response, then the resource identified by that URI
>      is an information resource;
>
>   -- http://lists.w3.org/Archives/Public/www-tag/2005Jun/0039.html
>
> It's not a very interesting result at all; it's pretty clearly
> a paper consensus (i.e. a decision that just papers over
> the substance of the issue). I think I abstained. Ugh...
> no, I ran out of energy to even do that.
> http://www.w3.org/2001/tag/2005/06/14-16-minutes.html#item023
>
> You seem to read much more into it than is there.

Well, I am basing my intuitions on a lot more than this bare text,  
indeed. As you say, this is just papering over the cracks.
>
> It in no way licenses an inference from
>  U denotes R and R is represented by B
> to
>  U denotes B.

I wasn't making *that* inference, which seems seriously broken.

I guess my understanding of the background to http-range-14 was that  
there was what might be called a situation for the SWeb, which is the  
presence of the pre-S Web, in which URIs almost without exception  
'identify' things like websites. Which is fine, of course, but then  
along comes RDF and model theory and people talking about 'denotation'  
and so forth, and the question suddenly arises of whether these  
millions and millions of pre-semantic URIs can be said to denote  
anything, and if so, what. There were three main schools of thought.  
One was that the Web simply had no business talking about such  
philosophical matters, and should stick to good old software  
engineering, and HTTP be described purely in terms of protocols and  
architecture. I believe this is still the majority view among non- 
semantic Webbies. Another, which might be called Boothianism, was that  
when it comes to reference and denotation, URIs just are ambiguous and  
hostage to interpretation, and that the only way to establish what it  
is that they denote (as opposed to "identify") is to say enough RDF to  
nail down their intended meanings adequately. This view has a weight  
of theory behind it, but it has the embarrassing consequence that  
someone has to write enough RDF about every extant website to fix the  
appropriate denotation of all the URIs that resolve to it, before the  
SWeb can get itself kind of connected to the pre-S Web. Which of  
course is never going to happen. The third view is a kind of benign  
Stalinism, which takes the position that when we said that URIs  
'identify' Web-pagey things, back in the pre-semantic day, we did of  
course intend that this should cover reference/denotation, not just  
mere Web address resolution and GETting. So yes, **of course** those  
old pre-semantic URIs denote (in this new Semantic sense) the same  
things that they always used to, and still do, "identify". Which makes  
sense, I agree; in fact, its the only viable strategy to adopt. And  
what I understood http-range-14 to be doing was to set this idea in  
stone, with the '200-vs-303' mechanism inserted as a kind of escape  
hatch for cases where the new semantic people had gone and used URIs  
to refer to some other kind of thing, different from the kind of thing  
one GETs; things like people and dogs and numbers (though its hard to  
make a typical list, since this is almost everything in almost every  
possible universe.)

I know this isnt written down in any authoritative document anywhere,  
but I think it can probably be reconstructed from the various  
archives, if anyone were wanting to take the trouble to do so.

Pat


>
>
>
> -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/
> gpg D3C2 887B 0F92 6005 C541  0875 0F91 96DE 6E52 C29E
>
>
>

------------------------------------------------------------
IHMC                                     (850)434 8903 or (650)494 3973
40 South Alcaniz St.           (850)202 4416   office
Pensacola                            (850)202 4440   fax
FL 32502                              (850)291 0667   mobile
phayesAT-SIGNihmc.us       http://www.ihmc.us/users/phayes
Received on Thursday, 13 May 2010 21:09:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:21:08 UTC