- From: Bullard, Claude L (Len) <clbullar@ingr.com>
- Date: Mon, 29 Sep 2003 14:30:29 -0500
- To: 'Dan Connolly' <connolly@w3.org>, "Ian B. Jacobs" <ij@w3.org>
- Cc: www-tag@w3.org
The problem of going deeper will be increased abstraction. URI persistence is an issue of the energy budget of the system. In other words, it is an entropy quality and one could describe it in terms of entropy measures. How does one measure the 'persistence of a URI' unless it is done operationally? Do you really mean 'the persistence of the resource identified by the URI' or 'the persistence of the association of the name and the resource'? I note the request for sources on the terms 'selectors' and 'choices'. I am debating with myself on that request because I fear driving this thread to more abstract terms than the ones I had hoped to see removed. When I made the reference, it was to evoke Shannon's abstraction of the network architecture away from the semantics or meaning. It is possible to reproduce the 'choices' at the receiver without knowledge of the 'meaning' or semantics' of making the choice (a selection). The only way I know to describe this better will be as others have suggested, a layered model where it is clear that each system layer builds on the one below it. Now, what about the World Wide Web as a system distinguishes it from the network as a layer? Information space feels flimsy, but longer explanations are worse. Should the abstract of the document paint an understandable if undefined sense, or should it provide the initial set of formal terms upon which all the rest of the content relies? How formal should this document be? len -----Original Message----- From: Dan Connolly [mailto:connolly@w3.org] * URI persistence This bit about "strong social expectations" and "always a matter of policy" seems more awkward and arbitrary than it should be. It seems like there should be a simple, compelling argument from information theory and economics about URI persistence and ambiguity.
Received on Monday, 29 September 2003 15:30:31 UTC