RE: [librecat-dev] A common MARC record path language

Hi Carsten

Thanks for the new spec I think it is a great initiative to align many proj=
ects 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 MARCspec=
s as string" and "2.1" which are design concerns which require a separate d=
iscussion from the formal part of the document. I mean, I can agree or disa=
gree 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 docume=
nt of use-cases. Producing Linked Data is only of the cases. Solrmarc is ab=
out  transforming MARC into something that can be send to SOLR. In ILS syst=
ems you might use it to point to parts of MARC you want to display in a web=
interface. In catmandu you might want to produce reports. Every use-case ca=
n have its own needs to make parts of MARC easy addressable.

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

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

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

But..this treats MARC as a document key-value exchange format for bibliogra=
phical 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 process=
ing 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 implemen=
t some of that logic.

For instance. as stupid example:

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

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 o=
f functions like move_field, split_field, copy_field etc etc. But I hope th=
ere are other options also.

Cheers
Patrick

________________________________________
From: Klee, Carsten [[email protected]]
Sent: Wednesday, February 19, 2014 2:27 PM
To: '[email protected]'; Patrick Hochstenbach
Cc: [email protected]; [email protected]; [email protected]
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. MARC=
spec is pretty much close to XPath at its approach, but without regular exp=
ressions and functions like first(), last() etc. But even with XPath it wou=
ld 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 me=
ntioned in the spec, MARCspec is not independent from the application using=
 MARCspec. Taking regular expressions into MARCspec wouldn't make the appli=
cation 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 ' /$=
' appears):

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

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

marcspec =3D "245.match(/(.*)\s\/\$/)"
titleData =3D 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 =3D "245"
titleData =3D 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

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

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

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

    return result
}

In Catmandu or elsewhere the user calls the function

takeEverythingFromSpecUntilYouHitBeforeSubfield("245","/",record)

--> this should result in the desired "Concerto per piano n. 21, K 467 [sou=
nd recording]".

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.

Cheers!

Carsten
_______________________________________________
Carsten Klee
Abt. =DCberregionale Bibliographische Dienste IIE
Staatsbibliothek zu Berlin - Preu=DFischer Kulturbesitz

Fon:  +49 30 266-43 44 02

> -----Urspr=FCngliche Nachricht-----
> Von: Thomas Berger [mailto:[email protected]]
> Gesendet: Mittwoch, 19. Februar 2014 01:04
> An: Klee, Carsten; 'Patrick Hochstenbach'
> Cc: [email protected]; [email protected]; [email protected]
> Betreff: Re: [librecat-dev] A common MARC record path language
>
> -----BEGIN PGP SIGNED MESSAGE-----
> 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 "=3D") 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
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
>
> iJwEAQECAAYFAlMD9NYACgkQYhMlmJ6W47PzEQP/RIfm5bsHLTwhJMLJjNjF3vO/
> XIpKt98CPUgy+hcFXc4hpTi+UH8j7NIWtaCyXYOfdL4xryzI0kEk98brZ/4TJG+9
> IxzPZ8WDQL8bjX1hRTF8P4qjn/u+nyvDFFvdbM4kH7QhYhPeeWfoVqtCnMFHLzFJ
> 7v+o6x2CKH2MnfOcgGI=3D
> =3DyBFy
> -----END PGP SIGNATURE-----=