Re: removing constraints on 'resource' [024-identity]

>On May 27, 2004, at 11:02, Pat Hayes wrote:
>[..]
>>BTW, the diagram cited below (Im looking at the one at 
>>http://www.w3.org/DesignIssues/diagrams/URI-space.png ) directly 
>>embodies that confusion/ambiguity very clearly. There are two black 
>>arrows at the bottom, one going from 'hypertext' to 'anchor', the 
>>other going from 'semantic Web' to 'anything'. THESE TWO 
>>RELATIONSHIPS ARE  NOT THE SAME KIND OF RELATIONSHIP. The first 
>>refers to identification on a network, and belongs in my "C' 
>>category: the second arrow is denotation, which has nothing to do 
>>with computation and belongs entirely in the D category.
>
>Yes.  The first is hypertext architecture; the second is semantic 
>web architecture.

Well, its actually SWeb semantics. Im not sure that semantics and 
architecture are the same kind of thing.

>  They are different.
>
>A warning: read the diagram carefully: it is not a venn diagram of 
>resources, but of URIs.
>Sets -- subset of URIs -- are labeled in roman text, or typewriter 
>text with syntactic constraints such as URI scheme.  Then, some 
>regions in the diagram are annotated in italic with some examples of 
>the things which can be *identified by* those URIs.

Ah. Ok, then my point is better stated thus: there are two different 
senses of 'identify' being used here. The sense in which an XHTML 
URI+localId "identifies" an anchor is not the same as that in which 
an RDF URI+localId "identifies" whatever it denotes.  One single 
URI+localID could identify an anchor in one sense and also refer to 
something completely different in the second (SWeb) sense.  The two 
relationships of 'identification' have nothing particular to do with 
one another, a priori.  Now, y'all might want to say as a matter of 
Web architecture that they *should* have something to do with one 
another, for example that they should be the same. This position has 
its merits, I agree, but (1) it would be a lot clearer if it were 
said explicitly, rather than just implied by what reads like a 
conceptual confusion; and (2) I'd like to see a case made out for it, 
as I can see some neat alternatives. For example, we could use the 
anchoring to locate a critical piece of representation which was 
intended by the owner of the URI to be definitive in identifying the 
referent (for example, a name, or a reference number, or a 
descriptive piece of text, ("the woman in a white dress who left her 
slipper at the Ball") which could be anchored and suitably labelled 
with an XML property). This might provide a semantically sound basis 
for connecting RDF markup with hypertext, for example.

BTW, aren't anchors GETable?  That is, shouldn't the pale blue area 
project down on the LHS to the bottom of the diagram?

>   It is rather squeezed.  "Anchor" should be in italics.

OK.

>>  The first is supposed, by its very nature, be computable (given 
>>the state of the network) and requires uniqueness of 
>>identification: neither of these properties hold of the second. The 
>>second can refer to anything: the first, by its very nature, 
>>cannot.  The second must be understood relative to an 
>>interpretation: the first cannot be that ambiguous but must be 
>>determined by the state of the Web.  The entire force of my 
>>extended attempt to deconstruct the confusion in the TAG 
>>architecture document can be summarized by the observation that 
>>these two relationships, shown in this diagram by identical (and 
>>parallel) arrows, are FUNDAMENTALLY DIFFERENT.
>
>Yes.

:-) Sorry if I got a little yellish there.

>Actually the arrows show in URI space the mapping from a set of URIs 
>without a hash to the set of URIs with hashes, specifically the 
>mapping in which corresponds to appending a hash and something.  The 
>syntactic relationship between the URIs is the same.

Ah, I see that point now, sorry.  The fundamentally different aspect 
is the relationship of the surrounding border to "anchor" and 
"anything", I guess: different kinds of example.

>However, for hypertext and the semantic web architecture, the

I wish you had finished that thought. I'd like to read the rest of 
the sentence.

>>  Calling them both 'identification' is not a good strategy: it is 
>>in fact little more than a pun. Applying criteria which make 
>>perfect sense for one to the other produces nonsense and confusion.
>
>No one is calling the arrow "+#localiD" "Identification". 
>Identification is the relation between the URIs mapped in the venn 
>diagram and things they are deemed to identify (as annotated from 
>time to time in italics).

Yes, got that now. I had thought that the long horizontal division 
was a split between syntax (above) and referent/resource (below). But 
my point still stands, even if it needs to be re-stated with 
reference to the diagram.

>[...discussion of denotation skipped ...]
>
>>Public discussion of http://www.w3.org/TR/webarch/ suggest that this
>>  unconstrained definition of 'resource', along with a separate term for a
>>  smaller set of "information resources" is a useful way to describe the role
>>  of URIs in Web Architecture.
>>
>>Well, it might be if the document was rewritten carefully paying 
>>attention to this distinction, and not applying advice suitable to 
>>the special case to the more general case.
>
>Yes indeed.
>
>>However, the result would be that almost the entire document would 
>>be about 'information resources'.
>
>The editor has instructions to do the edit so we can see what it looks like.

Ok, great.

Pat

-- 
---------------------------------------------------------------------
IHMC	(850)434 8903 or (650)494 3973   home
40 South Alcaniz St.	(850)202 4416   office
Pensacola			(850)202 4440   fax
FL 32501			(850)291 0667    cell
phayes@ihmc.us       http://www.ihmc.us/users/phayes