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

Hi Patrick! Hi everyone!

Thanks for looking into MARCspec. I opened some GitHub issues [1] concernin=
g 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 t=
hat the character "X" is used as a wildcard in the field tag. If someone de=
fined a local field tag like "XYZ" this gets interpreted as "all fields end=
ing with YZ". Possible solution is to define another wildcard character lik=
e "*".

>  - 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 =8C/=8C in =
a 245
> field).

I understand that both are desired very often. But I think that this is may=
be a little bit out of scope. Since XSLT provides this feature and many mor=
e like "the last element", "the X element", "substring-after", "substring-b=
efore" etc., MARCspec should concentrate on the core MARC data model (field=
s, subfields, character positions) and let the rest to the post data proces=
sing 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 da=
ta 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 re=
peatable subfields? Maybe someone requires the first subfield "a" of the se=
cond 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[=8C\s(.*)]_10. But for usability rea=
sons this might be better left to the applications. Isn't there something i=
n Catmandu like=20
marc_map('245','my.title', -substring-after =3D> '=8C '); ??

Maybe you have another solution for that?

Another issue I suspect with your last example under https://metacpan.org/p=
od/Catmandu::Fix::marc_map=20

# 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 subfie=
lds ^, 0, 1, 2, 3, 4, 5, 6, 7, 8 and 9 of field 100". This is because "^" i=
s a valid subfield code (see [2]).

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

Cheers!

Carsten
=20

[1] <https://github.com/cKlee/marc-spec/issues>
[2] <http://www.loc.gov/marc/specifications/specrecstruc.html#varifields>
_______________________________________________
Carsten Klee
Abt. =DCberregionale Bibliographische Dienste IIE
Staatsbibliothek zu Berlin =96 Preu=DFischer Kulturbesitz

Fon:  +49 30 266-43 44 02

> -----Urspr=FCngliche Nachricht-----
> Von: Patrick Hochstenbach [mailto:[email protected]]
> Gesendet: Freitag, 20. Dezember 2013 14:06
> An: [email protected]; [email protected]; [email protected]
> Cc: Klee, Carsten
> Betreff: Re: [librecat-dev] A common MARC record path language
>=20
> Hi
>=20
> 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=B9s MARC spec rules and I will gladly implement =
it
> for our community.
>=20
> 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.
>=20
> 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.
>=20
> Our paths are very much simplified but still seem to lack some things tha=
t
> are available in the MARC data model which would be great to have
> available in the MARCspec syntax:
>=20
>  - 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 =8C/=8C in =
a 245
> field).
>=20
> Cheers and have a nice holiday
>=20
> Patrick
>=20
>=20
> On 19/12/13 13:16, "Jakob Vo=DF" <[email protected]> wrote:
>=20
> >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=DF <[email protected]>
> >Verbundzentrale des GBV (VZG) / Common Library Network
> >Platz der Goettinger Sieben 1, 37073 G=F6ttingen, Germany
> >+49 (0)551 39-10242, http://www.gbv.de/
> >
> >_______________________________________________
> >librecat-dev mailing list
> >[email protected]
> >http://mail.librecat.org/mailman/listinfo/librecat-dev