[Sorry Scott that I may have accidentally already replied to you directly.]
This issue is a year old, but I seem to be getting exactly the same issue. I use sml:ModifyPrefixes to add new prefixes before creating URLs with those prefixes in sml:ApplyConstruct (using smf:buildUri to create the URIs dynamically). I then use sml:ModifyPrefixes again to remove unwanted prefixes. However, while my Turtle output contains the new prefix definitions, the constructed URLs themselves have been expanded into full URLs. Additionally, the unwanted prefixes haven't been removed. Is there some trick to getting sml:ModifyPrefixes to work correctly, something that isn't in the documentation? Or is there a good example file showing its use? Thanks, Cheers, Tony. On Tuesday, March 29, 2011 4:12:55 PM UTC+1, Scott Henninger wrote: > > Phil; You can use the sml:ModifyPrefixes module to add prefixes to > your output f]file. > > Keep in mind that the script only contains the triples from the > modules in the script "triple stream" (the series of modules connected > by sm:next). Since the script file is not in the triple stream, no > prefixes or other triples from the script file will appear in the > output. (An exception to this is that if you run a script from TBC and > add the sml:ImportCurrentRDF to the triple stream, the script file's > data will be added to the triple stream. However, > sml:ImportCurrentRDF has different interpretations in the context of > TBE sessions (the current session's graph) and Web service calls (a > "no current graph: exception).) > > On Mar 29, 9:56 am, Phil <[email protected]> wrote: > > We have numerous non-rdf data sources (i.e. text files, spreadsheets, > > etc) where we use sparqlmotion to convert the data in those files to > > rdf. > > > > Our sparqlmotion scripts utilize the "smf:buildURI" to construct URIs > > using our targeted namespaces. We have added these namespaces to the > > list of Namespace Prefixes in the sparqlmotion script to not only make > > our sparql constructs be more legible, but also with the assumption > > that those prefixes would be written into the rdf files produced from > > the "export to rdf" modules in our sparqlmotion script. > > > > However, the namespace prefixes are NOT be written to the .rdf files > > and this is causing problems when we import those .rdf files into our > > "federated.owl" file because TopBraid Composer ends up assigning "j.0" > > as the prefix for all of the .rdf files generated in this way, > > producing namespace prefix conflicts. > > > > How can get the sparqlmotion scripts to write out the prefix we want > > to use into the individual .rdf files so that when they are imported > > they use the prefix we want them to use (rather than TBC's arbitrary > > "j.0" prefix). > > > > I should note that we follow the practice whereby we do not use > > default namespaces in any of our rdf files so that we can have > > consistent prefixes no matter where the .rdf file is referenced. > > > > Thanks, > > Phil -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include Enterprise Vocabulary Network (EVN), TopBraid Composer, TopBraid Live, TopBraid Ensemble, SPARQLMotion and SPIN. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/topbraid-users?hl=en
