On 11/05/2018 12:26, Rob Atkinson wrote:
OK - thanks for that.
so just checking we'd need to merge outputs of B,C in module flow A
-> (B,C) -> D by
<A>
<B>
<update temp>
</B>
<C>
<update temp>
</C>
</A>
<D context=temp/>
?
Yes that would work.
On Friday, 11 May 2018 12:01:45 UTC+10, Holger Knublauch wrote:
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].
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] <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.
