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@xxxxxx
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
|
