[ckan-dev] ckanext-rdf: Consolitdated RDF handling for CKAN
William Waites
ww at styx.org
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
More information about the ckan-dev
mailing list