Re: Meaning of names and operations of services

noah_mendelsohn@us.ibm.com wrote:
> Larry Masinter writes:
>
>   
>> In general, it is a bad idea to design a language where the
>> meaning of a term in the language depends on the operational
>> behavior of a service.
>>     
>
> I can't tell if we agree or disagree, or perhaps in some ways both. 
> Regarding the above: wes, indeed, but I would go further.  What you say of 
> languages in general is most especially true of the Web.  I think the 
> reasons are well explored in the TAG's Self-Describing Web finding, which 
> is in near final draft form at [1], and which should be published 
> officially within a few days (in the interest of full disclosure, I am the 
> editor of that Finding.)
>
> In short, the Web has as one if its particular goals that ad hoc 
> exploration be possible.  The characteristic that you discourage for 
> languages in general is particularly harmful for the Web, I think.  The 
> whole point is that, with the Web, I should be able to stumble on a URI 
> wherever I might find it (e.g. doing a Google search), poke at it with a 
> standard operation such as HTTP GET  and in the main path case discover 
> from that representations of the resource.  As the finding describes [2], 
> I should be able to discover the correct interpretation of what I find by 
> application of specifications that are discoverable, recursively, from 
> references from the URI specification itself.
>
> So, this indirectly explains why having the same URI identify both a 
> resource and its description is bad.
>   
A URI identifies something.  What is the thing identified, a user has to 
get the representation and figure it out.  If a user intends to say that 
this is both a "resource" and a description of it, whatever the terms 
mean, then, it is both a resource and a description.  There is no 
identity crisis here either because the URI here identifies a new 
identity Resource+Description.  If you don't believe there is such a 
thing, then you don't believe it.  But it says nothing about  identity.  
We identify something by its semantic content but not by how the content 
is delivered.  This adheres to "the principle of orthogonal 
specification" and httpRange-14 in fact breaks it.

It is so strange, in AWWW (section 3.5) it says "Reference does not 
imply dereference".  But on the other hand, httpRange-14 says 
"Dereference does imply reference".  I am no logician and I know this is 
not an outright contradiction. But this is quite a logic loophole that 
most ordinary engineers won't care to put their feet in.
> As you say above, having the meaning of a URI depend on context or 
> operational details of some conflicts with this characteristic of the Web, 
> I think, with the very particular exception that anyone running a Web 
> server is obligated to serve faithful representations of a resource 
> (faithful is my term), if representations are served at all.  Still, that 
> does not make the meaning of the URI depend on operation of the service: 
> the right way to think about it is that the assignment authority 
> associates the URI with a resource.  The Web server is then obligated to 
> serve representations faithfully, if it serves at all. 
>
> So, while I agree with the quote from you as far as it goes, you imply 
> that what IANA chooses to do is therefore of low importance.  On that I 
> respectfully disagree.  The question, I think, is not whether they are 
> running some random service, but in particular a Web server that will 
> respond to HTTP GETs for the URIs identifying certain abstractions.  While 
> the meaning of those URIs does not "depend" on what the server does, it is 
> very important that the URI refer to one thing and not more, it's 
> desirable that representations be available if the resource is an 
> information resource or that a URI with descriptions be available 
> (presumably through redirection) if not, and that any representations 
> returned be faithful to the underlying resource.
>
> Whether the particular solution proposed in resolving httpRange-14 is the 
> best one is hard to say.  Whether it's practical to deploy seems to be the 
> subject of ongoing debate in various communities.  Still, I agree with Tim 
> that the costs of reopening the decision would be very high at this point. 
>  So, I think we should at least try hard to make it work.  
I don't understand the rationale here.  The cost of making httpRange-14 
to work is very high too.  Practically, 303 everywhere would already 
double the web traffic without any particular gain.  But obviously, the 
cost is not at TAG, but at the cost of the entire web community.  Then, 
show us the benefit  or the danger with real world use cases.  The above 
rational won't fly, at least not with me.

Xiaoshu
> As to returning 
> 404's, that is equally antithetical to the Self-Describing Web, in that it 
> becomes hard to find out information about resources in a standardized 
> way.  Mark Nottingham wrote yeterday [3] that:  "consensus was already 
> moving in the direction of NOT having the registered relations be 
> URIs...That means  that, to some degree, this discussion is moot."  Seems 
> so, though of course using anything other than URIs for identity raises 
> its own concerns Web-wise.
>
> Also, as an aside, in a member-only email [4] you asked some questions 
> about what the goals of the new Self-Describing Web finding might be;  the 
> answer is, in part IMO, to contribute to discussions like this.  Thank 
> you.
>
> Noah
>
> [1] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html
> [2] http://www.w3.org/2001/tag/doc/selfDescribingDocuments.html#grounding
> [3] http://lists.w3.org/Archives/Public/www-tag/2009Jan/0136.html
> [4] http://lists.w3.org/Archives/Member/tag/2009Jan/0064.html
>
> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>
>
>
>
>
>
> Larry Masinter <masinter@adobe.com>
> Sent by: www-tag-request@w3.org
> 01/30/2009 09:38 AM
>  
>         To:     "www-tag@w3.org WG" <www-tag@w3.org>
>         cc:     Lisa Dusseault <lisa@osafoundation.org>, Mark Nottingham 
> <mnot@mnot.net>, (bcc: Noah Mendelsohn/Cambridge/IBM)
>         Subject:        Meaning of names and operations of services
>
>
>
> In general, it is a bad idea to design a language where the
> meaning of a term in the language depends on the operational
> behavior of a service.
>
> Generally, this is because the meaning of the language terms
> needs to be longer-lived and more stable than any particular
> service or service guarantee, and thus independent of any
> particular service.
>
> The meaning of "describedBy" is term in a link relation language.
> The IANA web site is a service.
>
> It is a bad idea for the meaning of "describedBy" to depend on
> the long-term operational behavior of the IANA web site.
>
> In some cases, a term in a language actually makes reference to
> the operational behavior of a service.
>
> "http://www.iana.org/blargh" is a term in the URI language which
> identifies the operational behavior of the "www.iana.org" HTTP
> service for the "/blargh" path. Other languages which include the
> URI language may then give derivative meanings to the term.
> However, in a language where the meaning of "blargh" depends on
> the operational behavior of "www.iana.org" has given it a
> transient meaning.
>
> It is a *good* idea (best practice) to run services which help
> people discover the meaning of terms they haven't seen before.
> Discovery of meaning is hard. Such services are useful, but they
> aren't definitional. They aid but do not determine.
>
> The IANA registry is a registration service. The IANA web site is
> a courtesy. IANA makes information from the IANA registry
> available on the IANA web site, but the IANA web site is not the
> registry, it is merely a service run by them to make their
> registry available.
>
> I think attempts to get IANA to change the operational behavior
> of the IANA web site because it might have some effect on the
> meaning of terms in the "Link" relationship language is a sign
> that some architectural error has been made.
>
> I don't think the problem is so much with "httpRange" as it is in
> languages that assume that "best practice" is always followed and
> that web sites that exist today will exist forever. Do not put
> operational "best practice" as a requirement for having
> well-defined semantically coherent languages.
>
> Larry
>

Received on Friday, 30 January 2009 16:21:28 UTC