RE: introducing URIs [was: 13 Aug Arch Doc...]

And what happens when you remove the engine from http://example.com/myCar 
and install it into
another car? It's the same engine. Seems like it might be a "cool URI" 
that shouldn't change. Yet, if
its URI includes the fragment, then its URI would have to change, breaking 
all the assertions
and references to it. You can't redirect a fragment (the engine has moved 
to Chris' car).

Cheers,

Christopher Ferris
Architect, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

www-tag-request@w3.org wrote on 08/16/2002 10:43:37 AM:

> 
> Hi Dan,
> 
> In [1] you asked me:
> 
> > Please take a look at my "introducing URIs" message to see
> > if it really looks like folly.
> 
> Well... the short answer is yes... I continue to think that redefinition 
of
> the terminology around URI would be folly (more at the very end below).
> 
> On the plus side (I think)... I believe I have come to be comfortable 
with
> the notion that URI composed with fragment id can indeed be used to 
identify
> Resources. That is elaborated below - I'd appreciate your thoughts, 
because
> the reasoning below may be flawed, and I would like to be agreeing on 
the
> reasoning as well as the conclusion. I think I also came close to
> understanding TBL's position on httpRange-14 and trip at the last 
hurdle.
> 
> regards
> 
> Stuart
> [1] http://lists.w3.org/Archives/Public/www-tag/2002Aug/0149.html
> 
> > -----Original Message-----
> > From: Dan Connolly [mailto:connolly@w3.org]
> > Sent: 13 August 2002 22:55
> > To: Ian B. Jacobs
> > Cc: www-tag@w3.org
> > Subject: introducing URIs [was: 13 Aug Arch Doc...]
> > 
> > 
> > 
> > On Tue, 2002-08-13 at 15:29, Ian B. Jacobs wrote:
> > [...]
> > > [1] http://www.w3.org/2001/tag/2002/0813-archdoc
> > 
> > "1.1 Use of terms URI and URI reference in this document
> > 
> > RFC 2396 divides the world ..."
> > 
> > Hmm... that starts from a perspective that we intend to
> > obsolete. How about starting from the other perspective:
> > 
> > =======
> > 
> > Chapter 1: Identifiers and resources
> > 
> > The Web is a universe of resources; resources are a generalization
> > over documents, files, menu items, machines, and services, as
> > well as people, organizations, concepts, etc. Web architecture
> > starts with a uniform syntax of identifiers for resources, so
> > that we can refer to them, access them, describe them, share
> > them, etc. The syntax employs an extensible set of schemes. Several of
> > the schemes incorporate established identification mechanisms
> > into this syntax:
> > 
> >    mailto:nobody@example.org
> >       mailbox names (including DNS domain names)
> >    ftp://example.org/aDirectory/aFile
> >       ftp file names (including DNS domain names)
> >    news:comp.infosystems.www
> >       newsgroup names
> >    tel:+1-816-555-1212
> >       telephone numbers
> >    urn:uuid:@@look-up-syntax
> >       UUIDs, from Apollo/DCE/COM
> > 
> > and others incorporate new naming schemes, including those
> > introduced as a consequence of new protocols:
> > 
> >    http://www.example.org/something?with=arg1;and=arg2
> >       HTTP resources
> >    ldap:@@look-up-ldap-syntax
> >       LDAP entries
> >    urn:oasis:SAML:1.0 (@@double-check)
> >       a namespace from an Oasis specification
> 
> No problem up to here... really nice.
> 
> > Indentifiers in any of these schemes can be composed with
>    ^sp
> > a fragment identifier to yield an identifier for a
> > resource that is a part of, or view on, another resource:
> 
> This begins to wriggle (maybe)... at the very least this suggests that 
the
> sort of thing identified by a URI composed with a fragment identifier is 
a
> specialisation of the sort of thing that a plain URI identifies. The 
former
> is 'constrained' to identify a resource that is either "part of" another
> resource or a resource which is a "view on" another resource. For there 
to
> be no specialisation here, for the resource identified by the URI#frag
> composition to be fully a first class resource, all resources would have 
to
> be "part of" or a "view on" to some other resource (and maybe that is 
also
> the case... up to some 'Top').
> 
> I tried to discuss some of this with a colleague locally we got round to
> using Cars as an example to discuss this stuff to see where we get to... 
so
> bear with me... I'm not sure where this will conclude...
> 
> Maybe we can think of the #1 piston of the engine of Dan's car. I've 
chosen
> "Dan's" car because we can perhaps also explore in the in the context of
> httpRange-14 which question whether or not it is legitimate to identify 
a
> car with an absolute HTTP URI. We can consider both cases below. A car 
is
> also interesting because we can think of it in real-world terms with 
VINs on
> chasis, engine numbers on engine blocks, and maybe batch and serial 
markings
> on individual pistons.
> 
> Case 1
> ------
> http://example.com/myCar       identifies a particular Car.
> 
> http://example.com/myCar#engine   identifies the engine in the car 
identified
> by http://example.com/myCar.
> 
> http://example.com/myCar#piston1   identifies the #1 piston (in the
> engine) in the car identified by http://example.com/myCar.
> 
> 
> That the piston and the engine are part of the car is evident from their
> respective identifiers. That the piston is also part of the engine is 
not
> evident from the identifiers... but I could 'mint' another identifier 
for
> the engine, and identify the piston as part of the engine. Hence:
> 
> http://example.com/myCar/engine   also identifies the engine in the car
> identified by http://example.com/myCar.
> 
> http://example.com/myCar/engine#piston1
>                   also identifies the #1
> piston in the engine in the car identified by http://example.com/myCar.
> 
> 
> Similarly, if there were parts of a piston to speak of then we could
> 'promote' the piston to having a URI such that:
> 
> http://example.com/myCar/engine/piston1
>                   also identifies the #1
> piston in the engine in the car identified by http://example.com/myCar.
> 
> Note that the 'equivalence' of the multiple identifiers of the piston is
> only asserted by the authority that assigns the URI. It is not a general
> property of URI syntax that replacement of a '#' with a '/' results in 
two
> identifiers that identify the same resource, but it is a convention used 
in
> this example.
> 
> Case 2
> ------
> http://example.com#myCar
>    identifies a particular Car.
> 
> Now I'm stuck...! How do name the engine in a way that reflects that it 
is
> part of the Car? So... scratch the above and go postfix (shouldn't be 
hard
> for some one from HP).... Start again:
> 
> http://example.com/myCar#
>    identifies a particular Car.
> 
> http://example.com/myCar#engine
>    identifies the engine in the car identified 
>    by http://example.com/myCar#
> 
> http://example.com/myCar#piston1
>    identifies the #1 piston (in the engine) in 
>    the car identified by http://example.com/myCar#.
> 
> 
> And as before we can 'prompt' fragments into a URI so that we can 
further
> fragment the fragment, hence:
> 
> http://example.com/myCar/engine#
>    also identifies the engine.
> 
> http://example.com/myCar/piston1#
>    also identifies the #1 piston.
> 
> and
> 
> http://example.com/myCar/engine/piston1#
>    also identifies the #1 piston.
> 
> The 'equivalence' of various of these identifiers again is assured by 
the
> assigment authority and *not* the URI syntax.
> 
> This also provides scope to ask... so what to http://example.com/myCar,
> http://example.com/myCar/engine etc. identify... and the assignment
> authority might reply... well that's easy... they identify documents 
that
> describe the various things identified by extending each identifier with 
a
> '#'. 
> 
> However, this does then leaves the ambiguity about whether
> http://example.com/myCar#engine identifies a part of a car or a part of 
a
> document. Hmmm I think that the balloon just bulged somewhere else.
> 
> Conclusion
> ----------
> With case 2 I was beinging to feel that I understand where TBL is coming
> from on httpRange-14... however I was disappointed to end in an 
ambiguity.
> 
> With case 1, a part, SP, of a part, P, of a resource, R, can realily be
> identified as a part of R. But to refer to SP as a part of P requires 
that P
> also be identified by an independent URI.  The equivalence of the URI of 
P
> and the compostion of the URI of R with the fragment identifier of P is
> assured only by the assignment authority and cannot be deduced from the 
URI
> syntax of the identifiers.... which are opaque in general (by design).
> 
> --
> 
> Sorry that was so long... I found it useful... apologies if you do not. 
I'd
> be interested in your thoughts. Clearly a car, its engine and a piston
> within that engine are all resources... case 1 does seem to work... and 
the
> simple conclusion is that in order to identify a part of something as a 
part
> of that something the URI reference, the something needs to be 
identified
> with URI (no fragment).
> 
> I would have liked case 2 to have worked... it was doing fine until I 
answer
> the question of what the plain URI (might) identify. Maybe there is a
> different answer eg. they don't identify anything which makes case 2 
work.
> But I think it then makes the two cases equivalent with infix and 
postfix
> use of the '#' and a need to adminsitratively assign distinct URI to
> resources and documents (also resources) that describe those resource.
> 
> --
> 
> Ok... real bottom line is that I have convinced myself that a 
URI+fragment
> can reference a resource (case 1). Queue the counter arguments.... :-)
> 
> >    ftp://example.org/aDirectory/aDocument#section1
> >    http://www.example.org/aList#item1
> >    http://www.example.org/states#texas
> > 
> > Note that while this composition is syntactically fully general,
> > many cases such as mailto:nobody@example.org#abc
> > don't make much sense to any deployed software or
> > specifications.
> > 
> > To summarize, a <dfn>Uniform Resource Identifier</dfn>, or
> > <dfn>URI</dfn>, is a
> > character sequence starting with a scheme name, followed by
> > a number of scheme-specific fields, optionally
> > followed by a fragment identifier.
> 
> Personnally I continue to prefer that we align our terminology with 
RFC2396
> and use that terminology precisely and carefully. And... despite the 
above I
> do believe that it would be folly to redefine the term URI in a way that 
is
> inconsitent with RFC 2396 or its successor. *IF* a successor to RFC2396 
were
> to make such a terminological change, I would be 'ok'ish for the TAG's
> Architecture to follow suit... BUT I think that such a change would be a
> huge diservice those who in the past have been careful in their use of 
the
> URI/URI reference (and same-document reference) terms. I think the 
likely
> maintenance impact on existing specifications that have carefully got it
> right should be objectively evaluated by those who advocate such a 
change (I
> was going to say doesn't bear thinking about, but that's more emotional 
than
> rational).
> 
> So... yes I continue to think such a change in the use of tersm is 
indeed
> folly.
> 
> > This URI syntax is accompanied by a shorthand
> > <dfn>URI reference</dfn> syntax.
> > A URI reference is an abbreviation of a URI that can be expanded
> > by combining it with a base URI. For example, in a document
> > whose base URI is http://example/dir1/dir2/file1 ,
> > the URI reference ../file2 abbreviates http://example/dir1/file2
> > and the URI reference #abc
> > abbreviates http://example/dir1/dir2/file1#abc.
> 
> The latter I think is wrong, #abc is a same document reference is is 
*not*
> evaluated with respect to a base URI [RFC2396 see Sections 4.2 and 5.2].
> 
> Again, I would request the use of the RFC2396 terms "Relative URI" and 
"Same
> Document Reference"... yes the identifiers in your example are URI
> References too... but is the "Absolute URI" that you used as a base URI.
> Mixing these up going forward will, IMO, add confusion rather than
> clarification.
> 
> > [[NOTE: The current URI specification, RFC2396, uses a more
> > constrained definition of the term URI; by that definition,
> > identifiers that include fragment identifiers are not URIs.
> > The TAG intends to request a revision to RFC 2396 to adopt
> > the less constrained definition used here.]]
> > 
> > =======
> > 
> > then continue with 1.2 Resources and URIs.
> > 
> > 
> > > [2] http://www.w3.org/2001/tag/#tag-attn
> > > -- 
> > > Ian Jacobs (ij@w3.org)   http://www.w3.org/People/Jacobs
> > > Tel:                     +1 718 260-9447
> > -- 
> > Dan Connolly, W3C http://www.w3.org/People/Connolly/
> 
> 
> regards
> 
> Stuart
>