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.
In pu branch this meas that if we have a nice configuration file for our data model and to translate JSON, half of the issues that you are having should be resolved. On 28 Mar 2014, at 11:30, Ferran Jorba <[email protected]> wrote: > Hello Esteban, > > [...] >>> So, the easiest solution accept any indicator in any tag. I may be >>> some exception somewhere in some tag, but accepting any indicator is >>> *much* better than only accepting __. >> >> We are ready to use fields in the form 100**, although I rather prefer >> listing all the valid possibilities that each installation might have, > > 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. An let me remark that the Marc21 produced from the JSON will also contain the 100 follow by the correct indicators. > >> for example the Invenio demo site has only 100__, but we can think >> about having 1001_ and 1002_. I can provide an example of how this >> should be done inside BibField/JSONAlchemy if you want. > > 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 :) > >> The problem is that so far we don’t have any demo record to test this >> situation, perhaps we should create a ticket to avoid forgetting about >> this topic. As you mentioned this possible issue, I guess because you > > You are right about that. My fault. Another thing in my too-long > to-do-list... > >> were/are/will be dealing with it, it would be really nice if you could > > I've patched my Invenios here and there, mostly changing thing like > bfo.field('245__a') for bfo.field('245%%a') and the like. The same for > logical fields, output formats, input templates, etc. It is not > difficult, but I don't know how to send those patches upstream, due to > the initial demo-database dump and the test cases. This situation is almost cover in pu. > > So, Invenio is perfectly able to cover 95% (or more) of the cases, just > taking any indicator as valid in any field. Those movement you are > doing towards JSON makes some us quite scary if it takes the semantics > out of Marc21. I don’t really understand what you mean by taking the semantic out. 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. Cheers, -- Esteban J. G. Gabancho
