To debug, I suggest adding --xslt ""
Which means it just does the conversion to XML.
However the problem here is that the places XSL is a bit richer (more
complicated) in that it accepts 3 kinds of spreadsheet rooms, buildings
These are expressed in the XML as different namespaces.
sorry for the icky syntax -- it's to allow multiple files in one go, and
some might be buildings, others a list of sites or rooms.
Jo Walsh wrote:
> Still no joy with Grinder (for converting csv/xls data into RDF on
> standard patterns for institutional data)
> Here is how far i got:
> Config files for different kinds of data are in etc/
> Example: buildings data
> $ etc/place.py
> Removed the in: line - use --in to grinder instead
> Changed all the id.southampton URIs to id.ed URIs
> (See grinder --help for more of the options.)
> $ bin/grinder --config etc/places.cfg --in
> Without customisation this dumps out a blank graph with Soton boilerplate
> Now is it better to :
> - edit lib/places.xsl (ugh)
> - edit the csv to create the field names that grinder expects
> - add a mapping of field names to predicates somewhere else in the conf?
> Similarly what is best to do where we have custom fields (building
> energy rating, local classification systems)?
> Looking at the example of
> $ var/UoSBuildings.csv
> Edited our csv to make sure it has 'lat','long','id' and 'name'
> Still have no output from grinder though.
Christopher Gutteridge -- http://id.ecs.soton.ac.uk/person/1248
You should read the ECS Web Team blog: http://blogs.ecs.soton.ac.uk/webteam/