[openbiblio-dev] BibJSON and multiple languages

Mark MacGillivray mark at odaesa.com
Wed Mar 7 16:32:47 UTC 2012

On Wed, Mar 7, 2012 at 4:01 PM, Roderic Page <r.page at bio.gla.ac.uk> wrote:
> My only concern about making usual data elements into objects is that it
> adds a level of complexity that many (most?) users won't encounter. Wouldn't
> make sense to keep things as simple as possible? This is one thing that has
> driven me nuts in the past when dealing with some RDF data (e.g., having to
> specify a language code when all I want is a text field).
> I like the idea of a lang_alternate key. On the one hand it may be less
> general than making all relevant fields objects, but it avoids asking
> developers using JSON to deal with complexity that they might not want or
> have.

Yes, if we were to follow Jims suggestion here and make everything an
object, we would add a great deal of undue complexity to all other
users; and the core purpose of bibjson is to maintain simplicity.


> Regards
> Rod
> On 7 Mar 2012, at 15:44, Jim Pitman wrote:
> Mark MacGillivray <mark at odaesa.com> wrote:
> Hi Roderic, thanks for contacting us, this is really interesting
> Yes. This is an important issue not yet addressed in BibJSON.
> I often come across articles in multiple
> languages (e.g., the article, abstract, and body of the text is in
> Portuguese, but an English title and abstract are also provided).
> Yes. Important use case we should accommodate.
> The most common use case is a translated title, then a translated abstract.
> I can provide plenty of data like this in mathematics.
> I think the right solution is to allow any of the usual data elements e.g.
> title,  abstract, ...
> to become an object, and to enhance those objects in a way that indicates
> what is the original title,
> what is its language, what are alternate titles, what languages, who
> translated them, ....
> Hopefully there is some available standard we could adopt for this purpose.
> Main point is, whatever we do, we should be doing the same thing in each
> field: title,  abstract, journal, ...
> and that should include author objects as well, especially e.g. for
> transformation of chinese and cyrillic characters.
> OR perhaps a better, more extensible approach, but more complex, would
> be to use the JSON-LD method of specifying languages:
> http://json-ld.org/spec/latest/json-ld-syntax/#default-language
> Great if JSON-LD can take care of this.
> We are currently leaning towards adopting JSON-LD methods for doing
> namespaces, so any JSON-LD methods for languages could also be acceptable.
> Sounds right.
> --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
> ---------------------------------------------------------
> Roderic Page
> Professor of Taxonomy
> Institute of Biodiversity, Animal Health and Comparative Medicine
> College of Medical, Veterinary and Life Sciences
> Graham Kerr Building
> University of Glasgow
> Glasgow G12 8QQ, UK
> Email: r.page at bio.gla.ac.uk
> Tel: +44 141 330 4778
> Fax: +44 141 330 2792
> AIM: rodpage1962 at aim.com
> Facebook: http://www.facebook.com/profile.php?id=1112517192
> Twitter: http://twitter.com/rdmpage
> Blog: http://iphylo.blogspot.com
> Home page: http://taxonomy.zoology.gla.ac.uk/rod/rod.html

More information about the openbiblio-dev mailing list