Hi Thomas and Patrick!

Thank you both for bringing the discussion forward. I must admit that I'm 
having some problems following here. I read your mails multiple times, really 
trying to understand your demands. After reading this [1], I hope I'm getting 

I just want to sum up what I think I've understood so far. Please correct me if 
I'm wrong..

--  When it comes to cataloging based delimiters (punctuation), there is some 
inner semantic to the content of the subfields. E.g. "=$b" in field 245 means 
something different than ":$b".

-- There may be data you want to get at whole, which spread over multiple 
subfields. This information is cannot be described by the range of subfields, 
but with the closure through punctuation. E.g. in the field

245     00$aHeritage Books archives.$pUnderwood biographical 
dictionary.$nVolumes 1 & 2 revised$h[electronic resource] /$cLaverne 

the data you want to get is

Heritage Books archives. Underwood biographical dictionary. Volumes 1 & 2 
revised [electronic resource]

Is this what you mean when want to say something like "Get me all from field 
XXX until you hit Y"? I guess so.

-- Therefore the order of subfields is crucial. While MARCspec allows subfields 
stated in any order, a result should preserve the subfield order emerging in 
the field.

-- Some fields are linked through specific subfields. There may be some data 
you want to get dependent on linkage from other fields. I'm not sure if I have 
an example for this. Maybe you could provide one.

Finally I've found a nice example on the MARC21 website [2] (section $i - 
Relationship information). That my question is, if you want to achieve 
something like this:

100  1# $aVerdi, Giuseppe, $d1813-1901.
245  10 $aOtello :$bin full score /$cGiuseppe Verdi.
700  1# $iLibretto based on (work) $aShakespeare, William, $d1564-1616. 
787  08 $ireproduction of (manifestation) $aVerdi, Giuseppe, 1813-1901. 
$tOtello.$d Milano: Ricordi, c1913

Result (user display):
Verdi, Giuseppe, 1813-1901. Otello : in full score / Giuseppe Verdi
Reproduction of Verdi, Giuseppe, 1813-1901. Otello. Milano : Ricordi, c1913
Libretto based on Shakespeare, William, 1564-1616. Othello.

Is this something you want to express within a MARCspec?

Anyhow a collection of use cases is a great idea. That would help to discover 
the tasks a MARCspec should cope. But I really need your help here. Maybe a 
wider audience would also be helpful?


[1] <http://marc-must-die.info/index.php?title=MARC_issues>
[2] <http://www.loc.gov/marc/bibliographic/bd76x78x.html>
Carsten Klee
Abt. Überregionale Bibliographische Dienste IIE
Staatsbibliothek zu Berlin - Preußischer Kulturbesitz

Fon:  +49 30 266-43 44 02

> -----Ursprüngliche Nachricht-----
> Von: Thomas Berger [mailto:t...@gymel.com]
> Gesendet: Mittwoch, 19. Februar 2014 23:06
> An: Klee, Carsten; 'Patrick Hochstenbach'
> Cc: v...@gbv.de; librecat-...@mail.librecat.org; perl4lib@perl.org
> Betreff: Re: [librecat-dev] A common MARC record path language
> Hash: SHA1
> Hi Carsten,
> > I think the whole problem lies in the limited expressivity of strings.
> > MARCspec is pretty much close to XPath at its approach, but without
> regular
> > expressions and functions like first(), last() etc. But even with XPath
> it would
> > be pretty hard to get the character before a subfield in a MARCXML file.
> >
> > The only solution I can think of, is using regular expressions. And I'm
> not
> > convinced that bringing this into MARCspec is a good idea. As I already
> > mentioned in the spec, MARCspec is not independent from the application
> using
> > MARCspec. Taking regular expressions into MARCspec wouldn't make the
> application
> > more usable, but would blow up the specification.
> Agreed, therefore regular expressions or other /general/ mechanisms
> should not the way to go (for specifying MARCspecs - specific
> implementations
> may realize it using a regexp implementation at hand)
> Thus, yes, limited expressivness of strings demands to make the most
> typical and most important "operations" on MARC records to be
> expressible. But if it's too limited (say it could only extract fields
> or has blind spots - parts of record data which cannot be accessed at all)
> it wouldn't be of any use.
> Thus MARCspec's need a convincing approach to the peculiarities of MARC
> records:
> Subfields are not always data elements in a proper sense, sometimes
> they are just marks interspersed into the field content.
> And as Patrick pointed out there is the presence of non-MARC delimiters
> (markup) which is crucial for processing of some (sub)fields.
> Many fields contain "ensembles" of subfields with one nature, accompanied
> by other, more data-like subfields of a different nature:
> - - Most subfields in 700 are a simple copy of some (hypothetical)
> authority
>   record's 100, however $e and/or $4 denote the function of that person
> with
>   respect to the work described by the record at hand - and repeatable
> $0's
>   just are complimentary to the "core" subfields which well may be
> $a,$b,$c,$d,
>   $f,$g,$j,$k,$l,$n,$p,$q,$t and $u (some of them repeatable and don't
> even
>   dare to change anything in their order). Use cases might include
> /selection/
>   based on one or more of the more data-like subfields and /reduction/ of
> the
>   field to a form suitable for further proessing (indexing without $e,
> display
>   including $e, or with deviant formatting of $e with reverence to today's
>   slighly silly discussion on AUTOCAT concerning photographers acting as
> authors
>   and authors acting as photographers to the perplexion of patrons ...).
> - - Same issue with most fields 77X: most subfields pertain to the work,
>   some are the individual "coordinates" within this work for that part
>   described by the given record
> - - The 245 example (and also the $e in 100's) may demonstrate a need to
>   /partition/ a field at certain spots - maybe before or after subfields
>   meeting some content condition.
> - - Ubiquitous (in the specification, maybe not in the "field") are $6 and
>   $8's. If MARCspec's could make thusly interwoven fields accessible
>   as ensembles - that would be an enormous benefit!
> - From my limited experience the "unclear" nature of subfields really is
> the
> hard part in MARC processing: If you delve into subfield processing too
> early you get data fragments almost or completely impossible to reassemble
> into something meaningful. On the other hand looking at fields as a whole
> gives you more chances to understand what it is about but you're going
> to choke on the weeding out necessary to proceed.
> Thus maybe due to my limited experience in MARC processing I'd very much
> appreciate MARCspec as a grammar to formulate those tasks that really
> matter (and are hard to be done 100% right). To achieve that - cf.
> Patrick's reply again - one or several "processing paradigms" for MARC
> records should serve as a base and - for clarities' sake - should be made
> explicit in the MARCspec specification.
> Thomas
> Version: GnuPG v1
> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
> QHT/8QypD6yKqHM8c7KzcHB8efttB7CQ8mB7cAtqxqQw2oqPzicnkYXIJU9Z9Yxm
> yIaJXPWKovgypLNn4sAjPf2/MsJMYTtCrLOGwWxgp+Uq8bvAuZx5iMr1rKP68PzH
> DCGkPq31KhMT1tUBHMk=
> =EP69

Reply via email to