- From: Jonathan A Rees <rees@mumble.net>
- Date: Fri, 2 Mar 2012 11:20:21 -0500
- To: Larry Masinter <masinter@adobe.com>
- Cc: Mark Nottingham <mnot@mnot.net>, "www-tag@w3.org" <www-tag@w3.org>
On Wed, Feb 29, 2012 at 5:17 PM, Larry Masinter <masinter@adobe.com> wrote: > >> My feeling is that RDF is simply not used in situations where persistence matters, > > I think persistence is the crux of the issue. Party A sends a message M containing uri U to party B. Communication is working to the extent that B understands U (within M) to mean something close to what A intended it to mean, at some point in time later than when A sent the communication to B. > > In any case, it's impossible to have a conversation about whether persistence matters without a model that allows talking about persistence. > > Fundamentally, though: > > "http://example.org/blah" means something already, it means "whatever it is you reach when you talk the Http protocol to the host at "example.org" using the path "/blah". In the context of an "<a href=..."> that might also imply something about the representation that gets returned when you send a GET, and it should be interpreted differently if used within a form as the target of a submit with POST. So "http://example.org/blah" is ambiguous as to whether you're referring to its GET behavior or its PUT behavior. The meaning is "persistent" in that allowable changes are expected. Without disagreeing or agreeing with you, may I point out that there is no agreement on this point, so it might be better if you prefixed this by saying it's what you think. Roy Fielding, for example, would say (I think) that the URI "means" or "identifies" some resource, not any particular HTTP behavior. The server knows what that resource is and what various methods do with it, while the client can only guess what the resource is and just has to live with whatever incomplete knowledge they might have related to the operational behavior of methods on the (to them) unknown resource. So that's another way to talk about meaning. I also want to point out that if the question is the *intent* of the agent writing the URI in a protocol context, then what you say is correct regarding HTTP, but not regarding @href in HTML. Clearly what the sender (the writer of the HTML @href) *intends* or *wants* is to refer to a particular resource. If HTTP gives a different resource than what is intended, then someone has made a mistake - the link has to be "fixed". To support my claim, just suppose that there were some URI scheme that correctly expressed the sender's intent, say urn: or duri:, and that in general the receiver had a way to understand this intent and use the URI to get to the intended document (or perform some method on some resource). Then I claim that nobody in their right mind would ever use http: in @href in preference to this other scheme that actually worked, since HTTP could deliver the wrong resource while the new scheme would deliver the right one. You would never see href="http:..." written ever again. The reason anyone uses http: in @href and RDF is because they think this is a good enough (right compromise between precise, concise, and useful) way to express their intent. It's all we have in the current world. The intended meaning is not what the specifications say, but it comes across well enough much of the time to be useful to many people. RDF lets one write out what you *want* a URI to mean using a set of statements. If your interlocutor has seen, or will see, a description that suits you, then you can use the URI without also transmitting the clarifying description with it. In a better world maybe we would use urn: or duri: in RDF to better express intent, or rely less on discovery and more on explicit description. But instead we use http: because it more or less works and the other schemes don't. It's very easy to say RDF doesn't work because it doesn't have a persistence theory, or because the meaning of a URI in RDF (and @href) is different from its meaning in HTTP and so RDF is therefore misusing http: (and @href). This is all true. Unfortunately, in the absence of a viable alternative, we (or the RDF WG, or someone) need to document what people do now, and explain why it works, because it really *does* work in current use - I think this is empirically established. I'm not saying I've succeeded in documenting how it works, and look forward to hearing your ideas on how to do this properly. Jonathan
Received on Friday, 2 March 2012 16:20:49 UTC