Excuses for the late reply, it took some while to get the system booted
after winter vacations.
You are right in the discussion about which parts should be specified by a
MARCspec language and which part should be implemented as operations on
nodes found. I gave the examples not as a hit for the implementation
language (e.g. if it requires regular expressions or not) but as a
examples of MARC in the wild (non standard tags) and MARC combined with
cataloging rules (where subfields and characters in front of a subfield
have a special meaning).
In daily work I often encounter mapping rules which involve these special
subfield cases (“Take everything from the 245 until you hit the first /
before a subfield”). These things can’t be easily (can it) expressed in
Xpath when using XSTL or MARCspec when using tools like Catmandu..but are
very common and can be shared across tools. I think this would be
candidates to formalise .
On 06/01/14 16:33, "Klee, Carsten" <carsten.k...@sbb.spk-berlin.de> wrote:
>On the other hand I could imagine something like "100" for the first
>100 field (author) and "100" for the second and so on. But what is
>about repeatable subfields? Maybe someone requires the first subfield "a"
>of the second 100 field. Besides the characters "[" and "]" are also
>valid subfield codes (see ).
>With substrings it is more complicated. I only could imagine using
>regular expressions. Maybe something like 245a[Œ\s(.*)]_10. But for
>usability reasons this might be better left to the applications. Isn't
>there something in Catmandu like
>marc_map('245','my.title', -substring-after => 'Œ '); ??
>Maybe you have another solution for that?
>Another issue I suspect with your last example under
># Copy all 100 subfields except the digits to the 'author' field
>In the current MARCspec this would be interpreted as "a reference to
>subfields ^, 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9 of field 100". This is
>because "^" is a valid subfield code (see ).
>So far... I would be happy to read more comments on this.
>Abt. Überregionale Bibliographische Dienste IIE
>Staatsbibliothek zu Berlin – Preußischer Kulturbesitz
>Fon: +49 30 266-43 44 02
>> -----Ursprüngliche Nachricht-----
>> Von: Patrick Hochstenbach [mailto:patrick.hochstenb...@ugent.be]
>> Gesendet: Freitag, 20. Dezember 2013 14:06
>> An: v...@gbv.de; librecat-...@mail.librecat.org; email@example.com
>> Cc: Klee, Carsten
>> Betreff: Re: [librecat-dev] A common MARC record path language
>> Thanks for this initiative to formalise the path language for MARC
>> records. In Catmandu our path language is better described at:
>> https://metacpan.org/pod/Catmandu::Fix::marc_map. It would be an easy
>> for us to follow Carsten¹s MARC spec rules and I will gladly implement
>> for our community.
>> We see these type of MARC paths in programming libraries such as the
>> projects mentioned below but also in products like XSTL, SolrMarc,
>> ILS-vendors who need them to define how to index marc, standardisation
>> bodies like e.g. that provide mapping rules (e.g.
>> http://www.loc.gov/standards/mods/mods-mapping.html). I tried to make a
>> small roundup in the past of these projects but it would be great to
>> more extensive look at all current pratices.
>> In our Catmandu project we found that Xpaths are too verbose for our
>> librarians to interpret and in practise tied to XSLT-programming which
>> requires quite some programming skills to read and interpret.
>> Our paths are very much simplified but still seem to lack some things
>> are available in the MARC data model which would be great to have
>> available in the MARCspec syntax:
>> - Notion of pointing to the first item (first author)
>> - Supporting local defined MARC (sub)fields (e.g. Ex Libris exports
>> contain all kind of Z30, CAT , etc fields)
>> - Support for pointing to a subfields that follow a specific character
>> (e.g. In titles I would like to point to everything after the Œ/Œ in a
>> Cheers and have a nice holiday
>> On 19/12/13 13:16, "Jakob Voß" <v...@gbv.de> wrote:
>> >Carsten Klee specified a simple path language for MARC records, called
>> >"MARC spec". In short it is a formal syntax to refer to selected parts
>> >of a MARC record (similar to XPath for XML):
>> >Similar languages have been invented before but not with a strict
>> >specification, as far as I know. For instance the perl Catmandu::MARC
>> >supports references to MARC fields:
>> >Could you please have a look at MARC spec and join forces to get a
>> >common syntax that can be used among different tools? So
>> >- If your tool does not support all aspects of MARC spec, please
>> >implement the missing parts.
>> >- If your tool supports more than included in MARC spec, help extending
>> >the syntax at https://github.com/cKlee/marc-spec/
>> >- If you tool uses a different syntax to refer to parts of MARC,
>> >please think about modifying it to align with MARC spec.
>> >Jakob Voß <jakob.v...@gbv.de>
>> >Verbundzentrale des GBV (VZG) / Common Library Network
>> >Platz der Goettinger Sieben 1, 37073 Göttingen, Germany
>> >+49 (0)551 39-10242, http://www.gbv.de/
>> >librecat-dev mailing list