Print

Print


29 maj 2013 kl. 21:44 skrev Tom Morris <[log in to unmask]<mailto:[log in to unmask]>>
:

That sounds very interesting

Thanks!

On Wed, May 29, 2013 at 1:44 PM, Niklas Lindström <[log in to unmask]<mailto:[log in to unmask]>> wrote:
Hello!

At the National Library of Sweden, we are working on a new cataloguing system (which will be live at the end of this year). It is comprised of a scalable backend system for data (with e.g. separation of storage and indexes), and a cataloguing client (based on HTML5 and JavaScript).
...
To this end, we have decided to convert our MARC data into a form expressing entities and relations, using the RDF data model. Our conceptual design focuses on being in the web of data, linking to and extending the existing datasets about and related to bibliographic information. Our current approach encodes conversions using JSON-LD, which we use directly in the client and for indexing.

Can you provide a pointer to the data model to shortcut having to rummage through the Github repos?  Is there something that summarizes what vocabularies you are using and what you are adding yourselves?

Absolutely. I must state though that this is very much in a state of flux (..). We refactor every now and then, with lots of renamings and reshaping. The given paths below are to a branch I'm hacking in at the moment. It may disappear within a week.

Regarding mapping our way out of MARC, the ambition is to create declarative data to drive the underlying code, so that as much as possible can be gleaned from that (with the principle that the decision points must not lie codified in some turing-complete program code, tied to platform details). Of course, that's easier said than done, but the currently used declarations (some unused, some sketchy at best) are at:

    https://github.com/libris/librisxl/blob/new-marcframe-converter/whelk-extensions/src/main/resources/marcframe.json

We'll be "filling in" this from various sources (involving our format experts) over time as be become more sure about details (we have lots lying around not yet included in the mappings above). One important external source of input is the BibFrame vocabulary and the LoC xquery conversion implementation. And the debates on this list, of course.

As for vocabularies, there is more stuff hidden in local notes and plans than visible in the repository. But some ideas may be gleaned from the JSON-LD context (which aspires to map to BibFrame where sensible, also used as the default @vocab):

    https://github.com/libris/librisxl/blob/new-marcframe-converter/whelk-extensions/src/main/resources/context.jsonld

(A worry in this work is the creation of yet another http://xkcd.com/927/-situation. I cannot say that I have definitive opinions in all matters concerning vocabulary mappings/reuse, but it is a real concern. The indirection via a JSON-LD context is to some extent mitigating this (right now), as we can change outward mappings later on. But only if conceptual entities and shapes of expressions are nigh identical. It's still fundamentally important to know e.g. if the item described is an agent, an event or (at worst) a complex involvement. And what to do with any remaining vagueness..)

(We are a bunch of people attending ELAG this week by the way, so anyone here should feel free to ask us about this. Some of us (including me) will be at the FRBR+UI-workshop tomorrow afternoon where some of these things are likely to come up.)

Cheers,
Niklas


Tom


Of course, the nature of the entities is where the challenge lies. For obvious reasons, we keep a close eye on BibFrame, and our intent is definitely to help out in shaping it into a usable and preferable bibliographic vocabulary.

We do share certain concerns that have been raised on this list. Still, there is a benefit to BibFrame as it emerges out of MARC. Our time is limited, and it is essential that we do not stray from the important details in an effort to generalize expressions using common terms.

At the same time, we see it as fundamentally important to express "consensual" entities, such as persons, and ideally model direct relations to avoid complexity. But we know that various events/involvements/actions are sometimes explicit in details of MARC, and we are striving to express this uniformly. A rich set of title variations along with ambiguous entities is also a major obstacle. This is sometimes at odds with maintaining as simple a shape as possible, and it is yet unclear which lines must be drawn for this to become palatable linked data (i.e. without overwhelming general consumers). We believe this is part of the current issues found with BibFrame, and hope to be able to work with you on this (or join in the venture) to find good paths forward through the various jungles of details.

Our development is fully open. The code for our backend system, including the MARC conversion implementation, is at:

    https://github.com/libris/librisxl

And our client code at:

    https://github.com/libris/kitin

We look forward to elaborate on our progress and hope to collaborate on the future shapes of bibliographic information.

Cheers,
Niklas

--

Niklas Lindström
Developer
National Library of Sweden (KB)
[log in to unmask]<mailto:[log in to unmask]>
http://www.kb.se/


10 maj 2013 kl. 17:27 skrev "McCallum, Sally" <[log in to unmask]<mailto:[log in to unmask]>>:

Hello all,

We have been hearing that some of you are testing and pushing around aspects of the BIBFRAME model and we are interested in hearing from you.    Please tell the list or send me an email.   Nothing is too small!

Sally

**************************
Sally H. McCallum
Chief, Network Development and Standards Office
Library of Congress,  101 Independence Ave., SE
Washington, DC 20540  USA
[log in to unmask]<mailto:[log in to unmask]>
Tel. 1-202-707-5119<tel:1-202-707-5119> -- Fax 1-202-707-0115<tel:1-202-707-0115>
**************************