[openbiblio-dev] Collections and API

Sat Feb 12 11:48:14 UTC 2011

On 11 February 2011 23:16, William Waites <ww at styx.org> wrote:
> Had a look through collection.py controller. Apart from
> the obvious refactor of factory functions wanting to be
> somewhere in the models part of the code (but not necessarily
> on the model!) there are some observations, the critical
> ones (that I think need to be dealt with before this can
> be put facing the public) are:
>
>  - modelling is funny, why bb:Collection and rdfs:member
>    instead of bibo:Collection and dcterms:isPartOf ?

First of thse I thought we discussed on irc:

* Understand bibo:Collection is more like a Journal (with its
collection of articles). These are more like reading list and we don't
want a list of these collection to show up journals! Hence thought
best to coin our own for the time being. Happy to change this.

* I'm a relative RDF schema newbie and sometimes the number of options
is rather confusion. I talked with Ben O'Steen and we thought about
rds:members, something in ORE and dcterms and went for rdfs:member as
it seemed the simplest.

>  - the use of cursors in that way is dangerous because
>    it skips the result value type processing

Ack.

> There is extended commentary at the top of collection.py
> itself, I'll start actually working on the code toorrow
> evening, but I would be happy to hear the rationale
> behind the first of these - I think it throws away a
> good amount of coherence for no obvious reason. The
> second just needs fixed. The rest of the observations
> aren't on the critical path.

I've responded to the commentary :)

<https://bitbucket.org/okfn/openbiblio/changeset/15b818c6c494>

Also please see:

<https://bitbucket.org/okfn/openbiblio/issue/18/convert-domain-objects-to-from-json>
- needs completing especially handling of ids.
<https://bitbucket.org/okfn/openbiblio/issue/19/refactor-collection-api-to-use-collection>

Rufus