Holger, A SPARQL Motion script and the new functionality for importing tabular data does seem like the best way to go. This is intended to be used by a data preparation team who understand the multiple source domains of the input data and I would want to add the burden of them having to learn to use TBC. This approach would allow the data to be loaded much earlier in their process (i.e., separating them from their spreadsheets earlier) than I had initially envisaged. The data could be staged in a repository for cleansing, formatting, transformation, harmonization, and validation, before committing it into the gold standard repository for access to our downstream modeling projects. I have seen the workflow tool being developed and it would be perfect here. I am assuming that we can deliver the functionality in these scripts to them in a TopBraid Live application.
I am going to take a look at this in the first week of March and will let you know how it goes. Arthur On Jan 19, 2010, at 8:51 AM, Holger Knublauch wrote: > Hi Arthur, > > as far as I can tell there is currently no way to specify blank nodes in this > spreadsheet importer. I think we should add this option. > > However, you should look at the Semantic Tables back-end, that allows you to > open .tsv, .csv or .xls files directly and will turn them into RDF models. > Those RDF models have the advantage that the instances (and column > properties) contain references to the row and column indices in their > original spreadsheet. This makes mapping tasks easier, even if the instances > are just blank nodes. The tables importer actually does not create blank > nodes, but resources with a rather random Id (that includes the row index as > well). > > But your approach to post-processing spreadsheet importer results with SPARQL > sounds right, and SPIN should be very helpful in that. I would propose > starting with the canonical default import of the Semantic Tables back-end, > and then do any customizations (e.g. changing datatypes, aligning ontologies > etc) using SPIN-based mappings. I had a blog entry on this recently. > > http://composing-the-semantic-web.blogspot.com/2009/08/ontology-mapping-with-spin-templates.html > > I would appreciate your feedback on how any of this works in practice. > > Regards, > Holger > > > On Jan 18, 2010, at 1:23 PM, Arthur Keen wrote: > >> I import tables of time-series data from spreadsheets. The application >> transforms (abstracts) the time series data using SPARQL queries to feed >> downstream models/modelers. >> >> I have a question relative to best practices for naming the elements like >> this (or not naming them). >> >> I use an instance name pattern of MeasurementSourceName_dateTimeMeasured >> so I get URI's like >> http://www.mycompanyname.com/owl/2009/12/fieldName#hughes_13_horizontal_20081221T123000 >> This is quite a long URI pattern repeated for thousands of points - Does it >> matter? I have tried numbering the points "_P#", but this would cause issues >> for inserting new points into the series and I would have to start >> subsequent imports from the highest point number + 1. >> Would it be better to use anonymous instances? Would there be a loss of >> functionality? Is it possible to have the spreadsheet importer create its >> own unique instance names automatically or create anonymous instances? >> >> Regards >> Arthur >> >> From User Manual >> "Pattern for instance names: This defines the pattern that instance names >> are created with, when they are imported. In this example, it is %2-%1, >> which means that an instance name would look like [name of a column #2 >> item]-[name of a column #1 item]. If there are items John in column #1, and >> Doe in column #2 in the same row, then this would be created as Doe-John." >> -- >> You received this message because you are subscribed to the Google Groups >> "TopBraid Composer Users" group. >> 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-composer-users?hl=en. > > -- > You received this message because you are subscribed to the Google Groups > "TopBraid Composer Users" group. > 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-composer-users?hl=en.--
You received this message because you are subscribed to the Google Groups "TopBraid Composer Users" group.
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-composer-users?hl=en.
