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? And multiple children is an order-independent equivalent of multiple sm:next - but how would you bring multiple predecessors into a single module in that case? 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 to reproduce, then visit > > > 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. > > > -- 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.
