OK, it's 'kennedys.rdf' in my installation, not 'kennedys.ttl' as the script suggests. I added a path to it (rather than relying on namespace lookup), & now it works. Thanks, Cheers, Tony.
On Monday, April 16, 2012 5:04:16 PM UTC+1, Scott Henninger wrote: > Tony; The uncle relationships should be in the RDF/Turtle produced by > the script. They are produced by the sml:ApplyConstruct module named > "Create uncles". If I run this script, I get, amongst others, the > following relationships: > > xyz:JohnKennedyJr > a xyz:Person ; > rel:uncle xyz:EdwardKennedy , xyz:RobertKennedy , > xyz:JosephKennedyJr ; > ... > > -- Scott > > On Apr 16, 6:35 am, Anthony Coates <[email protected]> wrote: > > Hi. I tried your example; I see the change of prefix working, but could > > verify the addition of a prefix because no 'rel:uncle' relationships > were > > produced from the 'Kennedys' data set. Is that what you expected? > > > > Thanks agin for your help, Cheers, Tony. > > > > > > > > > > > > > > > > On Monday, March 26, 2012 4:54:25 PM UTC+1, Scott Henninger wrote: > > > Tony; Attached please find an example script that adds a new prefix > and > > > modifies another prefix by removing the old prefix and adding a new > one. > > > > > Hard to say what is happening in your script, but I'd guess that your > > > prefix definitions don't exactly match your URIs. One way to address > this > > > is to open your file in Composer, open a resource with the full URI in > it, > > > and use Assign Prefix to Namespace... (context triangle in upper-left > of > > > Form) to assign a prefix. > > > > > -- Scott > > > > > On 3/26/12 9:28 AM, abcoates wrote: > > > > > [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 -- 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
