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). 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. 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? Thanks a lot! Nis PS: Unfortunately, your suggestion on going non-ABBREV was a step in the wrong direction, only making things more hierarchical. 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: [email protected], Date: 02-09-2013 16:00 Subject: Re: Circular references when serializing RDF XML I'm not sure that thinking in terms of "declarations" and "references" is helpful here. rdf:about is a normal way to state the subject of a statement, rdf:id is an optional abbreviation of it: "The rdf:ID attribute on a node element (not property element, that has another meaning) can be used instead of rdf:about ..." [1] The thing with rdf:ID is that you are only allowed one rdf:ID with a given name in each document and so you have to keep track of whether you have already used that form (and if you then then use rdf:about everywhere else). Whereas you can use rdf:about on the same URI (including relative URI) as often as you like. [This has nothing directly to do with circularity of cross referencing. When you refer to a resource you are using it as the object of a statement which in RDF/XML means using the rdf:resource attribute.] If you want to be certain of a "flat" structure then use rdf:about uniformly, rather than use rdf:id uniformly. You can do that by using the non-ABBREV writer or by switching off the rdf:id option in the ABBREV writer (see the Block rules section of 2). You can't turn off rdf:about as far as I know, that would be problematic. If your consuming application *really* requires only rdf:ID and not rdf:about and you really can't get that changed then your best bet *might* be to use the non-ABBREV writer to get simple flat XML that you then transform yourself to meet the custom syntactic constraints of your consumer. Dave [1] http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-ID-xml-base [2] http://jena.apache.org/documentation/io/rdfxml_howto.html#advanced-rdfxml-output On 02/09/13 13:54, Nis Jespersen wrote: > Dear [email protected], > > I am currently working on producing an RDF XML file with a bunch of high > voltage electrical objects in it. I've come a long way, but recently hit > an obstacle because three classes are referencing each other circularly. > Basically, a ShuntCompensator references a RegulatingControl which > references a Terminal which references a ShuntCompensator - and the circle > is thus completed. > > It is no problem adding all this to my Model model object, and I can > actually also specify it in my RDFWriter (see below). But the problem is > that one of these classes would always be referenced before it has been > declared, and therefore it gets an rdf:about identifier in a child element > below whatever references it, rather than an rdf:id in a completely "flat" > XML RDF structure (i.e. without any hierarchies in the serialized file). I > find this result weird (an "about" tag doesn't sound like an ID to me) but > recognize that it is probably okay according to the rdf spec. However, the > receiving end of this file requires a completely flat structure and > everything declared using rdf:id attributes. So I am reaching out to ask > if there is a way to tweak Jena's serializer to do this? Surely, there > must be a way to reference something which is declared further down the > file? Since the entire model is already established, I would find it an > odd limitation that such ordering in which elements are serialized should > be a limitation? > > RDFWriter writer = model.getWriter("RDF/XML-ABBREV"); > writer.setProperty("showXMLDeclaration", true); > writer.setProperty("xmlbase", NS); > writer.setProperty("prettyTypes", new Resource[] { > Ontology.ShuntCompensator, > Ontology.RegulatingControl, > Ontology.Terminal, > ... > } > FileOutputStream fos; > fos = new FileOutputStream(filepath); > writer.write(model, fos, null); > > Thanks a lot in advance!! > > 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 > > -------- ------------- ------- ------- > -------- ---------------- -------- -------- > ---- ---- ----- ------- ------- > ---- ------------ -------- -------- > ---- ------------ ---- ------- ---- > ---- ---- ----- ---- ----- ---- > -------- ---------------- ------ --- ------ > -------- ------------- ------ - ------ > > > > Medmindre andet er angivet ovenfor: / Unless Otherwise Stated Above: > IBM Danmark ApS > Nymøllevej 91 > 2800 Kongens Lyngby, Danmark > CVR nr.: 65305216 > Medmindre andet er angivet ovenfor: / Unless Otherwise Stated Above: IBM Danmark ApS Nymøllevej 91 2800 Kongens Lyngby, Danmark CVR nr.: 65305216
