[openbiblio-dev] BibJSON spec

[Mark MacGillivray]

Hi Patrick, thanks for trying out bibjson,

On Thu, Feb 23, 2012 at 1:20 AM, Jim Pitman <pitman at stat.berkeley.edu> wrote:
>> These keys are arrays of objects according to the BibJSON standard, but
>> can other keys be as well? If the "author" and "editor" fields contain
>> lists of objects representing people, can the same be done for
>> "recipient" or "translator" or "illustrator", etc.?

If you create records that include these keys as objects, and they
have not previously been used as keys for strings, they will be
accepted and defined as objects by the bibserver instance you create
them on.


> I think they should be. Others I have encountered are "originator", "creator".I am not clear however on
> the process by which it is decided which keys have this feature and  which do not, nor on where the
> definitive list of such keys (if there is one) can be expected to be found.

The list is on bibjson.org, and shows the ones we have so far decided
to make into objects. To decide which ones we should add, just suggest
them on the openbiblio-dev list (as is being done now), and we can add
them to bibjson.org.


> Another issue is how consistent we should aim to be on what keys are required/expected once inside an
> object of this kind. I think it is reasonable to insist on some required fields, and to encourage use
> of some optional ones, in the style of bibtex, and make this part of the BibJSON spec to try to reduce
> potential proliferation of field names.
>
> Mark, could you please comment?

Specifying required keys would not stop proliferation. We would have
to forbid the use of any unknown keys to achieve that, which would
make it harder to use.

This is a great example: Patrick has discovered some potential new
objects here, and he can upload them and see how it goes. By finding
it is useful, and showing it to others, we can discover the most
useful structure to use based on experience - instead of guessing and
restricting in advance. (Of course we know at the moment that the
parsers do not provide adequate feedback, but that is on the way.)

Our aim is to engage people to share their data whatever the state, so
it is sensible to be as flexible as possible and to allow requirements
/ improvements to emerge in the community.

Mark


>
> Its really great Patrick that you are following up on this. Many thanks for your interest!
>
> --Jim
>
> ----------------------------------------------
> Jim Pitman
> Professor of Statistics and Mathematics
> University of California
> 367 Evans Hall # 3860
> Berkeley, CA 94720-3860
>
> ph: 510-642-9970  fax: 510-642-7892
> e-mail: pitman at stat.berkeley.edu
> URL: http://www.stat.berkeley.edu/users/pitman
>
> _______________________________________________
> openbiblio-dev mailing list
> openbiblio-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openbiblio-dev