[ckan-dev] dataset urls
David Raznick
kindly at gmail.com
Wed Apr 25 00:07:25 UTC 2012
We are talking about comment links atm.
Re name change you get broken
> links on github if you rename your repo.
We could also implement a
> simple redirector by looking up in the dataset revision table for old
> names :-)
>
We considered this but it would not work unless we were sure that all names
are unique forever.
>
> > changing *HARD* because the last thing we want to do is confront users
> with
> > with more choices then necessary. They should not be forced to think
>
> Why shouldn't it be like github repos. You can change but you are
> warned about problems. Pick a good name.
>
If we cared that much about the name we would not sluggify the title and
force people to make good ones. Github forces you to do this.
> through the consequences of their actions and read some blurb as why its
bad
> if we can make it avoidable.
Understood. That said I frequently type in the names of familiar
> datasets (but i may be unusual). That's never possible once we have
> somewhat random id in there. But that's then a question of usage. I
> think DataHub at least is more like GitHub (or Twitter) in that
> regard: I care about this entities name a lot (compared to say
> StackOverflow where I always arrive via google or similar).
>
> I think that the relevance of the name has much less consequence to us
then github but more then stackoverflow. I am happy to keep the ability to
reference by name only in the url, but not give that out when
systematically creating a permanent links, like in this case.
This can include things like activity streams, social stuff, apis to update
qa information, feeds, and anywhere we give out urls that we expect other
services to use. We could use just uuids for these but some would also
benefit from also being less ugly.
At the same time I would have no objection to, say, shortening
> resource uuids ... (but what is cost/benefit?)
>
> Rufus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20120425/3f936843/attachment-0001.html>
More information about the ckan-dev
mailing list