[openbiblio-dev] BibJSON and multiple languages

Thu Mar 8 08:02:07 UTC 2012

Two quick thoughts.

I take Tom's point about separating front and back end, but one of the attractions of JSON is "round tripping" between JSON stores like CouchDB and web pages, avoiding intermediate layers of mapping between web pages and databases. In such cases keeping things simple is attractive.

Specifying the default language is not always straightforward, and in my case it will often not be English (taxonomic literature spans some 250 years and many languages). I guess I could do something like Google's translate API to infer the "default" language.

As ever, there seems to be a balancing act between keeping things simple (at the risk of storing up future problems) and making things general (at the risk of drowning users in complexity they rarely need).

Regards

Rod

On 8 Mar 2012, at 00:10, Mark MacGillivray wrote:

> (apologies Roderic, the thread has moved away from your original point).
> 
> On Wed, Mar 7, 2012 at 10:17 PM, Tom Morris <tfmorris at gmail.com> wrote:
>>> The disadvantage of that is it would interfere with the display of
>>> objects on the UI - right now we have a lot of power from the UI side
>>> by being able to write queries to the backend with full lucene
>>> functionality if so desired - but this requires knowledge of the shape
>>> of things on the backend; not a big problem when we keep things nicely
>>> document oriented, and tell people what those documents look like.
>>> BUT, if we change what the documents look like in the backend, it will
>>> not be so easy to explain how to write queries to it.
>> 
>> That's a problem with tightly coupling the front end and back end.  It
>> makes it harder to change either one without having to change both.  I
>> think it'd be better to formally decouple them up front (even if the
>> current mapping is the identity mapping) to make it easier to
>> accommodate future growth and change.
> 
> Yes, indeed, although it is not exactly the problem that I meant. Even
> if we decouple the front and back, which is already entirely possible,
> I was meaning that if the backend is storing everything as an object
> but in bibjson we say things can be strings or objects, then you
> cannot simply look at a bibjson file and obviously see that you could
> query on a particular key. For example "title" - if I see some bibjson
> with "title": "string" then I think perhaps I can filter by "title" -
> but that would not be possible if the title was a different object on
> the backend.
> 
> Referring back to Jims points, if any item in bibjson can be a string
> or a list or an object and still be bibjson, then actually all we have
> is JSON. In terms of what the backend uses, or what the front end
> expects, I actually do not need any more than JSON, so this does not
> matter from that point of view - whether or not the back and frontend
> of our particular piece of software is loosely or tightly coupled, it
> can be solved any way we desire by passing JSON around. The value of
> bibjson comes when someone shares a dataset with another person - the
> other person can see from the bibjson conventions where they can
> expect to find certain sorts of value, and how they might process
> them.
> 
> Jims benefits of duck typing are not entirely clear to me - for
> example, if I ingest some bibjson in python, and I cannot refer to
> bibjson convention to know whether or not to treat a field as a list
> or a string, then I could validly turn name strings into lists of
> letters; but I doubt this is what the end user would expect.
> 
> In the end, I am not against just using JSON supplemented with JSON-LD
> rules where people need that functionality. Where bibjson becomes
> useful is where we list up some sensible keys, and describe the shape
> of the things they point at. So going back to the original point
> Roderic brought up - which key would be suitable for placing language
> information in, and what sort of thing would we expect to find next to
> that key? If we find consensus on that, we can add it to the
> convention.
> 
> 
> Mark
> 
> 
>> 
>> Tom
>> 
>> _______________________________________________
>> openbiblio-dev mailing list
>> openbiblio-dev at lists.okfn.org
>> http://lists.okfn.org/mailman/listinfo/openbiblio-dev
> 

---------------------------------------------------------
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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/openbiblio-dev/attachments/20120308/9c9afd19/attachment.html>