Hi Ferran!

On 28 Mar 2014, at 10:39, Ferran Jorba <[email protected]> wrote:

> Hello Esteban,
> 
> [...]
>> Don’t worry Ferran, I was using the authors 100 vs 700 as an example,
>> but it is the same case for other fields where you want to do
>> aggregations like this one.  About the indicators, don’t worry either
>> we take good care of them, if needed, you can make the distinction
>> between 1001_ and 100__ (I don’t know if this is even correct, it is
>> just an example).
> 
> the problem is more general in Invenio.  You can take Marc21 and use a
> subset of it.  Or just use a subset of the tags.  Or interpret more
> strictly, more loosely, use more local tags or subfields.  Marc21 is
> like a legal code (or a programming language, if you feel more
> confortable with), where there is flexibility.

It is true that we are using a subset of Marc21(sometimes maybe not in a 
stander way) and we know that there is more beyond Invenio Marc21 world.

> 
> CERN may use a subset of Marc21 where most of the indicators are __.
> Ok, that's CERNs library decission.  But if the Invenio developers claim
> that Invenio supports Marc21, you *must* allow other indicators there,
> and consider it valid.  For example, take a quick look to the authors
> tag documentation:
> 
> http://www.loc.gov/marc/bibliographic/bd100.html
> http://www.loc.gov/marc/bibliographic/bd700.html
> http://www.loc.gov/marc/bibliographic/bd110.html
> http://www.loc.gov/marc/bibliographic/bd710.html
> http://www.loc.gov/marc/bibliographic/bd111.html
> http://www.loc.gov/marc/bibliographic/bd711.html
> http://www.loc.gov/marc/bibliographic/bd720.html
> 
> 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, 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.

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 were/are/will be 
dealing with it, it would be really nice if you could provide us with some sort 
of demo record, for example we have several records inside the poetry 
collection just for testing the unicode support, we could also add some catalan 
poetry there to test that the indicators are well managed :)

Cheers,
--
Esteban J. G. Gabancho

Reply via email to