A common MARC record path language

[Jakob Voß]

Hi,

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):

http://collidoscope.de/lld/marcspec-as-string.html
http://cklee.github.io/marc-spec/marc-spec.html#examples

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:

https://metacpan.org/pod/Catmandu::Fix::Inline::marc_map
https://metacpan.org/source/NICS/Catmandu-MARC-0.103/lib/Catmandu/Fix/Inline/marc_map.pm#L26

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.

Cheers,
Jakob

--
Jakob Voￜ <jakob...@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/

[Patrick Hochstenbach]

Hi

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 fix
for us to follow Carsten¹s MARC spec rules and I will gladly implement it
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 have
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 that
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 245
field).

Cheers and have a nice holiday

Patrick

On 19/12/13 13:16, "Jakob Voß" <vo...@gbv.de> wrote:

>Hi,
>
>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):
>
>http://collidoscope.de/lld/marcspec-as-string.html
>http://cklee.github.io/marc-spec/marc-spec.html#examples
>
>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:
>
>https://metacpan.org/pod/Catmandu::Fix::Inline::marc_map
>https://metacpan.org/source/NICS/Catmandu-MARC-0.103/lib/Catmandu/Fix/Inli
>ne/marc_map.pm#L26
>
>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.
>
>Cheers,
>Jakob
>
>--

>Jakob Voß <jakob...@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
>librec...@mail.librecat.org
>http://mail.librecat.org/mailman/listinfo/librecat-dev

[Klee, Carsten]

Hi Patrick! Hi everyone!

Thanks for looking into MARCspec. I opened some GitHub issues [1] concerning your enhancement requests. Let me just give you some thoughts on these:

> - Supporting local defined MARC (sub)fields (e.g. Ex Libris exports
> contain all kind of Z30, CAT , etc fields)

I think this should be supported. The only problem in the current spec is that the character "X" is used as a wildcard in the field tag. If someone defined a local field tag like "XYZ" this gets interpreted as "all fields ending with YZ". Possible solution is to define another wildcard character like "*".

> - Notion of pointing to the first item (first author)

and

> - 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 245
> field).

I understand that both are desired very often. But I think that this is maybe a little bit out of scope. Since XSLT provides this feature and many more like "the last element", "the X element", "substring-after", "substring-before" etc., MARCspec should concentrate on the core MARC data model (fields, subfields, character positions) and let the rest to the post data processing of the applications.

If MARCspec would provide these functionalities it quickly will become very complicated. And maybe it will come into conflicts with already defined data processing functions in the various applications.

On the other hand I could imagine something like "100[0]" for the first 100 field (author) and "100[1]" 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 [2]).

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 https://metacpan.org/pod/Catmandu::Fix::marc_map

# Copy all 100 subfields except the digits to the 'author' field
marc_map('100^0123456789','author');

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 [2]).

So far... I would be happy to read more comments on this.

Cheers!

Carsten


[1] <https://github.com/cKlee/marc-spec/issues>
[2] <http://www.loc.gov/marc/specifications/specrecstruc.html#varifields>
_______________________________________________
Carsten Klee
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.Ho...@UGent.be]
> Gesendet: Freitag, 20. Dezember 2013 14:06
> An: vo...@gbv.de; librec...@mail.librecat.org; perl...@perl.org
> Cc: Klee, Carsten
> Betreff: Re: [librecat-dev] A common MARC record path language

>
> Hi
>
> 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 fix

> for us to follow Carstenąs MARC spec rules and I will gladly implement it

> 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 have
> 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 that
> 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 245