[ckan-dev] ckanext-rdf: Consolitdated RDF handling for CKAN

Tue May 31 10:17:12 UTC 2011

Hi Friedrich, good work.

] * OPMV provenance (*ducks first bottle*)

This is generally fine and not required by any stretch. Where it
will start biting is when you want to find out if a dataset comes
from the ckan being harvested, or if it comes from somewhere else
and is being re-exported...

] * Formats normalization (not a converters job)

The newer RDF stuff doesn't do this much either. It just says
there is a format tagged with a particular tag.

To do this properly means actually having proper mime types used
in the CKAN.

] * Differentiation between catalogue records and datasets (*ducks
] spanish cucumber*)

Well this is an important one. You won't be able to speak the
DCat protocol that we agreed in Edinburgh if you do this.

] * Any references to the various representations of the data on
] semantic.ckan.net

As it should be.

] Added features:
] 
] * BNodes for arbitrary package extras (*ducks 200wpm linked data battlesword*)

I like this, personally. But some people find bnodes hard to work
with.

] While this makes little sense on its own, I hope that we can add
] support for RDF as an almost natural representation soon and then
] won't have to distinguish between semantic CKAN and mundane CKAN.

"almost natural" heh.

I guess the biggest problem with this is when you use CKAN as an
aggregator of different kinds of sources, CSW, Socrata, whatever,
and then re-export that as RDF you get generation loss just like
when you copy a cassette tape and then copy the copy, only worse.

CKAN's data model has to seriously improve for this to not be the
case, but I don't want to reopen the debate about the model. So
long as round tripping is possible one day...

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