[ckan-dev] VoID
Ross Jones
ross at servercode.co.uk
Fri Feb 15 18:29:11 UTC 2013
Hi Tim,
Content negotiation or adding .rdf to the dataset URL should get you the
RDF repr of the meta-data, even on 2.x (see
http://hub.healthdata.gov/dataset/adoption-foster-care-analysis.rdf).
>From a quick glance it is still using the legacy_templates (
https://github.com/okfn/ckan/blob/master/ckan/templates_legacy/package/read.rdf)
so its lifespan is probably only as long as they are still available.
Sorry it lack of documentation caused you to do more work than necessary
:( You can override that template if you'd like to tweak the DCAT though.
I think deprecating ckanext-rdf was, at the time, the correct thing to do,
but perhaps with a bit of polish and optimisation it could be useful again?
Would definitely be the right place to add VoID support I think if the
deps for the package could be reduced. I know the templating of the format
probably isn't ideal, but it *is* fast.
I'm not sure of what the CKAN team's plans are for linked-data, but I'll
see if I can find out what our plans are at data.gov.uk when I'm back at
work next week. Failing that, I'm happy to help anyone in the community
who might want some help on the CKAN side in implementing this stuff.
Ross
On Fri, Feb 15, 2013 at 5:32 PM, Timothy Lebo <lebot at rpi.edu> wrote:
> Ross,
>
> I'd love if CKAN used VoID (or, DCAT) natively.
>
> It certainly would help me access the listings in an arbitrary CKAN.
>
> For example, it was a bit more difficult than we would have hoped for us
> to get the entries from http://hub.healthdata.gov/dataset (some notes
> at [1]).
>
> It would have been great to just grab http://hub.healthdata.gov<http://hub.healthdata.gov/dataset>/void.ttl
> and run with the RDF descriptions of all the datasets (some notes at [2]).
> Or -- even better -- just conneg http://hub.healthdata.gov/dataset with
> an Accept: application/rdf+xml… (several other ways are mentioned in [2]).
>
> Please note that W3C's DCAT [3] can be used to describe _any_ kind of
> dataset, not just RDF datasets.
> We ended up crawling CKAN to produce DCAT entries for all of its datasets
> (notes at [4]; an example at [5] which includes W3C's PROV-O assertions at
> two levels).
>
> I think VoID should be seen as a special case of DCAT, in the case where
> one has RDF datasets.
>
> There are some nice features that VoID offers that DCAT does not (such as
> the "top level" http://hub.healthdata.gov<http://hub.healthdata.gov/dataset>/void.ttl file
> to "just get the listing"), and CKAN's needs could inspire the W3C GLD team
> to get them into DCAT, which is still in development.
>
> Regards,
> Tim Lebo
>
> [1]
> https://github.com/jimmccusker/twc-healthdata/wiki/Accessing-CKAN-listings
> [2]
> https://github.com/jimmccusker/twc-healthdata/wiki/Using-VoID-for-Accessibility
> [3] http://www.w3.org/2011/gld/wiki/Data_Catalog_Vocabulary
> [4]
> https://github.com/jimmccusker/twc-healthdata/wiki/Retrieving-CKAN%27s-Dataset-Distribution-Files<https://github.com/jimmccusker/twc-healthdata/wiki/Retrieving-CKAN's-Dataset-Distribution-Files>
> [5]
> https://github.com/jimmccusker/melagrid/blob/master/data/source/data-melagrid-org/e-geod-11584/access.ttl
>
>
> On Feb 15, 2013, at 12:01 PM, Ross Jones <ross at servercode.co.uk> wrote:
>
> I've been looking at http://www.w3.org/TR/void/ and thought it might be
> worth taking a look at implementing it for CKAN as it has been asked for
> more than once, and seems like a useful way of finding the datasets that
> are available as RDF.
>
> As CKAN doesn't really model the relationships between datasets, other
> than membership of groups, I wondered whether it would be enough for the
> void file to simply be a collection of void:Datasets so that at least it
> would aid in discovery via void.(rdf|ttl) even if it didn't attempt to
> describe the relationships between them?
>
> Any suggestions, or general guidance appreciated.
>
> Ross
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
>
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130215/bd0aaa38/attachment-0001.html>
More information about the ckan-dev
mailing list