W3C home > Mailing lists > Public > www-tag@w3.org > February 2012

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

From: Larry Masinter <masinter@adobe.com>
Date: Wed, 29 Feb 2012 14:17:00 -0800
To: David Booth <david@dbooth.org>
CC: Mark Nottingham <mnot@mnot.net>, "www-tag@w3.org" <www-tag@w3.org>
Message-ID: <C68CB012D9182D408CED7B884F441D4D06A8D3C68A@nambxv01a.corp.adobe.com>

> 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.

 I don't understand under what circumstances it makes sense to expect A to provide, or B to consume, some other documentation or information that might lead B to believe that "http://example.org/blah" means anything else, or how that other documentation could be persistent (= "retaining an equivalent meaning over time"), without discussing equivalence.



> I agree entirely.  The whole issue of "meaning" is an endless rat hole, and there is no need for this document to get into it.  

I don't agree at all. I think the issue of "meaning" isn't endless, it requires more elaboration, not less.

I don't agree "there is no need for this document to get into it"; rather, I think to make progress it is necessary to get into it more deeply, and acknowledge that meaning is a state of perception of individuals over time.

> The document should simply define *mechanisms* for conveying a URI definition, without saying anything at all about how that URI definition should be interpreted or what it means.

I don't think this is a productive route at all, David. Until we have a common understanding of what it means to "convey" a "URI definition", defining the mechanism won't improve interoperability.

Larry
--
http://larry.masinter.net


Received on Wednesday, 29 February 2012 22:17:30 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 12:48:45 GMT