Hi Patrick, I'm sorry for my much more late reply. Since your mail MARCspec [1] developed a lot. But unfortunately I didn't got a solution for the issue you described. Honestly, I'm not sure, if I understand the problem which you want to 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 problematics. You mentioned the typical case “Take everything from the 245 until you hit the first / before a subfield”. I thought about this, but didn't came even close how this could be expressed in MARCspec. How is this solved in Catmandu now? If you have any suggestions, how this could be expressed in a string, please give me a hint. The only thing I can imagine, is a reference to a character within a subfield. 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 "/". But 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 might give you some clue. Cheers! 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. Ü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: Dienstag, 21. Januar 2014 09:57 > An: Klee, Carsten; v...@gbv.de; librecat-...@mail.librecat.org; > perl4lib@perl.org > Betreff: Re: AW: [librecat-dev] A common MARC record path language > > Hi Carsten > > 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 . > > > Cheers > Patrick > > 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[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.hochstenb...@ugent.be] > >> Gesendet: Freitag, 20. Dezember 2013 14:06 > >> An: v...@gbv.de; librecat-...@mail.librecat.org; perl4lib@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 > >> field). > >> > >> Cheers and have a nice holiday > >> > >> Patrick > >> > >> > >> On 19/12/13 13:16, "Jakob Voß" <v...@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.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 > >> >librecat-...@mail.librecat.org > >> >http://mail.librecat.org/mailman/listinfo/librecat-dev > >
