Re: Q to implementers: Resource identifiers - XML Names and/or (concatenated) URIs? (was RE: rdfs.isDefinedBy...)

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