Hi Richard,
the Jena API that we use under the hood has two dialects of RDF/XML
syntax. One is called "RDF/XML Abbrev" and uses a less predictable, but
more readable format, while the plain RDF/XML uses rdf:Descriptions that
are more regular and thus attractive for XSLT. As you have found out,
the SPARQLMotion servlet was only supporting the plain RDF/XML syntax.
Side note: The variations of syntax have been a major reason why RDF/XML
has long become very unpopular for many users. In the early days RDF/XML
was the only syntax for RDF and this backfired to the RDF data model as
a general graph data representation mechanism. Many people have
therefore moved to Turtle syntax.
One strategy to solve whatever you have to solve is to move the
processing into the TopBraid server itself. For example, instead of
having an external XSL processor work on the results of the SM calls,
you could write a JavaScript or SWP script that operates on the graph
itself, regardless of the syntax, and then produces exactly the output
that you really want. Many TopBraid users seem to be quite content with
JavaScript/ADS, see
https://www.topquadrant.com/doc/7.2/scripting/index.html but if your
XSLT is producing HTML you may also use SWP directly.
If you need to continue to use external XSLT, the SPARQL endpoint itself
is NOT an option either, because if you run a CONSTRUCT there it can
only produce abbreviated RDF/XML. However, you could use this SPARQL
function
BIND
(<http://topbraid.org/sparqlmotionfunctions#convertRDFToText>(<http://topbraid.org/sparqlmotionlib#RDFXML>)
AS ?s)
to produce an RDF/XML string, which you could then return either from an
SWP script or an ADS/JavaScript service. In SWP it would mean to first
collect all relevant triples into ui:tempGraph using ui:update, and then do
<ui:setContext ui:queryGraph="{= ui:tempGraph }">
<ui:return ui:result="{= smf:convertRDFToText(sml:RDFXML) }" />
</ui:setContext>
I am not sure what other technical background you have and whether these
pointers are enough, so feel free to follow-up.
Holger
On 2022-03-30 2:24 am, 'Richard Nagelmaeker' via TopBraid Suite Users wrote:
Hi all,
In EDG 6.4 we used sparqlmotion to retrieve RDF/XML and process this
using some XSLT scripts.
Now we are using EDG 7.1.2 the sparqlmotion option is gone. So we
access the sparql end-point directly. (tbl/sparql). Using
application/rdf+xml in the accept header and posting a construct
query. The RDF/XML produced has a different syntax form the one
produced through sparqlmotion.
I used the Sparql end-point on EDG 6.4.3 as well, this gave the same
result als EDG 7.1.2. So my assumption is that the difference stems
from settings for sparqlmotion.
The RDF/XML from sparqlmotion has every subject wrapped in a
rdf:Description
The RDF/XML from tbl/sparql has no rdf:Description and has every
subject wrapped by it's type, also every subject now has nested
subjects as well.
Is there a way to get the RDF/XML output from Sparqlmotion, with every
subject wrapped in a rdf:Description?
Regards,
Richard
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/7e1c4f84-e03f-448c-bfb9-9bf9274cbf28n%40googlegroups.com
<https://groups.google.com/d/msgid/topbraid-users/7e1c4f84-e03f-448c-bfb9-9bf9274cbf28n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/f76faed6-0719-502c-5c9f-acc89b7b6647%40topquadrant.com.
