[
Lists Home |
Date Index |
Thread Index
]
Simon St.Laurent wrote:
> julian.reschke@gmx.de (Julian Reschke) writes:
> >> >> "Cool URIs don't change" is a bad joke
> >
> >The aforementioned article is published as part of W3C "Style Guide for
> >online hypertext" [1], so this seems to be entirely advisory.
>
> For the axiomatic flavor, see:
> -------------------------------------
> "an essential [axiom] was that the same URI represents the same thing
> irrespective of context."
> - http://lists.w3.org/Archives/Public/www-tag/2003Jan/0330.html
> -------------------------------------
>
It is fair to say that someone might design a system where there are things
called 'URIs' and 'resources' and where one defines a many:many relationship
between the two. Indeed in directed labelled multigraphs it is expected that
the relationship between nodes be many:many.
This entirely misses the point of the relationship between URIs and
resources as described in RFC 2396 (a very loose description admitedly)
and/or the RDF semantics/model theory http://www.w3.org/TR/rdf-mt/ which is
a very tight and very precisely written description. In such a formalism a
URI(ref) is _defined_ to be a label for a node. Some nodes don't have
labels/names, for example a particular representation of a resource may or
may not explicitly be labelled with a URI(ref) yet as a 'thing' is
nonetheless a 'resource'. Using owl:sameIndividualAs we can explicitly state
that two different URI(ref)s label the same 'node' or 'individual'. So the
relationship (if we include OWL in this formalism) is many-to-1
Now with REST we all know that a single URI may yield multiple
_representations_ and I am convinced that this idea of many-to-many is a
direct result of conflating 'representation' for 'resource'.
The reason that the above is an _axiom_ is because we have sat down and
written a formal description for a system that describes software which
conforms to the RDF and OWL model theories. Not only have we written such
specifications but we have interoperable software implementations as a
result of such specifications.
Anyone is free to write down a _different_ specification which uses the
terms 'URI' and 'resource' in an entirely different fashion. Indeed 'URI'
might mean 'plane' as we normally understand it and 'resource' might mean
'airport' as we normally understand that term, and so you can be talking
about planes and airports but I'd have no idea what you mean because I am
using different definitions for these terms. All I can say is that in the
context of the Semantic Web activities we _can_ point to very precisely
written (albeit difficult to read) documents that try to use such terms in
an unambiguous fashion.
What I'd really like to see is that such precisely written specs (formal
semantics) be extended into the REST side of the URI/resource/represenation
arena -- I'm convinced that what we've written is entirely compatible with
REST.
Of course having very precisely written specs isn't great for promoting
permathreads.
Jonathan
|
