[ckan-dev] CKAN and RDF/SPARQL

Seb Bacon seb.bacon at okfn.org
Thu May 26 10:28:22 UTC 2011


Hi,

On 25 May 2011 22:42, William Waites <ww at styx.org> wrote:
> * [2011-05-25 16:58:25 +0100] David Read <david.read at okfn.org> écrit:
>
> ] Sorry I should have been clearer - I'm talking here about package
> ] properties that don't fit in the core package fields. There's not a
> ] problem with the core package fields mapping comfortably to RDF, are
> ] there Will?
>
> Except as the core data is minimal and it is almost certain that
> more will be needed.
>
> ] And if Ed decides to use any extra fields, can express lists and
> ] dictionaries in our extras fields - they are not limited to string
> ] values. And these can be worked with sanely in CKAN via forms, SOLR,
> ] and (with an extension) the API.
>
> I read from the subject header that SPARQL is a requirement. If this
> were implemented with D2R this means SPARQL-SQL translation. If the
> data is hidden in blobs, absent a JSON parsing stored procedure I
> think this kills the strategy. None of forms, Solr or the API help
> here.
>
> The most practical is probably a worker process that makes the RDF and
> puts it in a real triplestore as soon as possible after the entity has
> been saved.

As I understand the original question, Ed assumed this might be
necessary.  So there are two different parts to the question:

1) How to bext export each Package as RDF
2) How best to expose a SPARQL endpoint for such RDF

For point (2), it seems likely that the right solution would be to
crawl the RDF and insert in a triplestore.

For (1), I'm still unclear and haven't really followed this
discussion.  How can we output RDF?  How is it done at the moment for
consumption by semantic.ckan.net?  (I seem to recall something about
XSLT?)

Thanks

Seb




More information about the ckan-dev mailing list