- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Fri, 07 Jun 2002 11:29:48 +0300
- To: ext Dave Beckett <dave.beckett@bristol.ac.uk>, jeremy <jeremy@jeremygray.ca>
- CC: RDF Interest <www-rdf-interest@w3.org>
On 2002-06-07 2:05, "ext Dave Beckett" <dave.beckett@bristol.ac.uk> wrote: >> ... and since we do expect >> information to flow to and from other systems operating in terms of the >> naive RDF 1.0 + issue tracking interpretation, we may create something >> analogous to the concatenation/stripping process but which is based on a >> list of known namespaces on which splitting/merging can occur when desired >> instead of the current half-baked process. Since those external applications >> will be creating collisions and improperly splitting URIs anyway, we don't >> honestly expect 100% correct integrated behaviour in any case, but will try >> to integrate with them as best as we can. >> >> How are you addressing Namespaces in XML -related issues in and around RDF? > > By using namespace URIs to indicate when to split. I agreed fully with everything you said, Dave, up to this point ;-) Whether you use a known namespace or not when serializing an RDF graph has no effect on the semantics of the resultant RDF/XML, and in fact, I would rather see autogenerated namespaces rather than "guessed at" namespaces which may actually be incorrect and lead to human confusion if the qnames in the output RDF/XML are expected to correspond to the originals. I do not see any reliable, robust method of getting to the original qname from a resource URI. Yes, you can get to something that is syntactically a qname, and a few tricks, hacks, and a bit of luck may get you the original qname, but that's not robust and precise enough for e.g. some XML application to presume it has a valid set of resource names per some original RDF/XML serialization. I consider the XML/RDF -> graph process to be strictly uni-directional, and any re-serialization to XML has no valid interpretation whatsoever to any XML application, though it may be reparsed by an RDF parser back into an RDF graph without loss of semantics. Of course, one can further argue that the qnames in the original serialization have no valid interpretation by an XML application, unless that application is an RDF parser. Yes, round-tripping of RDF/XML is a practical need, and yes, some folks seem to be getting by in some limited contexts with a few tricks and hacks -- but let's be clear that (a) there are significant problems with any existing method of URI->qname generation in RDF (b) folks shouldn't be doing anything based on qnames anyway (c) we need to find a proper solution that either (i) removes the use of XML naming constructs forever in RDF/XML for designating resources (no qnames or IDs), or (ii) formally defines a robust, reliable bi-directional mapping between URIs, qnames, and ID/xmlbase representations which is fully exposed to all RDF applications in a standardized manner and by which RDF and XML applications can be sure they are talking about the same things Until then, it is IMO irresponsible to tell folks to simply look for the longest known overlapping namespace prefix, or just break at the last non-name character, etc. That's a house-of-cards mentality that will result in alot of headaches down the road. Re-serialization of RDF graphs in XML is *not* intended for either human or XML application interpretation, but only as a means of moving a graph to some other RDF application, and any qnames in such an exported RDF/XML instance should be treated as transitory and bearing no significance beyond capturing a URI syntactically as a qname. (I expect you probably agree with most of the above, but I wanted to say it explicitly anyway... ;-) Cheers, Patrick -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Received on Friday, 7 June 2002 04:25:46 UTC