Re: Understanding URI Hosting Practice as Support for Documentation Discovery: 'meaning of meaning'

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