- From: pat hayes <phayes@ihmc.us>
- Date: Mon, 21 Jul 2003 13:31:38 -0500
- To: Sandro Hawke <sandro@w3.org>
- Cc: "Dan Connolly" <connolly@w3.org>, www-tag@w3.org
> > 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