W3C home > Mailing lists > Public > www-tag@w3.org > July 2003

RE: [httpRange-14] empiricism was Re: resources and URIs

From: pat hayes <phayes@ihmc.us>
Date: Mon, 21 Jul 2003 22:07:55 -0500
Message-Id: <p06001a0fbb4258c684f7@[]>
To: "Bullard, Claude L (Len)" <clbullar@ingr.com>
Cc: www-tag@w3.org

>  >>My current thinking is that HTTP URIs most directly denote
>>>ResponsePoints [1].
>>That is the best idea Ive heard so far.  Is that consistent with
>>Tim's idea of an 'information resource' ?
>It's consistent with Joshua Allen's comments last year
>that a 'resource is a hypertext dispenser'.

:-) though I'd rather say, a *representation* dispenser.

>I don't
>know if it is more revealing than that but it is certainly
>the common assumption right up there with a 'resource is a
>server'.  Does it help the architecture document to know that
>or is it a qualification of a use of a URI in a context?

All of this sounds very like the idea that 
resources are the things on the network which 
emit representations in response to transaction 
queries. (Roughly, that is, modulo a lot of 
complexity about virtual machines and endpoints 
and so on.)  Again, if the TAG group would say 
this clearly and unambiguously, or else deny it 
equally clearly, that would greatly cut through 
the fog.

>  >No, look. Interoperability does NOT require that we pick a single
>>fixed semantics. All it requires is that your semantics for the URI
>>and my semantics for it are *compatible*.
>Umm... the syntax for The URI is it's semantic.

I don't follow what you mean. Maybe we are using 
the word "semantics" differently (??)

>Past that,
>a different system and therefore different semantics are the
>basis of interoperation.  How far 'compatibility' gets one is
>different system by system.  Reliability differs by proof so
>in that sense, you are right.

I don't think that is quite what I meant, 
however.  I wasnt meaning to suggest that we all 
use different notions of proof.

>  I don't know if that helps to
>get a web architecture document completed because so far,
>there isn't a definition for the Web that meets everyone's
>different notions of proof.  The Web architecture document
>is supposed to be that definition, I hazard, but the process
>of creating that won't close without a definition for 'done'
>and without some assertion/proof boundaries, that won't happen. 
>I suspect URIs are bigger than the web because they are
>used off the web too.  A URI on a billboard is not a
>resource on a web.

Good point.

>It is a syntactically correct URI
>on a billboard.  One can say it is part of the web but
>that is silly on the face of it; it is far simpler and
>just as correct to say it is a non-web system using
>a URI for whatever it does, but the web architecture
>being a system architecture, doesn't care.

I tend to agree. URIs in themselves are just 
strings with a certain syntax, after all.


>-----Original Message-----
>From: pat hayes [mailto:phayes@ihmc.us]
>Sent: Monday, July 21, 2003 1:32 PM
>To: Sandro Hawke
>Cc: Dan Connolly; www-tag@w3.org
>Subject: Re: [httpRange-14] empiricism was Re: resources and URIs
>>   > http://www.w3.org/1999/XSL/Transform
>>>   http://www.w3.org/2000/svg
>>>   http://www.w3.org/2001/XMLSchema
>>>   Now we have 3 URIs created by the W3C over the course of 3 years. The
>>>   representations obtained on dereferencing the URIs state that these are
>>>   intended to be "XML Namespaces"
>>But they state it in English, thank goodness, so we have some wiggle
>>room.  If they said it in RDF we might have to conclude they were
>>simply false, since they were logically inconsistent with our
>>ontologies (yours and mine at least) of XML Namespaces.
>>It being English, we can read "This is an XML namespace defined in..." as
>>"This is the offical page of information about the XML namespace
>>... defined in ...".   Of course that level of self-description is a
>>bit silly, but it might be necessary while people are figuring out
>>>   I understand this position, you are saying that all HTTP URIs identify
>>>   *documents*, that is to say all resources which are directly 'on the
>>>   and who are identified by HTTP URIs are documents.

IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes
Received on Monday, 21 July 2003 23:07:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:56:00 UTC