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

Comments inline...

> 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.

An expected and not uncommon interpretation, but still unfortunate,
especially WRT  integration scenarios - scenarios on which RDF's widespread
adoption almost surely hinges.

> 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.

Assuming that by "original serialization" you mean the first XML which was
serialized from RDF, as opposed to any original source XML, an RDF
application which retains the concept of namespaces throughout the process
could ensure that a downstream XML application is still able to make a valid
interpretation in terms of namespaces, though the _prefixes_ used in
generated textual QNames may have to have been arbitrarily selected or
dynamically generated. Non-issue, however, given that a Namespaces in
XML -compliant XML application doesn't care about the textual prefix, only
that it represents a specific namespace. It's the namespace + local
identifier that matters, not the letters and punctuation of "foo:bar".

> 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

Yup.

> (b) folks shouldn't be doing anything based on qnames anyway

Certainly not based on the whole textual QName or even just its prefix,
that's for sure.

> (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.

Agreed, agreed, and agreed. :)

Re: (c) (ii) - Whose charter would cover such an activity?

> 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.

Ouch! I don't expect humans to really _want_ to work with the resulting
output, but if XML applications can't we might as well all pack up and go
home right now. Serialization of RDF into XML MUST be intended for both
human and XML application interpretation, even if additional transformation
step(s) are required to get from the base serialization schema to a desired
final schema. For any such  transformation processes to have successful
results, though...

As for the QNames, again bearing in mind that the namespace + local
identifier combination is what is of importance, not the textual
representation thereof, we will guarantee our chance to pack up and go home
if we continue to generate QNames that are at best unrepresentative of input
data and at worst completely and unpredictably contrived.

> (I expect you probably agree with most of the above, but I wanted
> to say it explicitly anyway... ;-)

I do and if, as you suspect, Dave does too then his view and mine are
probably really not so different. Dave?

Jeremy

Received on Friday, 7 June 2002 12:15:04 UTC