[
Lists Home |
Date Index |
Thread Index
]
jonathan@openhealth.org (Jonathan Borden) writes:
>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.
I don't think the problem frequently comes from single designers. It
comes from a wide ranges of people solving a wide range of problems with
a toolkit they assume is generic. URI's lack of centralization is both
their greatest virtue and their greatest vice, since pretty much
anything can happen - and indeed has happened.
>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.
RDF is one context for using URIs. I don't hold RDF or its expectations
to be canonical in any other context.
>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
That may work for RDF and OWL, but it does nothing beyond that.
>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'.
Nope. I'm thoroughly frustrated with REST's refusal to let me actually
talk about representations, but this is a separate matter. There are
lots and lots of 'live' cases where a single identifier may point to
multiple resources, even in simple cases like HTTP load-balancing.
While you can, I suppose abstract away multiple HTTP servers as
representations themselves, it's not particularly convincing. (I have to
confess that RFC 2616's definition of the kind of resource an http URI
identifies - a listener on a server - is the only definition I've heard
so far that is precise enough to be useful.)
More importantly, the wildly divergent uses of URIs in different systems
has made it very difficult to pretend that we're all talking about the
same thing, even when we square the circle by doing something like using
a RDDL description as a representation of a namespace URI. Convenient,
yes. Consistent? Only if you try really hard. I think it's fair to
say that much of the world never tried in the first place, and
post-traumatic stress sets in after a few thousand rounds of this.
>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.
You're welcome to write all the axioms you want. If they don't hold,
they don't hold. RDF's bizarre misunderstandings of basic URI syntax
(per 2396 and fragment identifiers) is enough cause for me to walk away
from that description, but reality is a stronger reason.
>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.
I give up at this point. The SW people are welcome to write whatever
they want, and I'll stop pretending that it affects me. The REST people
have taught me a lot about the value of lots of nouns and few verbs, but
at this point I find their definitions too constraining. Can I have
some adjectives, please? I don't just want a pony, I want a red pony. I
might even want the red pony.
I'm not worried about planes and airports. I'm worried about
communicating with people and making both my documents and my tools
accessible to them. Bizarre notions of Platonic Forms are really only
useful for communicating with a tiny audience of self-styled
philosopher-kings. I'll take the ambiguity at this point - it's far
less of a headache than metaphysics.
>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.
You're welcome to try, though I'm deeply skeptical that what you've
"written is entirely compatible with REST." For example, this is a
rather unpromising start:
http://lists.w3.org/Archives/Public/www-tag/2003Jan/0334.html
You may want to try talking with Dr. Fielding, if he's in a listening
mood.
>Of course having very precisely written specs isn't great for promoting
>permathreads.
I don't think there's any risk of that here.
--
Simon St.Laurent
Ring around the content, a pocket full of brackets
Errors, errors, all fall down!
http://simonstl.com -- http://monasticxml.org
|
