[openbiblio-dev] [bibserver] changing handling of collections from frontend to get them working properly again now that collections are stored as separate objects (937d3e2)

[Peter Murray-Rust]

On Mon, Oct 10, 2011 at 8:30 AM, Rufus Pollock <rufus.pollock at okfn.org>wrote:

>
>
> > Actually no, it is very simple, and already accomodated by standard A&I
> service records.
> I don't think it is -- as evidenced by some of this discussion below.
> We *really* are going to have think hard about this as well as what is
> important. Implementing all possible requirements here could be very
> expensive so we should focus on the simplest / highest value items
> first. I think it is important we have a tool that does a few things
> well rather than trying to do lots and lots of stuff (and doing it
> badly).
>
> [...]
>
> >> I really think we want to focus on the user stories first and then
> >> decide whether one concept/ / domain object (e.g. "Collection") is
> >> sufficient for the domain we are trying to cover.
> >
> > OK. I am already convinced we need to go with a very general, flexible
> concept of "Collection" which is capable of adapting to
> > whatever use case we can throw at it. Mathematically, collections are
> nothing more or less than sets of records. We need a way to allow
> > users to simply specify whatever sets they care about. If there are
> simple boolean relations between sets, especially A subset of B and
> > A disjoint from B, there must be simple ways to indicate this in the
> collection metadata. Its as simple as that. Do not need any more use
>
> You realize this is really pretty complicated right!
>
> > cases to commit to respecting those structures in the data model. I think
> it is mostly a matter of *where* these structures are kept, and I think
> > the answer is simple, you either put this info directly in the meta
> record for a collection, or you link out to this info (e.g. as a query
> response)
> > from the collection record.
> > I think we should just try installing simple collection metadata support
> on the above lines, and then start exercising it with actual
> > use cases, for which the publisher collection and departmental
> collections are exemplary.
>
> From what you are saying I think we are going to have to think about
> this really quite hard -- this isn't something we can just "hack" in
> quickly. I may be wrong but this really does not sound trivial.
>
> The idea of Bibsoup is that it is simple. It's a soup where a whole lot of
things are added. Carrot1 does not know about carrot2. It doesn't even know
that they are both carrots.
 Or that they are not potatoes.
Indeed someone may decide that carrot2 is actually a turnip. It doesn't
matter.

The bibsoup itself is a collection only in that it has N items at a given
time and we can iterate over the items 1,2,...N. The serial numbers are only
an iterator. That's to make sure that the data is Open and we can get it
all. But I have no expectattion of the high-level view of this data.

A typical bibsoup is "my thesis". There are 300 entries. They can be
anything that can be expressed in bibJSON. But none of them know about the
others.

If the chef wants to tell us that they are her references, she can use an
aggregating tool (RDF, ORE, HTML lists, whatever). But the entries know
nothing.

Unless you keep it simple as possible we will not survive and prosper. An
undergraduate should be able to understand BibJSON without a manual.

P.


Rufus
>
> _______________________________________________
> openbiblio-dev mailing list
> openbiblio-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openbiblio-dev
>



-- 
Peter Murray-Rust
Reader in Molecular Informatics
Unilever Centre, Dep. Of Chemistry
University of Cambridge
CB2 1EW, UK
+44-1223-763069
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openbiblio-dev/attachments/20111010/b2241b85/attachment.html>