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
