On 27/03/13 18:29, Pastrana, Rodrigo (RIS-BCT) wrote:
Because "410069.jpeg" is illegal as an XML qname local part, it is not returned
by Jena.
So basically, a Jena API user interested in a node's NS and name will
need to extract the full URI and parse it manually to extract the NS
and the Name. Because the
com.hp.hpl.jena.rdf.model.Resource.getNameSpace() will potentially
return invalid namespaces (if the name starts with a numeral or
contains a dot).
You claim it's illegal. Why?
Let's look at XML namespace 1.0 edition 3:
A names pace is used in a qname which is the PrefixedName gramam production:
[8] PrefixedName ::= Prefix ':' LocalPart
[10] Prefix ::= NCName
/* An XML Name, minus the ":" */
[4] NCName ::= Name - (Char* ':' Char*)
[5] Name ::= NameStartChar (NameChar)*
Name and NameStarChar exclude "/" so the local part can't include "/" so
("http://www.rdfabout.com/rdf/usgov/congress/";, "people/412360")
does not work either.
Being able to navigate every statement in an RDF graph is one of the reasons we
are considering JENA, where can we add a feature request for this API? Thanks.
Another example is Woodrow Wilson's congress people entry.
<foaf:Person
rdf:about="http://www.rdfabout.com/rdf/usgov/congress/people/412360";>
...
</foaf:Person>
Jena represents the statement like this:
[http://www.rdfabout.com/rdf/usgov/congress/people/412360,
http://www.w3.org/1999/02/22-rdf-syntax-ns#type,
http://xmlns.com/foaf/0.1/Person]
But the Subjec'ts namespaces is reported as
"http://www.rdfabout.com/rdf/usgov/congress/people/412360"; and it's localname as
"".
Which is correct. A local part can't start with a digit.
[11] LocalPart ::= NCName
XML allows an empty local part.
In Turtle, you can define the prefix (which is not an XML namspace) as
"http://www.rdfabout.com/rdf/usgov/congress/people/";
and get ns:412360
but it's not legal as an XML qname.
The Turtle way is much better for RDF - we have to live with RDF/XML for
awhile though.
You can call the Turtle writer directly with a PrefixMap , whic is more
liberal than the PrefixMapping the XML writer needs.
Andy
Thanks, Rodrigo.
-----Original Message-----
From: Andy Seaborne [mailto:[email protected]]
Sent: Tuesday, March 26, 2013 8:56 AM
To: [email protected]
Subject: Re: RDF Model Namespaces
On 25/03/13 17:19, Pastrana, Rodrigo (RIS-BCT) wrote:
In order to use Jena's API to navigate RDF graphs, I need to know how
this particular node is represented. If the node were a literal, its
literallexicalform would be sufficient. Since the node is represented
as an instance of "Resource" the node's label is the namespace + the
localname. However, "http://www.govtrack.us/data/photos/410069."; Is
clearly not a NS, and "jpeg" is not its local name.
Using Jena's API how can one determine if the given "Resource" node
can represented by its literallexicalform, or by its
namespace+localname. Thanks.
The full URI should be what you use to determine if two Resources are the same.
Namespace/localpart are just syntactic convenience - the code keeps and
indexes URIs only.
For literals, you need to test the language or datatype as well.
"123" is not the integer 123.
You can use .equals (of RDFNode, the supertype of Resource and Literal)
A Resource is a URI or a blank node.
RDFNode has isLiteral()/isURIResource()/isResource()/isAnon() for testing what
kind of thing an RDFNode is.
By XML, ("http://www.govtrack.us/data/photos/410069.","jpeg";) is a qname
- in fact the one with the longest local part.
This is a qname ("http://www.govtrack.us/data/photos/410069.jp";, "eg") for the
same URI.
Because "410069.jpeg" is illegal as an XML qname local part, it is not returned
by Jena.
Roll on Turtle ...
Andy
-----------------------------------------
The information contained in this e-mail message is intended only
for the personal and confidential use of the recipient(s) named
above. This message may be an attorney-client communication and/or
work product and as such is privileged and confidential. If the
reader of this message is not the intended recipient or an agent
responsible for delivering it to the intended recipient, you are
hereby notified that you have received this document in error and
that any review, dissemination, distribution, or copying of this
message is strictly prohibited. If you have received this
communication in error, please notify us immediately by e-mail, and
delete the original message.
