DCAT Profile Support

[philipashlock]

Does this support DCAT profiles? For example, can you validate a harvest source against a DCAT profile that defines certain required fields?

It looks like there's some documentation for a Europe-wide DCAT profile at:
https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/dcat-application-profile-data-portals-europe-final

[amercader]

Not really. For now it only supports exposing and importing metadata dumps [1] that have been serialized following a specific DCAT profile, which is effectively the European one that you linked to, although currently there is only partial support for all fields defined there.

There is no validation as such but that should be easy to add, in a similar way to other CKAN harvesters.

Hope this helps.

[1] https://github.com/ckan/ckanext-dcat/tree/master/examples

[letmaik]

This would be useful for the "spatial" and "temporal" fields which are more clearly defined in the GeoDCAT-AP profile currently being developed. Is there any handling of those two fields in the harvester currently?

[trickvi]

@amercader has this issue been solved with #19 ?

[amercader]

@philipashlock Work on DCAT profiles started as part of #19 (ingesting RDF) and will be finished with #28 (producing RDF). The base profile is based on the European DCAT-AP, but it should be generic enough for most cases.

@neothemachine @tryggvib There is the following support for the temporal field:

ckanext-dcat/ckanext/dcat/profiles.py

Line 110 in 43af079

def _time_interval(self, subject, predicate):

This essentially supports temporal intervals defined with both schema.org startDate & endDate and W3C Time hasBeginning & hasEnd.

As for the spatial field, as there wasn't a clear convention on how to define it, for now the base parser will just extract an URI for the spatial field, and is left to the specific profiles to extract more detailed information (as in this example).
As part of the remaining work on #28 I'm really keen on better supporting the spatial field. If GeoDCAT-AP provides a clear guidance on how to do that, that would be fantastic. It looks like it's still a work in progress though, @neothemachine do you know the status of this and how safe it is to use it as guidance? I'm also not sure if that covers complex geometries apart from bounding boxes.

[letmaik]

@amercader I just recently started following the GeoDCAT-AP mailing list, but from what I see I think it is relatively safe to at least partially follow it. The draft defines spatial as being a bounding box only, which at a minimum must be given as either WKT or GML. With GML it is really a bounding box fixed by its XML structure, but with WKT it's just a polygon, so I'm sure as time comes this will lead to people putting more complex geometries as WKT polygon. I don't think anyone will use GML here to be honest.

The WKT form would be:

@prefix dct: <http://purl.org/dc/terms/> .
@prefix locn: <http://www.w3.org/ns/locn#> .
@prefix gsp: <http://www.opengis.net/ont/geosparql#> .

[] dct:spatial [ a dct:Location ;
    locn:geometry "POLYGON((-10.58 70.09,34.59 70.09,34.59 34.56,-10.58 34.56,-10.58 70.09))"^^gsp:wktLiteral 
   .]

I think this is sensible and will actually be used once the spec is complete. It integrates nicely with GeoSPARQL as well.

So my suggestion would be to follow the WKT route and implement simple bounding boxes for now, as this is what the spec says. Of course, if it's easy to implement support for arbitrary WKT polygons, go ahead, but I guess the majority will stick to bounding boxes.

[amercader]

Thanks @neothemachine that's useful. We'll see how it goes.

Cheers

[amercader]

Full documentation for the profiles support is here: https://github.com/ckan/ckanext-dcat#profiles

@neothemachine I ended up implementing the GeoDCAT-AP recommendation for the spatial field, you can see it in action here:

http://demo.ckan.org/dataset/newcastle-city-council-payments-over-500.xml
http://demo.ckan.org/dataset/newcastle-city-council-payments-over-500.ttl

[letmaik]

Looks good, nice work! :)