jonathan@o... (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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format