On Wed, 2011-11-09 at 11:05 -0800, Dennis E. Hamilton wrote: > Um, forgive me for operating out of context and not rummaging through all of > the applicable W3C specs, but are you saying that the splitting rule is > basically creating parts for a CURIE ?
Not a CURIE but the parts of a QNAME. > That's not exactly how XML Namespace > works so is there a clash with RDF/XML or does RDF/XML not adhere to > [xml-names]? It's precisely because RDF/XML adheres to XML names that you get this pain. As far as the RDF model is concerned, and thus Jena, every resource has a URI[1]. That's a plain, simple, absolute URI - no qnames, no curies. Now the way you write these URIs in RDF/XML depends on whether you are using your resource as an object/subject resource, a property or a class (in abbreviated form). For the last two cases the RDF/XML syntax uses namespace-qualified element names. So for example: <rdf:Description rdf:about="http://www.openjena.org/example#foo";> <eg:myprop>Bar</eg:myprop> </rdf:Description> with the namespace declaration: xmlns:eg='http://www.openjena.org/example#' Is supposed to be parsed as the triple: <http://www.openjena.org/example#foo> <http://www.openjena.org/example#myprop> "Bar" . So RDF/XML defines that the URI you give myprop is found by concatenating the namespace and localname parts of the qname. Now think about reversing this. You have an RDF graph with a bundle of triples with absolute URIs. You want to write them out. Now you have to be able to recreate a QNAME which when concatenated would give you the right absolute URI. That's the purpose of Jena's getNamespace/getLocalName calls. By "virtue" of the XML specs the localname part of a QNAME is restricted to be an NCName so the Jena algorithm (and it really doesn't have very much choice here) is to find the longest trailing NCName and all else is namespace. Any answer from getNamespace which left a non-NCName on the end would result in Jena writing illegal RDF/XML. Dave [1] (ignoring bNodes as irrelevant for this discussion)
