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
>namespaces.
>
>>  I understand this position, you are saying that all HTTP URIs identify
>>  *documents*, that is to say all resources which are directly 'on the web'
>>  and who are identified by HTTP URIs are documents.
>
>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' ? Suggestion, though: don't 
say 'denotes'. Instead say something like "indicates", ie use a word 
that doesn't have a direct semantic connection, and then use that 
term in a purely architectural sense. That can be done clearly and 
unambiguously without getting architecture and semantics with their 
knickers in a mutual twist. Then, later, we can link the semantics to 
this purely architectural term. For example, it may be that what the 
URI is understood to actually denote can be left open, but what is 
said is only that the URI's RP delivers a representation  of it, 
whatever it is (HTML); for other purposes, we can impose extra 
semantic conditions on that representation (RDF et. seq.); for yet 
other purposes, we might have the denotation depend on the MIME type, 
or specified by the protocol (URNs), or whatever. But all of these 
are in some operational sense 'functions of' the core information 
than comes out of the RP indicated by the URI; and that RP is indeed 
uniquely globally specified by the URI itself, as a Web architectural 
requirement. This lets us do things like distinguish between 'wild' 
RPs (deprecated) and 'coherent' RPs (which are such that one can 
identify an enduring thing that the representations they emit all 
denote, as required to conform to the REST design.) Then its clear 
how to make sense of, say, a URI which used to get you to a web 
travel service but now just brings back a piece of HTML saying 'this 
URI is no longer in use'. We don't have to insist that there is a 
strange abstract 'resource thing' that lies behind this change 
without itself altering its True Identity; all we have to do is say 
that the RP still emits representations (arch.) but their content 
(seman.) has changed. Semantics do change, though: that's life.

>  I think all the other theories can be built out
>from this one, but jumping straight to the others over this one makes
inaccessible something vital. 

I almost agree.

>I see the appeal of "documents", but I
>prefer to think of the document as something delivered to the client
>by some server handling that ResponsePoint.

Ditto.

>
>I'm interested in any practical use of HTTP URIs which doesn't fit
>into this model.  (cc www-archive, not www-tag, please).
>
>>  I just can't reconcile this by accepting that an 'XML Namespace' is a type
>>  of 'document'. Do you think that the XML Namespaces REC ought be modified to
>>  deprecate namespace names which are not URI references? Do you believe the
>>  Web Architecture ought be documented based on its empirical existence or
>>  based on a grander design?
>
>We can reconcile these views by saying that Namespace URIs do NOT
>denote Namespaces.  They "indicate" them or something; they map to
>them via some other function.

I'd suggest the other way round.

>
>However, it doesn't matter, because we can just avoid the whole
>question of what the namespace URI identifies or denote.  We don't
>need no stinkin' "resources".

:-)

>  The namespace URI simply lets agents
>get to information which is in some sense official or authoritative
>(and hopefully useful and relevant) for working with XML documents
>using that namespace URI.  It would sure be nice if we had some good
>standards for agents to follow in doing this.  [ cf RDDL of course ]
>
>My use of "official" or "authoritative" is of course controvercial and
>more constraining than the Namespaces Recommendation.  But if we want
>XML to live up to its implied promise of cross-application
>interoperability, then we need the semantics to come from somewhere,
>and I don't know how else we could make this work.   It's fine to have
>a thousand flowers offering semantics associated with a namespace, but
>if we don't pick one (eg via URI dereferencing), then I don't see us
>achieving interoperability.

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*. That can be a very weak 
constraint, particularly if one of us is only using the URI to do 
something very simple involving a very weak semantic framework (such 
as RDF).

Pat

>
>      -- sandro
>
>[1] http://esw.w3.org/topic/ResponsePoint


-- 
---------------------------------------------------------------------
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 14:31:42 UTC