- From: Paul Prescod <prescod@gmail.com>
- Date: Mon, 28 Jul 2008 10:16:54 -0700
- To: Pat Hayes <phayes@ihmc.us>
- Cc: dev <dev.akhawe@gmail.com>, "Ray Denenberg, Library of Congress" <rden@loc.gov>, "www-tag@w3.org" <www-tag@w3.org>
- Message-Id: <2843BF48-4360-402A-BB89-CA8F22D145E4@gmail.com>
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 >
Received on Monday, 28 July 2008 17:17:56 UTC