Meant to say

 

"My suggestion though was NOT about renaming the properties, but about
renaming the converted row resources."

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Irene Polikoff
Sent: Tuesday, March 22, 2011 1:05 PM
To: [email protected]
Subject: RE: [topbraid-users] afn functions in sparql tab/spin rules

 

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

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

Reply via email to