Jeff,
SPARQLMotion is a data flow processor. RDF flows into the modules and it flows out of them. It is useful to see a debugger to see exactly what triples are in the pipeline at any given point. Setting "importToInputGraph" to true does not add the range triples to the pipeline, so the converter does not know what ranges to use. It simply specifies the mode in which importer works. You need to explicitly make these triples available. When you use "Import to current model" outside of SM, the model you are importing to is available because it is opened and import happens into it. Adding construct steps or inferencing steps or any other steps is pretty simple. My suggestion though was about renaming the properties, but about renaming the converted row resources. You said that your current script with "importToInputGraph" set to true is doing everything you needed except that URIs for the newly created resources did not follow the pattern you wanted them to follow. The way to address this is by using an Apply Construct module which would take the graph that has been created and create a new graph that would be exactly the same except for the URIs of the converted resources. Replace = true setting insures that the only triples that flow out of Apply Construct are those that were created by it. Without this setting, it would output the incoming triples as well as the triples it creates. Regards, Irene From: [email protected] [mailto:[email protected]] On Behalf Of Schmitz, Jeffrey A Sent: Tuesday, March 22, 2011 11:40 AM To: [email protected] Subject: RE: [topbraid-users] afn functions in sparql tab/spin rules JS: It didn't use the range of the defined properties to determine the types of the subjects (I meant objects) imported from the table data. It just makes them all strings. GS: The 2nd script imports the rdfs:range triples, so the importer knows how to assert types. JS: A concept I'm not quite getting is, why when "importToInputGraph" is set to true are the rdfs:range triples defined in the input graph not available to the importer? Also note that when I set "importToInputGraph" to false while still importing the script containing model, then there is no property matching performed against the imported model, I assume because the properties are then just created using the "base" namespace instead of the inputGraph namespace, right? In the end, what I'd really like is a way to specify: 1. That the processor should match properties from an imported graph if possible, or even or a way to define a namespace for the generated properties instead of using the base namespace one, neither of which is currently possible, right? I did try using the property prefix, but that doesn't seem to work for specifying a different namespace. 2. That the processor should use the ranges of the matched properties to classify the objects imported from the spreadsheet data. (which it currently does do) Is there some way to specify number 2 that I'm overlooking? I suppose there might be a way to use an ApplyConstruct module to rename the generated properties (ala Irene's instance renaming suggestion) and then let appropriate spin inferencing take care of classifying the objects according to property range. Any simpler way, or is that way pretty simple to do? Thanks, Jeff From: [email protected] [mailto:[email protected]] On Behalf Of Gokhan Soydan Sent: Monday, March 21, 2011 9:37 PM To: [email protected] Subject: Re: [topbraid-users] afn functions in sparql tab/spin rules Hi Jeff, The reasons that the script with ImportRDFFromWorkspace (the 2nd script) did better job, but skipped instancePattern are as follows as answers to your analysis of the 1st script: It didn't use the range of the defined properties to determine the types of the subjects imported from the table data. It just makes them all strings. The 2nd script imports the rdfs:range triples, so the importer knows how to assert types. It's not using the instancePattern to create the URLs for each row of data. The instance pattern is not used, for importing the spreadsheet to input graph, . The first column of the spreadsheet in this case should already have the instance qnames, and they are used. Importing the spreadsheet to a new graph vs. the input graph are different. More information is at the Help page of TopBraid Composer. TopBraid Composer > Import and Export > Import external information > Import Spreadsheets It's not using the className property to classify each row of data, it just makes them all owl:Thing's The 2nd script imports the definition for the resource corresponding to the className. Gokhan -- You received this message because you are subscribed to the Google Group "TopBraid Suite Users", the topics of which include 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 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 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
