- From: Patrick Stickler <patrick.stickler@nokia.com>
- Date: Wed, 23 Jan 2002 11:36:25 +0200
- To: ext Jonathan Borden <jborden@mediaone.net>, RDF Comments <www-rdf-comments@w3.org>
Your comments are quite on target, Jonathan. This is an issue that I have repeatedly ranted about in the past, and have done alot of thinking and hacking to find an optimal solution. It is my opinion, which may or may not be shared by others, that the entire QName -> URI problem with RDF is simply a direct consequence to using QNames to denote resources in the XML serialization which in the RDF graph only have URIref denotation, and that design decision, while adding a certain degree of openness, flexibility, and readability to the serialization of RDF statements, was not an optimal design choice. QNames are only an issue for RDF serialization, and in fact are not addressed in the MT at all, by intent. Therefore, I see the solution to this problem as defining a new XML serialization for RDF which does not employ QNames for denoting resources, but uses only URIrefs. This would avoid RDF having to support content-specific QName to URI mappings or resort to problemmatic and simplistic direct concatenation, and would also provide for full round-tripping, since clearly, if no mapping occurs, you get out what you put in. Such a serialization would also facilitate the use of validating XML editors for RDF serialized knowledge regardless of ontology, as the only element and attributes in such a serialization would be those needed to represent RDF statements -- with all application specific vocabulary relegated to attribute values and/or data content. For now, however, I don't see that this QName -> URI mapping problem can be solved in terms of the present RDF/XML serialization, and as the present Core WG is not able under its charter to provide a new serialization, this matter must be left for a future WG or a future phase of the present WG (which I hope will commence very soon as this is a non-trivial issue). Regards, Patrick On 2002-01-23 7:37, "ext Jonathan Borden" <jborden@mediaone.net> wrote: > Graham Klyne wrote: > > " > The forward transformation from QName -> URI is clear and unambiguous per > the original RDF specification. It is the reverse transformation that is > problematic. > " > > To be clear, while I would prefer that a bidirectional mapping be possible, > just as I would _greatly_ prefer that the RDF model <-> XML mapping be > bidirectional and roundtripable, there are issues with the simple forward > transformation. > > In particular the model XML Schema uses for use of a QName as a type > specifier is that the namespace name/URI is like the 'base URI' of the > schema (quotes because it is not quite that simple but nonetheless) and that > the localname is used as a locator for the type declaration within the > schema module. In URI terms, XML Schema thus treats the localname LIKE a > fragment identifier. It is not exactly a fragment identifier for several > reasons, namely that no fragment identifer syntax is (yet)defined for > application/xml and particularly because the localname maps to the XML > Schema "name" attribute which is not ot type ID. > > For this reason I have issues with the forward QName -> URI mapping if this > is a simple string concatenation. > > For the vast majority of RDF namespaces, perhaps all of the deployed RDF > namespaces, simple concatenation is exactly the same as treating the > localname as a fragment identifier (it comes after the '#') but for XML > namespaces in general this is not the case. RDF does not require its > namespaces to end in '#' hence one of the reasons for the incompatibility. > > I cannot say for sure that this incompatibility is entirely the 'fault' of > RDF (although the mapping is perhaps too simplistic), rather a breakdown in > communications and coordination between the RDF WG and other WGs more > intimately involved in XML activities. It is not important to me where this > incompatibility gets fixed, and since it is a basic architectural issue I > agree with Brian and Tim Bray that the TAG ought be involved in this issue. > For that reason alone, I would prefer that the issue not be closed for the > moment. > > Jonathan > > > -- Patrick Stickler Phone: +358 50 483 9453 Senior Research Scientist Fax: +358 7180 35409 Nokia Research Center Email: patrick.stickler@nokia.com
Received on Wednesday, 23 January 2002 04:35:35 UTC