[ckan-discuss] CKAN API and relationships

David Read david.read at okfn.org
Thu Jan 26 14:02:44 GMT 2012


Richard,

I've made the changes now for the 'links_to' relationship. Do you want to
try out creating links on http://test.ckan.org/ ? It will be on
thedatahub.org soon.

Also the updated docs are here:
http://readthedocs.org/docs/ckan/en/latest/api.html#model-formats

David

On 23 January 2012 17:10, David Read <david.read at okfn.org> wrote:

> On 23 January 2012 16:11, Richard Cyganiak <richard at cyganiak.de> wrote:
> > Hi David,
> >
> > On 23 Jan 2012, at 12:54, David Read wrote:
> >>> We need another type: links_to.
> >>
> >> Yes, these are designed to be added when good use cases come along
> >> like this, so I will add it. There's an argument for making it
> >> arbitrary, but I think we'll keep it constrained whilst we see how it
> >> gets used.
> >
> > FWIW, we brainstormed possible other relationship types during
> November's CKAN+LD meetup, and I think all other types that came up do fit
> more or less comfortably into the existing set.
> >
> >> I'll see if we can easily add a 'count' property for this one, to
> >> store the number of links,
> >
> > That would be really great.
> >
> >> I've put these requests in a ticket http://trac.ckan.org/ticket/1695
> >> and since it should be quick, I'll aim to get these onto the datahub
> >> in the next couple of weeks.
> >
> > That's great news! Looking forward!
> >
> >> By the way, you may wish to play with these using the version 3 of the
> >> API - we'd be interested in your views. It's RPC style rather than
> >> RESTful. The v1 and v2 APIs remain as RESTful wrappers over calls such
> >> as 'package_relationship_create'. There are still rough edges, such as
> >> 500 error if you get don't send the right parameters, but otherwise
> >> we're pleased about the extra feedback it gives. Docs:
> >> http://readthedocs.org/docs/ckan/en/latest/apiv3.html
> >
> > Yeah I've seen the v3 API docs. And to be honest I'm not a big fan.
> >
> > It's a bit hard for me to articulate why. From my point of view –
> someone who started knowing nothing about the API, doesn't have much time,
> and wants to learn just enough to get a particular small job done – the v2
> version just seems more approachable.
> >
> > Figuring out how to read from v2 is really trivial. All I need is this
> little table here, and a web browser to test some calls:
> > http://readthedocs.org/docs/ckan/en/latest/api.html#model-resources
> >
> > In the v3 version, I can't do anything in the browser; I need to start
> messing around with curl to do even the most simple interaction. To be
> honest, when I saw that I need POST to read from v3, I cursed a little and
> went right back to v2… The exposed function calls in v3 also seem more
> low-level. v2 feels like it's on a higher level of abstraction.
> >
> > (If CKAN had *only* the v3 API, then I'd maybe grumble a bit about not
> being able to read with GET, and get on with it. But with both the
> REST-style v2 and the RPC-style v3 available, there is very little that
> draws me to v3…)
> >
> > I apologize for this rather unproductive and negative message :-/
>
> Not at all, it's all useful feedback. This encourages us to maintain
> the RESTful interfaces, certainly for basic data operations that suit
> it. I suspect the javascript developers out there are much happier
> with the RPC-style interface for doing autocomplete and other whizzy
> form things. And the people writing custom interfaces in Drupal etc.
> will appreciate the richer RPC calls than REST would ever give us. So
> I hope we are cater for broad needs.
>
> Dave
>
>
> >
> > Richard
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-discuss/attachments/20120126/35db871f/attachment.htm>


More information about the ckan-discuss mailing list