Re: Private naming conventions and hypermedia (was Re: Draft minutes from TAG telcon of 2008-07-24

At 9:49 AM -0700 7/27/08, Paul Prescod wrote:
>On 25-Jul-08, at 11:48 PM, dev <dev.akhawe@gmail.com> wrote:
>
>>
>>>(1) and (2) are replications of the resource identified by the abstract
>>>identifier (3).   They may be identical (and then again they may not), but
>>>by what definition of "resource" are they the same resource?
>>
>>Am I wrong in thinking that if two resources have the different URI
>>they are different ?
>
>Yes, you are actually wrong. In general, URIs tell us nothing about 
>resources, including whether two of them are "really" the same 
>thing. One use for semantic web technologies is declarations of 
>resource equivalence.

Um... gentlemen, I think I know what you are saying, but you are 
saying it wrong. If there are TWO resources then of course they are 
not the same thing (because if 'they' were the same, there would only 
be ONE of them.) The question is, can two different names (in this 
case, URIs) /denote/identify/be the name of/ one and the same thing 
(resource)? And the answer is, yes, they can. So one cannot conclude, 
from the fact that one has two different names, that one is talking 
about two distinct things. The 'unique name hypothesis' is not 
generally true on the Web.

>
>>We really don't care about whats the actual
>>content inside is , do we ? Aren't you loosing the resource
>>abstraction if you try and go deeper inside what each resource
>>represents / returns /  whether its replicated or not etc. ?

No need to go 'inside' the resource. The question arises when 
resources are considered to be completely atomic and opaque. It has 
to do with the relationship between the names of resources and the 
resources themselves. You have to bear in mind that the name (more 
generally, representation) of the resource is not the resource. This 
has been said many times in many other contexts (Korzybsky 'General 
Semantics': "the map is not the territory"; Rene Magritte "Ceci n'est 
pas un Pipe"; Tarski: 'In order to speak of a thing, we must use a 
name of that thing'). Getting this wrong is so common that it has a 
name: use-mention confusion. Best avoided, though.

Pat Hayes

>
>If hypermedia or some other framework licenses the client to treat 
>two URIs as equivalent then the client can do so.
>>
>>>Can you offer a suggestion that meets the requirements of the
>>>applicant and also preserves the benefits of an HTTP URI?
>>
>>Although I don't know the requirements, ...
>
>The requirements have been stated and summarized and re-summarized.
>
>>I will say that whatever be
>>the requirements it is always better to use hyper links than hard code
>>any sort of state transition at the client side (i.e hard code an
>>assumption at client side).
>
>Application state transitions are not being discussed as far as I know.
>
>>
>>
>>Thanks
>>Devdatta
>>
>>
>>
>>2008/7/25 Ray Denenberg, Library of Congress <rden@loc.gov>:
>>>
>>>I don't believe that:
>>>
>>>(1)   http://loc.gov/ark:/12025/654xz321
>>>(2)  http://rutgers.edu/ark:/12025/654xz321
>>>(3)  ark:/12025/654xz321
>>>
>>>Identify the same resource.
>>>
>>>(1) and (2) are replications of the resource identified by the abstract
>>>identifier (3).   They may be identical (and then again they may not), but
>>>by what definition of "resource" are they the same resource?
>>>
>>>As I see it, if you (hypothetically) were to resolve  ark:/12025/654xz321
>>>then you are happy to get any replication.
>>>
>>>But http://loc.gov/ark:/12025/654xz321  resolves to the replication (of the
>>>abstract resource identified by ark:/12025/654xz321) that resides at
>>>loc.gov.   (Please see "aside" below.)
>>>
>>>And http://rutgers.edu/ark:/12025/654xz321  resolves to the replication (of
>>>the abstract resource identified by ark:/12025/654xz321) that resides at
>>>rutgers.edu.
>>>
>>>(Aside: loc does not participate in ARK, the ARK specification mistakenly
>>>lists loc. But for discussion sake consider this a valid example.)
>>>
>>>So as I see it, (1) and (2) are different resources.  And (3) is a third
>>>distinct resource.
>>>
>>>--Ray
>>>
>>>
>>>----- Original Message -----
>>>From: "Mark Baker" <distobj@acm.org>
>>>To: "Henry S. Thompson" <ht@inf.ed.ac.uk>
>>>Cc: <www-tag@w3.org>
>>>Sent: Friday, July 25, 2008 12:41 PM
>>>Subject: Private naming conventions and hypermedia (was Re: Draft minutes
>>>from TAG telcon of 2008-07-24
>>>
>>>>
>>>>>HST [...] I think there's a fundamental issue we need to be clear on: is
>>>it OK for a group of domain name owners to agree a naming convention amongst
>>>themselves? In the ARK case, this trespasses on the WebArch advice wrt
>>>aliasing, and in general might also seem to fall foul of the whole business
>>>of URI opacity (that was Mark Baker's particular concern).
>>>>
>>>>"URI Opacity" is a term that I've found means different things to
>>>>different folks, so I try to avoid it now.  But I do believe that
>>>>private naming conventions do cause harm to the Web because they are
>>>>essentially a proprietary form of link and link metadata.  If two URIs
>>>>at different domains identify the same resource, dereferencing one of
>>>>them should provide a declaration (Link header, RDFa, whatever) that
>>>>the resource is the same (owl:sameAs or equivalent) as the other.
>>>>
>>>>>From a REST perspective, the architectural constraint that's being
>>>>disregarded by this practice is "hypermedia as the engine of
>>>>application state", and IMO, it's the constraint most responsible for
>>>>imparting Web-nature.
>>>>
>>>>Cheers,
>>>>
>>>>Mark.


-- 
---------------------------------------------------------------------
IHMC		(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32502			(850)291 0667    cell
http://www.ihmc.us/users/phayes      phayesAT-SIGNihmc.us
http://www.flickr.com/pathayes/collections