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
