[openbiblio-dev] BibJSON and multiple languages

[Mark MacGillivray]

(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