On 28.03.2014 13:49, Ferran Jorba wrote:
Hi!
Let me clarify something before my answer, just to avoid
misunderstandings, I’m talking always from the point of view of making
BibField/JSONAlchemy as compatible as possible.
Compatible with... Standard Marc21, maybe ;-)?
Surely, I think Esteban is heading for this large goal. :)
[...]
Personally, I think that isting all valid possibilities for all tags
for all installation is worthless. There are just too many of them.
Just consider all valid. It is much easier and good enough.
If all of the possibilities have the same meaning I agree with you
that they should be listed together using regex like 100**.
On the other hand, if they have different semantic meaning, I think
they should be listed separately, even if they will produce the same
JSON field in the end.
I know Marc21 reasonably well, and I don't remember now any case where
having different indicators mean something so different that has to be
treat differently.
Here I would be more careful. Basically, I would treat Marc fields and
indicators not as 3 digits plus two other funny chars but consider the
whole bunch as a 5 character wide filed designation. I think, here I'm
in fact a bit more in line with Estebans approach. At least if I
understand it correctly. (Though I agree with you that one might not
come up with a complete bibfield list, but just with a set of "most
common usages".)
For 1001_ and 1002_ (I think the latter was referring to 3_):
We use 1001_ as we store names in the form "Lastname, Firstname" and 3_
would be "Firstname Lastname" while __ doesn't say a thing about it.
That's why I feel, that 1_ indeed contains some semantic content. (I
agree, that the latter doesn't make much sense as a storage format but
it seems quite common for US address books till today. At least my phone
sorts addresses by Firstname. Ridiculous. I also agree it would have
been wise to have two fields in the first place.)
Beyond that we have some usage of indicators that contain clear
semantics. We have a friend here in 913 e.g. (ok, this is in the free
range of Marc). 9131_ are grants from the "then valid funding period"
while 9132_ are grants from "the then upcoming funding period". (Don't
ask, this is the bean counting we have to do in the end.) We could have
invented a completely new field, right. But in a way it makes sense to
have both in 913 signifying "they are essentially the same".
In some cases, it means: with a 0 here, don't
display, or, don't index, or this author is a family name. It would be
perfect if Invenio could honor them, but now I'd be happy just to
improve the current situation.
Agreed, for indexing, especially for all those default indices, I can't
imagine an exception as well, while I see sort of a problem with the
title index e.g. 245__a while all library systems use at least indicator
2 for the "Nonfiling characters". So
The important book
24504 a The important book
sorts under I not under T. Ingesting foreign data to default instance
currently will, however, render this title not indexed in the title field.
For the 913 above, however, it could be preferable that we have an index
pof living on 9131_ only, while npof lives on 9132_ only.
An let me remark that the Marc21 produced from the JSON will also
contain the 100 follow by the correct indicators.
:)
I don't care much about the implementation as I do that Marc21 should
be *the* final word. We discussed it at length at Jülich.
This is war that I don’t want to fight, at least not in this thread :)
It is not war, no; it is to clarify things. I'm a fervent pacifist too
;-)
Believe it or not: I'm as well. ;) Even served wearing White (not Green. ;)
[...]
The JSON structure that we create from Marc21 (or anything else)
contains as much information from the master format as you want (even
the indicators). Meaning that if your data model is well written it
is a lossless conversion and there is a one to one mapping that makes
possible doing Marc21 to JSON to Marc21.
I hope that.
+1
I share some concerns about this with Ferran and Martin and some others,
and I'm very sure it's quite a task...
--
Kind regards,
Alexander Wagner
Scientific Services / Scientific Publishing
Central Library
52425 Juelich
mail : a.wag...@fz-juelich.de
phone: +49 2461 61-1586
Fax : +49 2461 61-6103
http://www.fz-juelich.de/zb/wp
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
