Hi Carsten

Thanks for the new spec I think it is a great initiative to align many projects 
that are processing MARC records. Here are some general remarks I hope we can 
use to discuss the spec more in depth.

What I'm missing reading the specification is a separate use-case document. In 
the spec I see sections like the introduction of "2 Expressing MARCspecs as 
string" and "2.1" which are design concerns which require a separate discussion 
from the formal part of the document. I mean, I can agree or disagree with the 
design concerns..with the formal section I should be able to say if it is 
correct or not.

The discussion we have here in this email thread deserves a separate document 
of use-cases. Producing Linked Data is only of the cases. Solrmarc is about  
transforming MARC into something that can be send to SOLR. In ILS systems you 
might use it to point to parts of MARC you want to display in a webinterface. 
In catmandu you might want to produce reports. Every use-case can have its own 
needs to make parts of MARC easy addressable.

We need tools like easyM2R, solrmarc, catmandu not only because of the 
verboseness of XPath or because it is tight to one possible serialization of 
MARC. Of course I love to write

100$a instead of /marc:record//marc:datafield[@tag='100']

This opens up a new class of easy DSL tools to process our datasets. 

But..this treats MARC as a document key-value exchange format for 
bibliographical data. And I can't agree with that... or not in a strict sense. 
I can as easily state that MARC is a mark-up language that requires more 
processing after the first mappings have been made. E.g. if you want to map 
260$c to an xsd^date field you really need get rid of the trailing dot '.' at 
the end. MARC is a key-value exchange format only as first approximation.

Using cataloging rules you can get much more information out of the record. And 
I wonder if in a second approximation we could add paths that implement some of 
that logic.

For instance. as stupid example:

245{/$.} : could evaluate to everything in 245 until you hit the first 

In catmandu..we'll we don't have a spec for that. We do the same things as in  
easyM2R and solrmarc and create a small DSL language of functions that get 
MARCspecs as input. Of course we could all agree on a same collection of 
functions like move_field, split_field, copy_field etc etc. But I hope there 
are other options also.


From: Klee, Carsten [carsten.k...@sbb.spk-berlin.de]
Sent: Wednesday, February 19, 2014 2:27 PM
To: 't...@gymel.com'; Patrick Hochstenbach
Cc: v...@gbv.de; librecat-...@mail.librecat.org; perl4lib@perl.org
Subject: AW: [librecat-dev] A common MARC record path language

Hi Thomas and Patrick!

I think the whole problem lies in the limited expressivity of strings. MARCspec 
is pretty much close to XPath at its approach, but without regular expressions 
and functions like first(), last() etc. But even with XPath it would be pretty 
hard to get the character before a subfield in a MARCXML file.

The only solution I can think of, is using regular expressions. And I'm not 
convinced that bringing this into MARCspec is a good idea. As I already 
mentioned in the spec, MARCspec is not independent from the application using 
MARCspec. Taking regular expressions into MARCspec wouldn't make the 
application more usable, but would blow up the specification.

One example:

The data in field 245 is:

"$aConcerto per piano n. 21, K 467$h[sound recording] /$cW.A. Mozart"

The desired result is (rule: take everything from 245 until the string ' /$' 

"Concerto per piano n. 21, K 467 [sound recording]"

Imagine a MARCspec with regular expression. // pseudo code coming up!

marcspec = "245.match(/(.*)\s\/\$/)"
titleData = getMARCspec(record, marcspec)
print titleData[1]
// should result in "$aConcerto per piano n. 21, K 467$h[sound recording]"

Now pretty the same but without the regular expression in the MARCspec.

marcspec = "245"
titleData = getMARCspec(record, marcspec).match(/(.*)\s\/\$/)
print titleData[1]
// should result in "$aConcerto per piano n. 21, K 467$h[sound recording]"

You see, nothing won here.

But an application could provide a special function like

    // get the data before the / or = or else
    regex = new RegExp("(.*)\\s\\" + hitWhat + "\\$")
    data = getMARCspec(record, marcspec).match(regex)[1]

    // now split on subfield
    dataSplit = data.split(/\$[a-z0-9]/)

    // loop everything into result
    for (i = 1; i < dataSplit.length-1; i++)
        result += dataSplit[i] + " "
    result += dataSplit[dataSplit.length]

    return result

In Catmandu or elsewhere the user calls the function


--> this should result in the desired "Concerto per piano n. 21, K 467 [sound 

If there is any other approach you can think of, pleeeease make a proposal or 
give me a substantial discussion here. Otherwise I can't see any options 
solving this problem in MARCspec.


Carsten Klee
Abt. Überregionale Bibliographische Dienste IIE
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz

Fon:  +49 30 266-43 44 02

> -----Ursprüngliche Nachricht-----
> Von: Thomas Berger [mailto:t...@gymel.com]
> Gesendet: Mittwoch, 19. Februar 2014 01:04
> An: Klee, Carsten; 'Patrick Hochstenbach'
> Cc: v...@gbv.de; librecat-...@mail.librecat.org; perl4lib@perl.org
> Betreff: Re: [librecat-dev] A common MARC record path language
> Hash: SHA1
> Am 18.02.2014 17:47, schrieb Klee, Carsten:
> > I understand that there is MARC data combined with cataloging rules. We
> > don't use this approach within our MARC. So I'm not really aware of the
> problematics.
> "Your" MARC however will be very much interested in "/" (or "=") as the
> first
> character of some subfield in 245 if I recall correctly. Not such a big
> difference I would think. But maybe a slight complication of the matter,
> since MARCspec should have to cope with both approaches...
> Thomas Berger
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> XIpKt98CPUgy+hcFXc4hpTi+UH8j7NIWtaCyXYOfdL4xryzI0kEk98brZ/4TJG+9
> IxzPZ8WDQL8bjX1hRTF8P4qjn/u+nyvDFFvdbM4kH7QhYhPeeWfoVqtCnMFHLzFJ
> 7v+o6x2CKH2MnfOcgGI=
> =yBFy

Reply via email to