W3C home > Mailing lists > Public > public-linked-json@w3.org > September 2014

Re: architecture for querying json and json-ld

From: Alfredo Serafini <seralf@gmail.com>
Date: Mon, 1 Sep 2014 11:39:39 +0200
Message-ID: <CADawF4PhyfqYqAdgFV11V4-Xsh3cck3CVDd-uBN5S40QiuAr1g@mail.gmail.com>
To: Philippe Duchesne <pduchesne@gmail.com>
Cc: Ricardo Pietrobon <pietr007@gmail.com>, Linked JSON <public-linked-json@w3.org>
I'm currently using an approach which is very similar to the one described
by Philippe.

Using the Tinkerpop stack it's easy to work adopting the same interfaces
(Sail, basically) as sesame, and there was also a bridge to mongodb as the

The major problem with this approach is that you need to let the driver
adopt the schema designed for mantaining the triples, so you will actually
have two distinct storage, but on the same (mongo in your case) database.
This is however good if need to put all the data on the same database.
BTW for the json-aware storage on some No-SQL i feel that the best option
is to save on the repository the "plain" json structure (I'm currently
using elasticsearch, but I suppose the same should be for mongo, more or
less). The json to json-ld mapping works very good for me on light
REST-like request with jersey, providing a @context which I define by
resource, while mantaining directly the json-ld structure it's possibile
but more complex to handle, and does not resolve the access by SPARQL and
graph-oriented languages (such as gremlin or cypher, if you need to use
them), or integrations on tools like Gephi, so you still may need to have a
triplestore or another tinkerpop ready storage...
One of the experiment I am planning for the next step is to find a way to
obtain back a "plain json" from a json-ld, once provided the correct
@schema. This should simplifying the communications between the parts.

Hope this helps,

2014-09-01 9:58 GMT+02:00 Philippe Duchesne <pduchesne@gmail.com>:

> Hello Ricardo,
> FWIW, here's my approach for a similar usecase.
> I have data sitting in a triple store, and I need to bridge it with an
> existing webapp relying on a legacy JSON object model.
> I have put together a Java stack with, from bottom to up:
>  - Sesame as a triple store
>  - Jersey as a JAX-RS framework (to expose resources RESTfully)
>  - jsonld-java as a codec layer within jersey
>  - a carefully defined json-ld context and frame that convert triples to
> my legacy JSON model and back
> works like a charm so far.
> This can be ported to most usecases, assuming you can define the proper
> context, frame, and set of sparql queries to extract statements
> my 2c,
> --p.
> On Sat, Aug 30, 2014 at 6:38 PM, Ricardo Pietrobon <pietr007@gmail.com>
> wrote:
>> I know the topic "mongodb and json-ld integration" has come up a few
>> times in this list, but our group is trying to make a decision regarding an
>> ideal architecture and so I thought I would get your input. Here is the
>> scenario:
>> 1. we have a ton of data on mongodb, but now we need to enhance a portion
>> of it with ontologies (at this point DC, FOAF and bio2rdf/mesh). we will be
>> relying heavily on sparql to make some inferences
>> 2. while we could have mongodb side by side with a triple store such as
>> Allegrograph, it would be easier to keep the whole thing under a single
>> database
>> 3. to my knowledge, I can run sparql queries on mongodb using
>> http://franz.com/agraph/support/documentation/v4/mongo-interface.html but
>> couldn't find much more on the limitations of this approach
>> the questions:
>> 1. is the allegro extension above still the best way of bringing json
>>  and json-ld together under mongodb
>> 2. any other sensible approach that could be attempted here
>> this is the short description of my case, I can provide more info if you
>> would like
>> many thanks
Received on Monday, 1 September 2014 09:40:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:18:42 UTC