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

Yes, thank you for tightening up the terminology.

###This message was lovingly handcrafted on a phone-like device###


On 28-Jul-08, at 9:15 AM, Pat Hayes <phayes@ihmc.us> wrote:

> 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/654 
>>>> xz321
>>>> 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
>