[ckan-dev] [ckan] Would be good to find another solution for the dataset URL rather than one generated from the dataset title (#1233)

Tue Oct 1 11:57:26 UTC 2013

Hi,

I've faced this difficulty in my application, due to business requirements.

> Using UUIDs in the dataset URLs probably wouldn't fly because, as you 
> say, the URLs would be ugly.
>
> I think you're probably right that the datasets should be namespaced 
> under their owning organizations or under their owning user if they 
> don't belong to any organization. Unfortunately I imagine that'd be 
> quite a difficult change to make in CKAN.
>

In my case, I would like to allow users to upload files which would 
possibly have the same title. For example: "rain" data is probably 
different from different locations, but users on those different 
locations still call what they observe "rain". You know... if you have 
user B trying to upload _/resource/_ "rain.csv" but user A already done 
that, CKAN will not permit duplicate names. Employing distinct UUIDs 
does not help because, despite URLs will be certainly different, 
_/resource names/_ in CKAN database would still be the same, which is 
not allowed. Similar trouble happen with package (dataset) names, for 
example.

In order to solve the problem, I've created a layer on top of Action API 
and "FileStore API" (sic) which manages (from the business point of 
view) how I create users, organizations, packages (datasets) and 
resources. This layer also makes life easier to upload files. In a 
nutshell, this layer is responsible for making sure that object names in 
CKAN database are distinct, even if _/apparently/_ they look the same 
(have same names/titles) when user A and user B see these objects.

At the moment, I do not allow users to visit the CKAN instance directly, 
I mean: users manage objects using my web application, not CKAN 
directly. So, the layer I've mentioned can be called locally (in the 
same server) without spending any additional time with calls over the 
network. CKAN does not even respond to HTTP requests in my installation, 
because I access CKAN functionalities locally via CKAN API.

Cheers :)

Richard Gomes
http://rgomes.info
http://www.linkedin.com/in/rgomes
mobile: +44(77)9955-6813
inum <http://www.inum.net/>: +883(5100)0800-9804

On 01/10/13 10:21, Sean Hammond wrote:
>
> Using UUIDs in the dataset URLs probably wouldn't fly because, as you 
> say, the URLs would be ugly.
>
> I think you're probably right that the datasets should be namespaced 
> under their owning organizations or under their owning user if they 
> don't belong to any organization. Unfortunately I imagine that'd be 
> quite a difficult change to make in CKAN.
>
> Regarding changing the name vs changing the URL, in CKAN datasets have 
> both a name and a title. The name is used to form the URL, the title 
> isn't. I think it's possible to change the title without changing the 
> name or URL (using the API). I think it's just a feature of the web 
> interface that when you change a dataset's title it also updates the 
> name/URL for you.
>
> I think this kind of discussion is better on the ckan-dev mailing list 
> rather than on a github issue, so I'm closing this now. Feel free to 
> discuss further on ckan-dev.
>
> —
> Reply to this email directly or view it on GitHub 
> <https://github.com/okfn/ckan/issues/1233#issuecomment-25435651>.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20131001/562b279c/attachment.html>