[openbiblio-dev] BibJSON and multiple languages

[Mark MacGillivray]

On Wed, Mar 7, 2012 at 4:39 PM, Etienne Posthumus
<etienne.posthumus at okfn.org> wrote:
> An alternative would be to allow either simple strings OR objects.
> (similar to what JSON-LD does in
> http://json-ld.org/spec/latest/json-ld-syntax/#string-internationalization
> as mentioned by Mark previously)
>
> This would push the complexity to the software in the parsing and
> displaying, but allow the end-user to still use as simple as possible
> bibjson.

Hmm... our backend (elasticsearch) is very flexible, but the one thing
that cannot happen is that something previously defined as an object
cannot then be supplied a string. We would have to make it so that
everything in the backend was an object, but that we could accept
strings in and turn them into objects, as well as converting simple
objects into strings on the way out.

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.

The only fudging we do when putting data in the backend at the moment
is we add some internal keys (which can simply be ignored) and every
field gets mapped to its name as well as something of the form
"name.exact" - this allows querying on the analysed strings under the
"name" field, and querying of the unanalysed strings under the
"name.exact" field (and you need unanalysed querying if you want
facets).

Mark



>
> _______________________________________________
> openbiblio-dev mailing list
> openbiblio-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/openbiblio-dev