[ckan-dev] CKAN and RDF/SPARQL
David Raznick
kindly at gmail.com
Thu May 26 00:35:29 UTC 2011
On Wed, May 25, 2011 at 10:42 PM, 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.
We could start representing extras values as xml instead in the database and
just decode to python as json like. We could add this as a configuration
option at least. This would be stored procedureable in postgres using
xpath.
> None of forms, Solr or the API help
> here.
>
I personally think we should depreciate json/xml in the extras values fields
altogether. It should not be too difficult or troublesome. ckan.net for
example is always using the extras field as a string anyway (just looked at
the database), it will not be difficult to sort out this is harvesting code
which is the only user of it I think.
Should this solve the issue?
>
> 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.
>
>
Cheers,
> -w
>
> --
> William Waites <mailto:ww at styx.org>
> http://river.styx.org/ww/ <sip:ww at styx.org>
> F4B3 39BF E775 CF42 0BAB 3DF0 BE40 A6DF B06F FD45
>
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20110526/5b94ba25/attachment-0001.html>
More information about the ckan-dev
mailing list