- From: Paul Prescod <paul@prescod.net>
- Date: Wed, 30 Jul 2003 12:49:57 -0700
- To: Bill de hÓra <dehora@eircom.net>
- CC: www-tag@w3.org
I don't understand most of what you wrote but... Bill de hÓra wrote: > Paul Prescod wrote: > > >> 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. > > That's not natural at all, to my mind. And what if the responder is a > web site, not a server? I don't follow. Web sites are served by servers. The responder is just the responder. It is a thing that listens for HTTP methods and does stuff. If RDF is to reason about these things then we need to distinguish them (whether in URI syntax or RDF assertions or otherwise) from objects that they may be proxies for like robots or human beings. > ... Norm's example works for his network, and mine. > It does make sense for many of my customers. Please, this only gets > worse through use. What stops me declaring another URI as denoting a > specific server, or cluster, or site? I don't understand anything you said there. > ... > > I vehemently do not need, or want, anyone telling me what the syntactic > convention is for distinguishing Aurelius my computer from Aurelius the > Emperor. Or Richard Harris. I don't think anyone would suggest different syntaxes for Aurelius the computer versus Aurelius the Emporer. But some would say that it would bad practice to use an HTTP URI to represent either of them and at the same time use that URI to represent an HTTP responder that proxies for them because how would you decide which properties apply to the proxy and which to the proxied object? > ... I can establish that by examining the > intersection of statement properties, (yes Pat, I know they have no > special standing), or inferring to the best possible explanation, if I > or anyone else cared to write the code, or port someone else's. Sorry. Don't understand. > ... > No, we're trying to decide if the URIs canonically denote a particular > class of entity. Well we obviously have different interpretations of what we are discussing. IMO, each URI denotes a particular entity. It is obviously bad for a single URI to address two entities. That's Fact 1. SW folks are encouraged use HTTP URIs so we can address a responder in addition to identifying a logical SW entity. Fact 2. We are using the address of one resource as the name of another resource because it is convenient and has important network effects. But what if we need to talk about the responder. What is its name? I see this as being the issue. > ... that's tricky because a) today there are no classes of > entity in web or semantic web architecture, there are just resources, There are some resources that we expect to respond to GET/PUT/POST/DELETE and other resources (like the emperor) that we do not. This strikes me as undeniable. Or to put it another way, at the HTTP level, two URIs should only be said to address the same resource if the behaviour of the two is indistinguishable in terms of HTTP messages. But at the Semantic Web level it might make perfect sense to say that these two URIs name the same resource: http://www.dictionary.com/Aurelius# http://www.encarta.com/Aurelius# Even if their HTTP behaviour is totally different. Is it equally valid to say that these two URIs represent the same resource: http://www.dictionary.com/Aurelius http://www.encarta.com/Aurelius Maybe. But if so then how do I make an assertion that says that the HTTP responder resources are actually totally different (e.g. when it comes to caching, supported methods etc.)? I really don't care HOW that assertion is made but it seems clear to me that it should be STANDARIZED and not ad hoc. > ... b) > when you do divide them, say into resources and information resources, > or servers and everything else, half the room house will disgree on the > split. Maybe so. > Personally I'm not sure the TAG has to decide anything yet. It's the > business of RDF and its descendents to take care of interpretive > functions that map URIs to resources, not an ad-hoc syntactic > conventions that came about because everyone was fed up and design by > exhaustion set in. The syntactic convention is out there and in use. The TAG merely needs to say that it works, is less confusing and causes no problems. Design by exhaustion is sometimes how it has to work. Otherwise we would still be arguing about whitespace in XML to this day. Paul Prescod
Received on Wednesday, 30 July 2003 15:50:08 UTC