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

Hi Patrick,

I'm sorry for my much more late reply. Since your mail MARCspec [1]  develo=
ped a lot. But unfortunately I didn't got a solution for the issue you desc=
ribed. Honestly, I'm not sure, if I understand the problem which you want t=
o solve here.

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 proble=
matics.

You mentioned the typical case =93Take everything from the 245 until you hi=
t the first / before a subfield=94. I thought about this, but didn't came e=
ven close how this could be expressed in MARCspec. How is this solved in Ca=
tmandu now?

If you have any suggestions, how this could be expressed in a string, pleas=
e give me a hint.

The only thing I can imagine, is a reference to a character within a subfie=
ld. Something like

245$a[0]/-1

could be read as "A reference to the last character of the first subfield '=
a' of field 245". Then you could check if the reference character is "/". B=
ut I think, that didn't solve your problem, right?

However I would be very glad, if MARCspec gets adopted by Catmandu. If you'=
re interested, I've written some algorithm rules for MARCspec parsers [2]. =
They are very comprehensive. Maybe there is a smarter algorithm, but this m=
ight give you some clue.

Cheers!=20

Carsten

[1] <http://cklee.github.io/marc-spec/marc-spec.html>
[2] <https://github.com/cKlee/marc-spec/blob/master/marc-spec-parser-rules.=
md>
_______________________________________________
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: Dienstag, 21. Januar 2014 09:57
> An: Klee, Carsten; [email protected]; [email protected];
> [email protected]
> Betreff: Re: AW: [librecat-dev] A common MARC record path language
>=20
> Hi Carsten
>=20
> Excuses for the late reply, it took some while to get the system booted
> after winter vacations.
>=20
> 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).
>=20
> In daily work I often encounter mapping rules which involve these special
> subfield cases (=93Take everything from the 245 until you hit the first /
> before a subfield=94). These things can=92t 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 .
>=20
>=20
> Cheers
> Patrick
>=20
> On 06/01/14 16:33, "Klee, Carsten" <[email protected]> wrote=
:
>=20
> >
> >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[=8C\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 =3D> '=8C '); ??
> >
> >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. =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
> >>
> >> 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=B9s MARC spec rules and I will gladly impleme=
nt
> >>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 characte=
r
> >> (e.g. In titles I would like to point to everything after the =8C/=8C =
in a
> >>245
> >> field).
> >>
> >> Cheers and have a nice holiday
> >>
> >> Patrick
> >>
> >>
> >> On 19/12/13 13:16, "Jakob Vo=DF" <[email protected]> wrote:
> >>
> >> >Hi,
> >> >
> >> >Carsten Klee specified a simple path language for MARC records, calle=
d
> >> >"MARC spec". In short it is a formal syntax to refer to selected part=
s
> >> >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
> >