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

[Pabitra Dash]

Hi Richard,
 
Glad to know you have solved this typical business requirements where the resource name can be duplicate. Was wondering if the source code is available for this solution?
 
Thanks,
Pabitra

 
Date: Tue, 1 Oct 2013 12:57:26 +0100
From: rgomes.info at gmail.com
To: ckan-dev at lists.okfn.org
Subject: Re: [ckan-dev] [ckan] Would be good to find another solution for the dataset URL rather than one generated from the dataset title (#1233)


  

    
  
  
    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:
          +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.
      
      

      

    
    

  


_______________________________________________
ckan-dev mailing list
ckan-dev at lists.okfn.org
http://lists.okfn.org/mailman/listinfo/ckan-dev
Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20131001/5af5b3f4/attachment-0001.html>