> > 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.
