RE: 13 Aug Arch Doc available for review

Hi Dan,

> -----Original Message-----
> From: Dan Connolly [mailto:connolly@w3.org]
> Sent: 14 August 2002 19:52
> To: Stuart Williams
> Cc: 'Ian B. Jacobs'; www-tag@w3.org
> Subject: RE: 13 Aug Arch Doc available for review
> 
> 
> On Wed, 2002-08-14 at 13:07, Williams, Stuart wrote:
> [...]
> > URI and URI References
> > ----------------------
> > 
> > [skw-2002-08-14-02]
> > 
> > I am very wary of the attempt to redefine the terms URI at the end of
> > section 1.1. I think the terms URI and URI reference have been a source
of
> > problems in the past and will likely be a source of problems to come.
But
> > IMO, the definition of TAG-URI =  AbsoluteRFC2396URI+OptionalFragment
will
> > make this document almost unreadable to anyone with a deeply infixed
notion
> > of URI based on current conventional usage.
> 
> I think I can count the number of people that know that
> 	http://example#foo
> isn't a URI on my fingers. OK, maybe I need my toes.

So somewhere between 2^10 and 2^20 then... fine motor control over my toes
is a little lacking ;-) 

[Oh and if the number is less than 9 the TAG certainly has a problem :-)]

I think anyone who has made or is making a serious attempt to get their head
around the architecture of the web (rather than simply use the web from a
browser) has encountered these terms and has indeed tried (and probably to a
large extent succeeded) in understanding the syntactic relationship between
AbsoluteURI, RelativeURI and URIReferences... and to some extent the torture
history of URL, URN and URI.

> (Keep in mind most people have never even heard of a URI;
> they hurl URLs around, or just talk about web
> page addresses).

So... what web page is addressed by:
http://www.w3.org/2001/tag/2002/0813-archdoc#Intro ?

Is it the same web page that is addressed by:
http://www.w3.org/2001/tag/2002/0813-archdoc#identifiers ?

> And I agree that the  $Date: 2002/08/13 20:19:49 $  draft
> doesn't help much: it assumes that you've got your
> head around RFC2396, and then throws you a curve-ball.
> 
> But there is, I think, a fairly simple and appealing
> architectural view in which http://example#foo
> is in the same class as http://example, but
> ../foo is in a very different class from
> http://example#foo . Does this rendition of it appeal to you?

Well... maybe... its worth exploring a bit... but you've also introduced
another troublesome word, 'class', which might solve a 'problem' or may just
be a symptom of the balloon bulging in a different place. I'd also have to
ask, when speaking of 'class' are we speaking of the 'class' of the
identifiers or the things that the identifiers identify... so,
http://example#foo, http://example and ../foo are all URI references, the
first two share a common absolute URI and the third one is a relative URI.

If we are speaking of the 'class' of the referenced thing... there seem to
be two views:

a)  i) The 'class' of thing identified by an absolute or relative URI is a
Resource (or choose another term of the same concept).
   ii) The 'class' of thing identified by a URI reference that contains a
fragment id is not a Resource, and we have no established term for what that
'class' of thing is. Candidates for that class of thing have been, 'item',
'sub-resource', 'part' and even 'fragment'.

b) i) The 'class' of thing  identified by a URI Reference is a Resource.
  ii) Some characteristics of a Resource vary depending on whether or not
the is an unescaped '#' character in the URI Reference used to identify the
resource [haven't got this right... but there is something of this ilk.].


>   introducing URIs [was: 13 Aug Arch Doc...]
>   Dan Connolly (Tue, Aug 13 2002) 
>   http://lists.w3.org/Archives/Public/www-tag/2002Aug/0138.html

Haven't got to this one yet in crunching the backlog from vacation... 

> [...]
> 
> > [skw-2002-08-14-03]
> > 
> > I am also very wary about asserting that the thing identified by
> > URI+fragment is a resource (which is what happens once you accept the
> > redefinition of URI). On one level I could live with it justified on the
> > basis that anything with identity can be a resource (RFC 2396 says
something
> > like that). 
> > 
> > However, resources can have fragments,
>
> Be careful with your quantifiers. To be clear, yes,

I think I was being careful in chosing the word 'can', but I agree with your
elaboration below which makes the meanin of 'can' very precise.

> 
> 	There exists resources R and F such that F is a fragment of R.

Yes... this (above) *is* what I meant.

> 
> but *not*
> 
> 	For all resources R, there is a resource F such that
> 	F is a fragment of R.
> 
> let alone
> 
> 	Given a URI I for a resource R, there exists a resource F
> 	and a URI J, computed from I alone, such that I identifies F
> 	and F is a fragment of R.


> 
> > and if I have a resource identified by the URIRef 
> > http://example.com/someResource#otherResource, how do I
> > reference a fragment of that resource (assuming it has one)?
>
> OK, assuming it has one, I can coin a new URI
> 
>  mid:2002-08-14.thismessage@w3.org#abc
>	(pretend that's the MID for this message)
>
> to refer to it.

But that's tant amount to saying that to make it a Resource (so that you can
refer to some further nested fragment within it) you *have* to give it
assign it a URI. [I accept that you wouldn't have to do that for 'resources'
were not fragmented further.]

> > The URI syntax
> > does not provide me a way to do that...
> 
> Depending on how you meant the quantifiers in
> your sentence to work, either (a) yes, it does, see above,
> or (b) no, it doesn't, but who cares?

Well if I know the identifier for R eg.
http://example.com/someResource#otherResource and I know the fragment, F, of
R that I want to reference, say 'someFragment' RFC 2396 does NOT give me a
way to construct an identifier for the Resource F from the identifier for R.

Or... maybe it does *iff* independently F is also a fragment of the
resource, Q, identified by http://example.com/someResource. Then
http://example.com/someResource#someFragment is an identifier for F. We do
lose the notion of being able to parse out the 'containment' relationships
beyond the top level - but maybe that is not important (cf. pwd - where am I
now?).

Hmmmm.... I need to chew on this some more. Maybe my comfort levels will
improve :-)

> > so maybe one heads off may be to map
> > the name of this resource into some new URI scheme eg.
> > resource:http://example.com/someResource?frag=otherResource so that it
can
> > now attract further fragment IDs. The particular design would need more
care
> > so that it would recurse nicely. But that feels like a horible kludge.
> > 
> > Anyway... bottom-line. On the TAG telcon, we did discuss distinguish
between
> > the sort of thing that a URI references and the sort of thing that a
> > URI+fragId references. I think there was consensus (although I'm not
sure we
> > really tested it) that need distinguish terms for the referent...
>
> I got the impression we were headed the other way.

I probably lost track of the conversation... somewhere there was the notion
of UII's (Universal Item Identifiers), initially with 'items' being the sort
of thing referenced by URI+fragmentId. But there seemed to be some desire to
call such things 'resources' and then a dangling question of what then to
call the things referenced just by absolute or relative URI. I don't think
we really closed on whether there were one or two concepts that needed
names. The single concept case is easy... its a resource. The two concept
case is harder because of a desire on the part of some to switch 'item' and
'resource' and then find a better term for 'item'.

> > but I
> > think it would be folly to use the term 'resource' to denote the sort of
> > thing referenced by a URI+Frag since that is commonly held to be the
sort of
> > thing that is referenced by a URI.
>
> Please take a look at my "introducing URIs" message to see
> if it really looks like folly.

Next on my to do list... but that will be tomorrow (at the earliest).

>  -- 
> Dan Connolly, W3C http://www.w3.org/People/Connolly/

Regards

Stuart

Received on Thursday, 15 August 2002 13:12:58 UTC