Hi Nis, Glad you are sorted. Next time I'm passing through Copenhagen ...
Dave On 05/09/13 12:52, Nis Jespersen wrote:
Hi Dave, Thanks so much! Subclassing Basic was a great idea, and our new custom Writer works beautifully! Very very helpful - your pointers helped us a long way in the right direction. Much appreciated! I'll be happy to buy you a beer one day! :-) Nis * Nis Jespersen* Advisory IT Architect • Energy & Utilities Global Center of Competency • IBM Global Business Services +45 41208641 • [email protected] • IBM Danmark ApS, Lyngbyvej 2, 2100 Copenhagen, Denmark -------- ------------- ------- ------- -------- ---------------- -------- -------- ---- ---- ----- ------- ------- ---- ------------ -------- -------- ---- ------------ ---- ------- ---- ---- ---- ----- ---- ----- ---- -------- ---------------- ------ --- ------ -------- ------------- ------ - ------ From: Dave Reynolds <[email protected]> To: Nis Jespersen/Denmark/IBM@IBMDK, Cc: [email protected] Date: 03-09-2013 15:38 Subject: Re: Circular references when serializing RDF XML ------------------------------------------------------------------------ On 03/09/13 11:14, Nis Jespersen wrote: > Hi Dave et al., > > Thanks so much for your response! I really appreciate it. > > The receiving client does indeed need rdf:IDs in a non-nested structure. > I've created the mentioned example in a different tool to illustrate the > result I am looking for: > > <?_xml_ version="1.0" encoding="UTF-8" ?> > <rdf:RDF xmlns:cim="http://iec.ch/TC57/2012/CIM-schema-cim16#"; > xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#";> > <cim:ShuntCompensator rdf:ID="_83884fb0-1473-11e3-9b87-00271369ce74"> > <cim:IdentifiedObject.name>nisShunt</cim:IdentifiedObject.name> > <cim:RegulatingCondEq.RegulatingControl > rdf:resource="#_8fc5db30-1473-11e3-9b87-00271369ce74"/> > </cim:ShuntCompensator> > <cim:RegulatingControl rdf:ID="_8fc5db30-1473-11e3-9b87-00271369ce74"> > <cim:IdentifiedObject.name>nisRegControl</cim:IdentifiedObject.name> > <cim:RegulatingControl.Terminal > rdf:resource="#_92fb63b0-1473-11e3-9b87-00271369ce74"/> > </cim:RegulatingControl> > <cim:Terminal rdf:ID="_92fb63b0-1473-11e3-9b87-00271369ce74"> > <cim:IdentifiedObject.name>nisTerminal</cim:IdentifiedObject.name> > <cim:Terminal.ConductingEquipment > rdf:resource="#_83884fb0-1473-11e3-9b87-00271369ce74"/> > </cim:Terminal> > </rdf:RDF> > > Note how the order of the three elements does not prevent the use of > rdf:ID. Elements further down the file are still referenced (by use of > rdf:resource, as you also mention). I don't think ordering is relevant here. Those resources could have been put in a different order and all use rdf:ID or they could all use rdf:about. > The ABBREV writer's "prettyTypes" property seems to be both what we > need, and where the limitation is hidden: > /prettyTypes: This is a list of the types of the principal objects in > the model. The writer will tend to create RDF/XML with resources of > these types at the top level. / > "Creating resources at top level" is just what we need and use, but > "tend to" I'm guessing is where it gives up, when things get circular. Again, this is not really do with circularity. > Is there some alternative way to specify such "principal" objects? I > don't need to list them, all objects in the model are principal and > should be created at the top level - that might be simpler? The non-ABBREV writer treats all subjects as top level objects, it never nests. Which is why I suggested starting with that. > PS: Unfortunately, your suggestion on going non-ABBREV was a step in the > wrong direction, only making things more hierarchical. ?? The non-ABBREV writer is just too stupid to nest resources :) it can't do it, everything is guaranteed to be flat (in the sense of the XML trees). If by "hierarchical" you mean that it uses rdf:about then that's what I said. It uses rdf:about uniformly. You would need to transorm the result afterwards or modify the writer [*]. If you really are seeing nested output from the non-abbrev writer then something weird must be going on. If you can construct a complete minimum example which generates and serializes just a few resources that could make this discussion more concrete. [*] If the notion of transforming the non-abbrev RDF/XML output is not appealing then it would be fairly easy for you too do a custom writer. If you look at the code for the non-abbrev writer [1] you'll see that it is very straightforward. It lists all the subject resources, for each subject it outputs an rdf:Description and a set of property/value pairs for each one. All output is done by primitive string bashing. The bit that outputs the URI in the rdf:Description is writeResourceId which is a protected method. So you could subclass Basic and provide your own writeResourceId which used rdf:ID instead of rdf:about in the case where substitutedAttribute(relativize(r.getURI()) starts with a '#'. Since listSubjects should only list unique resources there should not be any repetition and blindly using rdf:ID for all such local relative URIs would be safe. Dave [1] http://svn.apache.org/repos/asf/jena/trunk/jena-core/src/main/java/com/hp/hpl/jena/xmloutput/impl/Basic.java Medmindre andet er angivet ovenfor: / Unless Otherwise Stated Above: IBM Danmark ApS Nymøllevej 91 2800 Kongens Lyngby, Danmark CVR nr.: 65305216
