RE: Late last-call comment on AWWW

At 11:50 06/10/04 +0300, Patrick.Stickler@nokia.com wrote:

>In short: "secondary resources", or resources which are solely
>denoted by URIrefs with fragment identifiers ("secondary identifiers"),
>are second class citizens of the web, and users should be made
>well aware of that fact.

I have to disagree with that.  Recall:

   A Resource is anything that can be identified by a URI

Now, it seems to me, that is something can be identified by a URI+fragment, 
then it manifestly can also be identified by a 
URI-sans-fragment.  Therefore, there is no such thing as a second class 
citizen of the web in the sense that you describe.

I think that here you are falling prey to the exact same concern that I 
expressed w.r.t. AWWW:  that the nature of a resource was being confused 
with the nature of the identifer used to refer to it.

#g
--

> > -----Original Message-----
> > From: public-webarch-comments-request@w3.org
> > [mailto:public-webarch-comments-request@w3.org]On Behalf Of ext
> > Sent: 06 October, 2004 11:45
> > To: gk@ninebynine.org; public-webarch-comments@w3.org
> > Subject: RE: Late last-call comment on AWWW
> >
> >
> >
> >
> > > There is one more that I will mention.  I'm dashing this off
> > > hurriedly
> > > following a plane journey, so this may not be very well expressed...
> > >
> > > In section 3.3.1, I feel the terminology concerning
> > > "secondary resources"
> > > is muddled.  The document text (numbered bullets) actually
> > > makes it fairly
> > > clear that there is no such thing distinguished as a secondary
> > > resource.  This same idea is present in the revised URI spec,
> > > and I've been
> > > uneasy with it there, but I've only just been able to articulate
> > > why.  Basically, I think resources are resources, with no
> > primary or
> > > secondary distinction.  However, there are primary resource
> > > identifiers
> > > (URIs without fragments) and secondary identifiers (URIs with
> > > fragments),
> > > but the form of identifier doesn't somehow make the resource
> > > of a different
> > > kind, which I think is a conclusion one might draw from the
> > > current wording.
> >
> > Very well put, Graham.
> >
> > I like your terms "primary identifier" (URI) and "secondary
> > identifier" (URIref with fragid) as they nicely correlate
> > to the use of primary machinery (HTTP) versus secondary
> > machinery (MIME specific client side processing) when it
> > comes to accessing representations of resources.
> >
> > It would also be nice to see more clearly communicated the
> > fact that representations of "secondary resources" (or
> > "resources denoted by secondary identifiers") -- presuming
> > that such can exist, since a given resource can be denoted
> > by both a URI and URIref at the same time -- are not
> > directly accessible via those "secondary identifiers"
> > insofar as the primary web machinery (HTTP) is concerned.
> >
> > A given web client might be able to retrieve a representation
> > of the resource denoted by the base URI of a URIref, and
> > from that (somehow, per the MIME type) extract a (kind of)
> > representation of the secondary resource, but such a process
> > is completely out of scope insofar as the core architecture
> > of the web is concerned.
> >
> > Thus, users should be made aware that choosing to use a URIref
> > with fragment identifier to denote a resource can have a significant
> > impact on how one might potentially interact with representations
> > of the resource in question; essentially isolating that resource
> > (insofar as use of that particular URIref is concerned) from
> > the web at large.
> >
> > A useful "best practice" could be: when in doubt, use
> > a URI, not URIref (though I appreciate that not everyone
> > would agree with such a policy).
> >
> > Regards,
> >
> > Patrick
> >
> >

------------
Graham Klyne
For email:
http://www.ninebynine.org/#Contact

Received on Monday, 11 October 2004 12:34:18 UTC