Thanks Irene,
"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."
That I think was the real source of my confusion since that behavior didn't
seem to happen in SM, and I just wanted to make sure I understood why.
I did understand your previous suggestion regarding renaming converted rows, I
was just thinking I could do something like that (i.e. use an ApplyConstruct)
to rename properties if I needed to. Btw, for your example I ended up having
to define a second ApplyConstruct (see below) to pass through all the non
ACMSReportData resources, namely the object resources that were auto-classified
using the property ranges, which is somewhat ironic :)
CONSTRUCT {
?s ?p ?o .
}
WHERE {
?s ?p ?o .
OPTIONAL {
?s a :ACMSReportData .
?s a ?sClass .
} .
FILTER (!bound(?sClass)) .
}
Anyway, thanks again, I think I'm starting to "get it".
jeff
From: [email protected] [mailto:[email protected]]
On Behalf Of Irene Polikoff
Sent: Tuesday, March 22, 2011 12: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
