[ckan-discuss] CKAN package ID debate

[David Read]

Thanks for the feedback!

301 redirects seem attractive, but the list of redirects would have to
be stored, replicated across CKAN instances, and you could never reuse
the name again for a different package. Listening for 301s also
complicates clients. So quite a trade-off.

I'd not considered the RDF implications. We could certainly allow IDs
as well as names in the web interface. Will, what do dbpedia/wikipedia
do if an article changes name?

Yes, the ID is randomly generated, following the mercurial model,
thinking ahead to the multiple CKAN instances. So the ID is not
deduceable but as long as you keep records of them, data can be
reloaded into a new database with the same ID. So yes, we'll have to
commit to this, should we reload the database for any reason.

> if two people add an identically named package in two
> different places it will get flagged as a conflict

I like names being unique (as well as IDs) and I don't see any reason
to change that.

David

> If the switch to using IDs is made, we should make sure that
> http://ckan.net/package/id works so we can have stable identifiers
> to use in the RDF. Unfortunately the URIs will be less readable
> but perhaps that is the tradeoff that needs to be made for the
> ability to rename a package.
>
> On the other hand it is arguably bad style to expose what is
> a non-reproduceable (it uses the random uuid.uuid1() does it not?)
> internal identifier to the outside world. Any automated tools to
> (re)construct part of the database will normally come up with
> different IDs on each run. Any external user that keeps track
> of IDs may have their data invalidated if some part of CKAN needs
> to be regenerated for some reason.
>
> Also, in the distributed CKAN model, if two people add an
> identically named package in two different places it will get
> flagged as a conflict and sooner or later a decision has to be
> made about merging them or renaming one or the other. If we
> use random IDs it may never get flagged. But maybe it isn't
> really useful to rely on package names for this kind of conflict
> detection anyway.
>
> Cheers,
> -w
>
> --
> William Waites           <william.waites at okfn.org>
> Mob: +44 789 798 9965    Open Knowledge Foundation
> Fax: +44 131 464 4948                Edinburgh, UK
>