- From: Paul Prescod <paul@prescod.net>
- Date: Wed, 30 Jul 2003 11:00:46 -0700
- To: Tim Bray <tbray@textuality.com>, www-tag@w3.org
- CC: Norman Walsh <Norman.Walsh@Sun.COM>
Tim Bray wrote: > ... The other issue you highlight > "But more important..." is real, but only requires that you have > different URIs for talking about the resource and some particular > representation. I don't think representations even come into the conversation yet. We're talking about assertions about the two resources. The HTTP responder and the person. When a SW document asserts that the identified object has moved, is it talking about the Responder moving from one URI to another or the person moving from one house to another? If it states that the resource was deleted, is the person dead or is the responder gone? Yes, it would be natural to say that the responder "represents" the person but we already have a meaning for that word. Representations are the things that go across the wire. Let's say that the HTTP resource proxies for the real-world resource. > Which you suggest, but I don't think a URI-syntax convention is called > for. Because there are a lot of other properties we're going to care > about, not just ex:WebPage or not, and we can hardly encode them all in > the URI. -Tim I think that is a non-sequiter. We aren't trying to encode properties in the URI. We're trying to make the same URI serve _two functions_ without causing semantic web ambiguities. The URI names a person (or a namespace or a corporation) and it also addresses a responder that can give us some information about that person. I can think of several solutions to the problem, only some of which use URI-syntax conventions but the point is that until the TAG nominates some particular solution as the canonical one people will debate this issue ad infinitum. Surely it is simpler to say "add a hash sign" or "use this form of a assertion" rather than spend the rest of your life on this issue. I propose you document a convention for disambiguation and move on... Paul Prescod
Received on Wednesday, 30 July 2003 14:00:57 UTC