Hi Colin,
are you sure you want to set sml:replace true? That would remove triples that may be needed, e.g. the imported graphs containing the sxml triples.
It's tricky to help without seeing details. Are you able to package up a minimal executable set of files for us to run and reproduce locally? Feel free to send them to me off-list, if there is private data.
Holger
--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/8af614c5-7d4a-4475-8ebc-a0e0dab7c802%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/cba0b9d7-f761-44df-8c43-3b1104febc5f%40googlegroups.com.
Sml:replace removes any data that was provided as input to a step. The output of the step then becomes only data that was produced by the step itself.Sent from my iPhone
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/cba0b9d7-f761-44df-8c43-3b1104febc5f%40googlegroups.com.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6e289e52-288a-4311-ae12-0992c5f9ff41%40googlegroups.com.
Hi Colin,
your script was *almost* correct. The difference (with the attached, fixed, version) is that the sml:document of sml:ConvertRDFToXML needs to point to an instance of sxml:Document which then points at the root element using sxml:root. So I have created a dummy Document such as
converter:TheDocument
rdf:type sxml:Document ;
sxml:root converter:model .
and made that the value in the SM module. It now seems to work as expected.
As a further minor change I changed the sml:xml as shown below to
be a SPARQL variable expression, which avoids string substitution
of the {?...} syntax. I believe that should work better.
HTH
Holger
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6e289e52-288a-4311-ae12-0992c5f9ff41%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/6e289e52-288a-4311-ae12-0992c5f9ff41%40googlegroups.com.
Works like a charm. Your help is much appreciated! I did tried to add a sxml:Document during the inference phase but somehow didn't had an affect. Since it did worked manually i didn't thought of it anymore.
I still have a minor issue with the order of the output but could solve this with a xslt transformation in-between. Just for my understanding the sxml:order should tell the RDF-to-XML step to order the elements according to this property, right?
For historical reasons, the order of sibling XML elements is determined based on the property http://www.topbraid.org/2007/05/composite.owl#index, which has values such as 0, 1, 2, ...
HTH
Holger
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b514c7cc-dc04-4fc5-b5a5-262c80d1e0ca%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/b514c7cc-dc04-4fc5-b5a5-262c80d1e0ca%40googlegroups.com.