Sure, we're converting RDF graphs into a data format understood by our processes. It should suffice to say that each non-anonymous, non-literal node 's namespace and name need to be parsed out. Thanks.
Thanks, Rodrigo. -----Original Message----- From: Martynas Jusevičius [mailto:[email protected]] Sent: Wednesday, March 27, 2013 4:39 PM To: [email protected] Subject: Re: RDF Model Namespaces Maybe you could start with explaining what you are trying to achieve? You stated you want to navigate statements in an RDF graph -- what does this have to do with namespaces and local names? Martynas On Wed, Mar 27, 2013 at 10:32 PM, Pastrana, Rodrigo (RIS-BCT) <[email protected]> wrote: >> You claim it's illegal. Why? > Did I? I pointed out the scenario, and asked if Jena's API can help handle it. > Are you claiming the "congress people" RDF/XML graph is illegal? > > Doesn't really matter, what matters is this scenario will play out in many > RDF/XML graphs. > We want to use JENA, but we have to be able to support RDF/XML graphs such as > the congress people... > >>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. > > At this point, I'll try anything. > Read in the people graph, wrote out as turtle, read in turtle version, still > having issues same issues with numeric people ids and all .jpg resources. > Anything else that I could do? > > Thanks, Rodrigo. > > -----Original Message----- > From: Andy Seaborne [mailto:[email protected]] > Sent: Wednesday, March 27, 2013 2:52 PM > To: [email protected] > Subject: Re: RDF Model Namespaces > > 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. >> >
