tiborsimko
commented
8 years ago Here are some thoughts:
- In your example, the existing subfields are "ababc", which is not too bad. If there is the same number of a's and b's, then you know which "a" is paired with which "b". I guess this may be the majority of records? If so, we are good.
- The worst case scenario is a situation where subfields look like "aaba" and "abaa". Currently, Invenio would not be able to tell the difference, such as to which "a" was the "b" paired with. Can this happen in your use case? If so, then dojson parser would have to be amended in order to keep this distinction, e.g. incoming field can be parsed into a
__original__JSON tree. - Regarding search and phrase queries combining several subfields, it may be perhaps possible to configure this on the Elasticsearch part, otherwise during the JSON enhancing step one could combine "a" and "b" into a composed "a-b" field, where phrase searching would work as per your example.
- Finally, note that if this concrete installation ecosystem works mostly within MARC world, then the editing and importing/exporting actions can happen in the middle layer of the record format onion. In this case, you don't need to perform virtually any MARC <-> JSON import/export operations. The cataloguers can be served directly MARC, which will be stored as the "master" format in SIP/DIP stores, so they can edit MARC directly as it will be stored, rigorously keeping the subfield order. In this kind of situation, JSON will be used only internally by Elasticsearch. (Well, there will be an issue to generate output formats from JSON or from MARC.)
Note that this depends on every concrete installation: in some cases, the middle layer of the format onion is very slim, so the site works mostly with internal JSON format being the master format. In other cases, the middle layer of the onion is rather fat, and most of the cataloguing action happens there. You seem to be targetting the latter example.
Kennethhole
greut
jirikuncar
switowski
SamiHiltunen
As a follow up to the RFC about handling of indicators https://github.com/inveniosoftware/dojson/issues/19, I would like to raise my concerns about the order of subfields. The order of subfields are important for libraries and should be taken into consideration in the MARC-JSON mapping. A very simple example is an item that has been published by two publishers in two different locations. By following MARC21, the metadata would look like this:
and should be displayed to the user in the order the subfields are stored:
If I have understood it correclty, the contrib.marc21 does not have the concept of order and it would map subfields a together, subfields b together, etc. My concerns are:
a) We will not be able to display the subfields in the correct order, so it might end up to be displayed like this:
You can see that the punctuation changes between equal subfields as they are dependent of the next subfield (comma before subfield c) and it ilustrates how important the order can be. In the worst case it can end up looking like this:
b) Exporting it back to MARC would leave us with an XML, which looks like:
c) I am also curiouse how it will be handled by Elasticsearch. Will I be able to copy- paste the displayed text
Paris : Gauthier-Villars ; Chicago : University of Chicago Press, 1955.and do an exact/partial phrase query?Has any of these concerns been taken into consideration?