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

William Waites ww at styx.org
Sun Oct 9 16:59:48 UTC 2011


On Sun, 09 Oct 2011 09:13:04 -0700, pitman at stat.Berkeley.EDU (Jim Pitman) said:

    JP> No. Need someone more familiar with RDF than I am. I have been
    JP> burned too many times by RDF to want to touch it again soon.
    JP> Need a cook more experienced with hot flames.  Any volunteers?

I've looked at ORE a bit in the past, and (ab)used a subset of it to
represent collections (union) of RDF graphs. It is not simple, and if
you look at it in a certain way has some overlap with the problem
space addressed by FRBR (multiple manifestations/representations or
versions) and BIBO (which has its own notion of collection, as in "an
bibo:Article dc:isPartOf a bibo:Issue (a kind of collection)
dc:isPartOf a bibo:Journal (a kind of collection) dc:isPartOf a
bibo:Collection (say held in a library or on a bookshelf)).

It should be possible without too much trouble to translate bibserver
collections to aggregations, probably using a subset of the latter,
and necessarily using some of the collection-type metadata that you
mention elsewhere in the mail. Definitely makes sense to keep in mind
the abstract data model of ORE to at least inform some of the thinking
for stabilising the bibserver collections.

*If* there were a straightforward mapping from BibJSON to JSON-LD or
else a sane RDF representation of BibJSON, it would be possible to
generate an ORE representation of the same just by writing a few
logical rules. Would take a bit of time and effort to get it right, of
course.

Does it make sense to do this? I don't know either how widely used ORE
is in the wild. It doesn't seem to get mentioned very much in places
that I pay attention to, but that's hardly an exhaustive or unbiased
sampling.

-w




More information about the openbiblio-dev mailing list