Re: suggest validator prefer URI to FPI

Le mar 17/08/2004 à 16:02, Nick Kew a écrit :
> > identifier; depending on the URI scheme, the said identifier may or may
> > not be dereferenceable; in some URI scheme, there is an authoritative
> > representation of the URI that can be obtained following a well-defined
> > protocol. For instance, http: URIs can be obtained through the HTTP
> > protocol, which also defines a caching mechanism.
> 
> But the HTTP protocol is perfectly clear that content may be dynamic.
> As soon as you dereference a URI, you lose the guarantee of uniqueness
> that is fundamental to the vocabulary/RDF usage.

I'm not sure of what you mean by uniqueness, here; I see 2 different
topics:
- the fact that the representation you get when dereferencing a URI may
vary; I don't see how this impact the identification part of a URI
- the fact that one URI may be used to identify 2 different things,
againts which there is indeed no guarantee but social pressure, but this
is not limited to HTTP URIs nor do I see the link to dynamic content.

> > Hmm... We're drifting a long way off the initial discussion :) To reply
> > shortly, Annotea is indeed better used on stable resources rather than
> > changing ones - but stable resources doesn't mean static; also, I think
> > Annotea now deals well with content negotiation, using the
> > Content-Location header as it should. But I guess this should be rather
> > discussed on www-annotations :)
> 
> Content-Location doesn't make the dereferenced content unique or
> invariant.

Indeed; but it doesn't need to be; I referred to Content-Location since
you were saying that Annotea was failing with negotiated content, and
dealing with the Content-Location header addresses this point, as far as
I can tell.

I don't see what makes you think that annotea fails on dynamic content;
more precisely, I'm not sure what you see as a failure of the annotation
protocol, given its scope; it's pretty clear to me that annotating a
resource that changes a lot is likely to break, but that is not a
failure of a protocol, but rather a probably bad choice of a target for
annotations (the same way that linking to the W3C home page for a
specific news published in the past week is a bad idea since the news
are rotating on this home page).

> The bottom line is confusion.  Annotea is fundamentally broken because
> it assumes invariance (and XML well-formedness - but that's another story)
> of dereferenced content.

XML Well-formedness is not a requirement of annotea, since it works on
HTML 4.0; note that even if it was, that doesn't make it broken, but
restricted to a specific domain - you may question whether this
restriction is appropriate for your usage, but I don't think that makes
the whole protocol broken.

As to invariance, I still fail to see what you mean.

>   I submit that this is entirely relevant to the
> current discussion, because it demonstrates what's wrong with W3C's usage
> of URI.

So be it, then :)

> Not that either usage of URI is intrinsically wrong, or even problematic.
> Not even that both usages can't in principle work together.
> But that *in practice*, they are often confused in the W3C's work,
> because each usage has its own 'community', and not everyone appreciates
> the difference.

The fact that it takes time for a technology to be well-used and
well-understood is very true, and the validators developers are better
placed than anyone to know this; I don't think refusing a technology
only because it takes time to explain/understand it is a good thing to
do.

>   There are ivory towers - particularly in semweb-land -
> constructed on this confusion.  And too much historical baggage to
> fix it as W3C would like.

"Too much historical baggage to fix it as W3C would like"... that could
make a good epitaph for the W3C Validator ;o)

Dom
-- 
Dominique Hazaël-Massieux - http://www.w3.org/People/Dom/
W3C/ERCIM
mailto:dom@w3.org