On 11/05/2018 11:56, Rob Atkinson wrote:
Hi Holger
Thanks for this. I'm trying to follow up to see if I can adapt it -
and can't locate the sparqlmotion in SWP information needed to
progess. I can find the SML module reference in the TBC help - but not
the control flow syntax..
- is nesting of elements in SWP equivalent to the sm:next connector
in SparqlMotion?
Yes.
And multiple children is an order-independent equivalent of multiple
sm:next
If your sml:XY module has multiple children then they will all have the
same input graph.
- but how would you bring multiple predecessors into a single module
in that case?
You cannot. This is a main feature of SPARQLMotion that has no direct
equivalent in SWP. What we often do is to copy the result triples into a
temp graph such as in
<ui:update ui:updateQuery="{! INSERT { GRAPH ui:tempGraph { ?s ?p ?o } }
WHERE { ?s ?p ?o } }" />
and then continue with the ui:tempGraph as context graph <ui:setContext
ui:queryGraph="{= ui:tempGraph }"> ... </ui:setContext> once you have
collected any data that you want to merge. This also liberates you from
a particular order.
If you need to merge multiple named graphs, you can also use the
function ui:unionOfGraphs.
Holger
Rob
On Tuesday, 8 May 2018 14:27:04 UTC+10, Holger Knublauch wrote:
Hi Rob,
I wanted to confirm the best recommendation myself so created a
little toy example of converting XML instance documents into a
stable ontology. You can unpack the attached .zip file into a
folder "xml" in a project called example.org <http://example.org>
to reproduce, then visit
http://localhost:8083/tbl/swp?_viewClass=scripts:ImportXMLService&fileName=thing.xml
<http://localhost:8083/tbl/swp?_viewClass=scripts:ImportXMLService&fileName=thing.xml>
to try it in your browser. It produces a dummy JSON just for the
sake of the demo, for example including a loop over all <thing>
elements found in the XML.
To produce the schema ontology, I started with an example instance
document - loaded it into TBC with double-click and then saved it
to TTL, deleting any instances. I created a suitable namespace
prefix to avoid the default namespace and then replaced the
sxml:element triples from URIs to string values (because otherwise
the XML tags would have to match ont:thing etc). The result was
thing-ont.ttl which is the master ontology against which users
could write SPIN/SHACL transformation rules etc. There are other
ways to produce such an ontology including XSD import, but the
trick is to get the sxml:element annotations right so that they
really match the XML instance documents.
The provided SWP script can be used to batch process any number of
XML instance documents. They will all get URIs from the provided
namespace (base URI), although I understand in your case they
might be a temporary structure that is then further processed down
the line.
I prefer using SWP over SML for such tasks, among others due to
the more compact syntax and more features. You can still use
debugging techniques including ui:dumpResultSet.
I know I am not directly responding to your specific questions but
think it might be more fruitful to present you with a foundation
that actually works and we can take baby steps from there if you
get stuck.
HTH
Holger
On 8/05/2018 8:17, Rob Atkinson wrote:
Thanks Holger
have been playing with Semantic XML and have specific questions:
I have an an example XML file and a schema I want to load and
manipulate using the RDF Construct transform approach, but be
able to load multiple similar XML files, and also re-load as the
XML file itself is versioned.
Approaches that create per-file namespaces for clones of the SXML
ontology make it hard to reuse the transforms.
Also I am getting different flavours of SXML results if I load
the file via the TBCME import wizard or via the SParqlMotion
import from XML, then export to RDF
(i suspect you also get different RDf if you drag and drop the
file into SPARQLmotion vs load it via names - but I need to
predict the namespaces in use and make it a re-usable script so
drag and drop individual files or using wizards is of no value
beyond testing.)
There are a few issues layered up here:
ultimate goal is to be able to load files of a given XML schema
into an equivalent ontology (note this is distinctly different
from the SXML model which recreates XML DOM nodes). Specifically
data has foreign key references using data values - these need to
be turned into object properties - not XSML text nodes with
nested values that happen to match some other property of some
other object somewhere:
<thing><idprop>23</idprop></thing>
<otherthing><id2>2</id2><refthing>23</refthing></otherthing>
needs to end up as something like
myns:thing_23 a mymodel:thing .
myns:otherthing_2 a mymodel:otherthing ;
mymodel:otherthingref myns:thing_23 .
not the original DOM.
So I can create constructs to do this rebuilding of the original
object model - if I can predict the form.
So questions:
1) if i wish to make a repeatable test case in SPARQLmotion
(because the debugger is handy) and ultimately deploy the
processing to SWA applications, what is the optimum way to do
this that makes the SPARQL (or tool config) re-usable ?
2) is there a better way (some configurable version of XML import
that is scriptable)
3) which of these methods produce the same outputs - or why do
they differ:
a) import via wizard without XSd
b) import via wizard with XSD
c) import via XML import -> XML2RDF (no option provided to use XSD?)
d) import via drag and drop of specific file (no option to use XSD?)
e) open the file directly in TBCME
e) ... other options I havent found yet?
--> differences seem to be the assumption about the namespace the
data is in
4) it strikes me that these XML->RDF patterns could be turned
into parameterised functions (do they exist - and what are the
moving parts in different technology layers so these can be
tested and deployed in a SWP environment?
5) is there succinct documentation anyway showing examples of the
SXML structures - the help docs are pretty verbose and hard to
visualise.
6) is there any way of making it not put the data and the class
model into the same namespace (that is just a
really,really,really bad idea when we naturally we will want to
have multiple data files using the same model and be able to
re-use the mappings...)
>
> SpinMap - doesnt seem to be supported in other technology
layers (how
> to access it via SPARQLMotion and/or SWP ?)
SPINMap should work fine - it is just a collection of SPIN
templates
with a visual notation. The SPIN templates can be executed as
rules
using the normal SPIN infrastructure including
sml:ApplyTopSPIN (which
also happens to be accessible using SWP). SPINMap is for
example used
under the hood of the EDG spreadsheet importers.
-
>
> XML import in general - does importing with an XSD produce
something
> substantially different from SPARQLMotion XML->RDF module?
What is the
> recommended way of doing an XML import and conversion in a SWP
> environment?
The recommended way is to produce a stable Semantic XML
ontology that
has sxml: annotations at classes and properties. These
ontologies can be
either created by hand, generalized from example instance
files, or
through the XSD importer. Then use sml:ConvertXMLToRDF to
convert XML
instance documents.
actually I dont want to produce the XML yet - but thanks for the
tip :-)
HTH
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 [email protected] <javascript:>.
For more options, visit https://groups.google.com/d/optout
<https://groups.google.com/d/optout>.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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].
For more options, visit https://groups.google.com/d/optout.
