Dimensions for columns attached to "external" URIs

[Adr Ges]

Hi group,

I'm working on some Data Cubes for the Swiss EPA equivalent called BAFU. The whole stuff is in a github repository, see https://github.com/lindas-uc/bafu_ubd for the complete repository.

I'm having a bit problems interpreting dimensions and would like to get some feedback on how to handle that properly. You can get an idea of how the data owner exposes his data in a spreadsheet here: https://github.com/lindas-uc/bafu_ubd/blob/master/input/ubd/ods/UBD0066.ods, you will find among others these columns:

site

plot

community

Xmin

Ymin

Xmax

Ymax

altitude

however, in the RDF export these rows are attached to a unique key which is the combination of site & plot. The CSVs I used for that can be found here https://github.com/lindas-uc/bafu_ubd/blob/master/input/ubd/66/UBD0066_site_plotID.csv. In the base table it only references this key, see here https://github.com/lindas-uc/bafu_ubd/blob/master/input/ubd/66/UBD0066_Basetable.csv

I convert the CSVs using RML with the following configuration https://github.com/lindas-uc/bafu_ubd/blob/master/config/ubd66.ttl

and the Data Cube itself is defined here:

https://github.com/lindas-uc/bafu_ubd/blob/master/input/meta/ubd66/qb.ttl

In there you can see that I basically only add dimensions for the keys itself. The problem with that is that a generic Data Cube viewer we work on cannot really figure out if/how it should show stuff which is attached to one of these keys and thus the user will not see them. Am I doing this right and if yes/no, how could I describe these invisible columns?

If you are curious what we do with it, see our generic viewer here: http://cpvrlab.github.io/sparql-table-viewer/

Its code is available on Github: https://github.com/cpvrlab/sparql-table-viewer

BTW if you spot some other issues in my transformations comments or even pull-requests are welcome :)

regards

Adrian

[Kämpgen, Benedikt (AIFB)]

Hi Adrian,

Interesting, do you have resolvable URIs of a dataset (such as [2]) that I can have a look at?

Then I could run it through our Linked Data Cubes Explorer [1] and find out where the modelling errors lie.

Best

Benedikt

[1] http://km.aifb.kit.edu/projects/ldcx/
[2] http://estatwrap.ontologycentral.com/id/tec00114#ds - will provide RDF if asked via the HTTP accept header

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 9654-824
Email: benedikt...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en

--
You received this message because you are subscribed to the Google Groups "Publishing Statistical Data" group.
To unsubscribe from this group and stop receiving emails from it, send an email to publishing-statisti...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Adr Ges]

Hi Benedikt,

Sorry for being super late, I did not had resolvable URIs before, which is now fixed.

Entry point to the dataset:

http://environment.data.admin.ch/ubd/66/qb/ubd66

Please let me know, if something doesn't work as expected.

regards

Adrian

On Wednesday, March 2, 2016 at 11:52:51 AM UTC+1, Benedikt Kämpgen wrote:

Hi Adrian,

Interesting, do you have resolvable URIs of a dataset (such as [2]) that I can have a look at?

Then I could run it through our Linked Data Cubes Explorer [1] and find out where the modelling errors lie.

Best

Benedikt

[1] http://km.aifb.kit.edu/projects/ldcx/
[2] http://estatwrap.ontologycentral.com/id/tec00114#ds - will provide RDF if asked via the HTTP accept header

--
AIFB, Karlsruhe Institute of Technology (KIT)
Phone: +49 721 9654-824
Email: benedikt...@kit.edu
Web: http://www.aifb.kit.edu/web/Hauptseite/en

To unsubscribe from this group and stop receiving emails from it, send an email to publishing-statistical-data+unsub...@googlegroups.com.

[Adr Ges]

To explain my issue better I will post some URIs for comparison:

The standard dimension points to a URI and in there a rdfs:label, see for example: 

http://environment.data.admin.ch/ubd/66/landuse/grasslandextensiv

You will get a rdfs:labe and rdfs:comment back. This is easy to query in a generic viewer and we simply show what's behind rdfs:label

However, the dimension I mentioned is one single column in the original data. It is basically a unique key of multiple values, which can be seen in this example:

http://environment.data.admin.ch/ubd/66/siteplot/58_1

So to this measure point (it's a sensor) we have multiple things attached like lat/long (in Swiss coordinate system), height, municipality etc. This is important to show in the default-viewer and currently we don't as I don't have a single rdfs:label in there and I wouldn't know how to properly describe that within Data Cube vocabulary.

regards

Adrian