[ckan-discuss] CKAN package ID debate

Wed Mar 24 10:18:22 GMT 2010

On 10-03-24 08:38, Sean Burlington wrote:
> Can I suggest another  option for consideration
> 
> continue to use package names - if someone requests a package by a
> name that has changed this could result in a 301 redirect to the new
> name
> 
> This would not require a change to the API, and would allow names to
> change without breaking things.
> 
> It may be best to use package IDs I'm not sure - just wanted to throw
> this into the pot.

In a similar vein, this has implications for the regular package
URIs as well. The RDF descriptions we are making refer to the
http://ckan.net/package/foo and if a name is changed then the
links are invalidated.

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