[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: many-to-many
Simon St.Laurent wrote: > julian.reschke@g... (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
|
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
|