Feature request: JSON-LD serializer

[phpnode]

The default serializer uses a pseudo-JSON format because JSON itself does not have primitives that can express things like record ids, sets etc. This means that any client library consuming the binary protocol must not only write a parser for the protocol itself, they must also write a parser for the serialization format that gets sent over that protocol.

While the format is quite simple and easy to parse, it's unlikely that the custom parser in the client library is going to be competitive performance wise with the native JSON implementation, especially so in e.g. JavaScript, PHP, Ruby, Python etc.

JSON-LD is a w3c standardised schema layer for JSON which is growing in popularity and can accurately express all of Orient's custom data types and graph database concepts without any loss of fidelity.

If Orient supported JSON-LD natively, it would be faster to consume for many client libraries using the binary protocol, and fix some limitations of the existing REST API, see #2243

[bollwyvl]

👍

Related to this would be hydra, which provides mechanisms for ensuring that such an API is documentable, discoverable and navigable.

[thadguidry]

👍

[Sfinx]

👍

[voxadam]

👍

[timothystone]

Any movement on this? Here's my 👍

[smolinari]

Although not completely related, I thought it might be good to reference the other suggestion for API improvement.

#5119

Scott

[abrown]

👍

[bollwyvl]

Yet another JSON-LD related flavor of API would be Linked Data Fragments, another W3C standard.

Being able to transparently write apps with a very simple client against orient would be very powerful.

[smolinari]

I am watching this video

https://www.youtube.com/watch?v=vioCbTo3C-4

and not understanding the advantage JSONLD would have over the current REST API.

Scott

[a-unite]

@smolinari it is not about replacing REST API, but about standart relationships aware and meaningfull structure of JSON answers and payloads.

[smolinari]

Ok, but the intent of JSONLD isn't really meant for the querying and mutating of data in a database like ODB, is it?

If you want more meaningful querying and mutating, then GraphQL is a much better standard than JSONLD.

Scott

[Sfinx]

JSON-LD is the extension for JSON to describe the linked data. The OrientDB's native graph are links and OrientDB already supports JSON. What the problem here ?

[smolinari]

No problem. Just trying to understand how JSONLD can be beneficial/ useful. I understand standardization is good, I just don't see the full effect with this standard. It wasn't meant for databases, from what I understand. And, to be honest, I'll admit I don't understand too much about all this either. LOL!

So, JSONLD is only for formating return data from select queries? It has no format for mutations, right? So, the rest of the REST API is needed for mutations too?

How would the context or id values be defined? Would the URIs be ODB's REST API URLs? How about types? What would ODB put under that key and how?

I can see semblances of relevance, just not any solution. That doesn't mean a thing really either. Just sayin.

Maybe someone could put up a more detailed suggestion on how JSONLD could help improve ODB's API, so more people like myself can understand the implications.

Scott

[Sfinx]

It is not clear what you mean under "mutations" - data changing ? Any thing in outside world can be modeled by linked semantic graph which in its turn can be described by JSON-LD standard. And ODB is perfectly storing such data. How the data will be queried is not so important for now. This issue is about the ODB data serialization to/from JSON-LD, not about some other API or so.

[smolinari]

Yes, mutation means changing state. When you do a create, update or delete, you are mutating the data storage state within the database.

I am going to stop. I personally just don't see the total benefit. I understand the benefit of following a standard. However, the real benefits of following THIS standard alludes me. I am no expert though and I would be open for any clear explanation.

Scott

[abrown]

@smolinari, here's how I understand it: JSON-LD is beneficial because it is a standard for how to format the data coming out of ODB. Right now, I would have to write adapter code to parse the specific ODB return formats from the REST API; if the REST API could format its results as JSON-LD, then I could use a JSON-LD library instead, saving myself some time. Additionally, if I have multiple applications that understand JSON-LD, I can take the objects returned from ODB and pass them around my system with little to no transformation. Is that more clear?

[smolinari]

Yes. That makes sense and thanks for the explanation. I think I understood that too, to some extent.

I guess I need to explain my perspective. I am a fan of GraphQL.

http://graphql.org/docs/api-reference-graphql/

To me, GraphQL is a better alternative for an HTTP / database interface, because it covers both querying and mutating. It was created as a proper interactive API, with a lot of advantages over normal REST(with or without response format standards), and thus is better suited to support database communication. The only disadvantage it has currently is, it isn't a fully recognized web standard. But, being Facebook is a huge force on the Internet, I would bet it will only be a matter of time, before it really catches on.

Scott

[thadguidry]

A few things for anyone wanting to begin hacking on ODB to support JSON-LD...

ODB could potentially become a qualified backend for Apache Marmotta. (as Postgres, MySQL, and H2 already are) - http://www.slideshare.net/wastl/apache-marmotta-introduction

ODB could look at the JSON-LD module for Apache Clerezza to get a headstart on parsing and serializing JSON-LD https://github.com/jsonld-java/jsonld-java-clerezza (actually ODB might or could even become an Apache Clerezza Triple Collection Provider - TC Provider - https://clerezza.apache.org/architecture/)

[smolinari]

I am no expert, and I am only reading stuff you've linked, so correct me if I am wrong, but....

ODB could potentially become a qualified backend for Apache Marmotta.

None of the current data stores Marmotta can use support JSON-LD. So, what is your point?

ODB could look at the JSON-LD module for Apache Clerezza to get a headstart on parsing and serializing JSON-LD

How widespread or popular is Clerezza? I'd say ODB is already miles ahead of Clerezza in popularity. So, to suggest making ODB a triple store for Clerezza would get it some kind of special advantage is false. Thus, the suggestion does nothing for the argument that ODB should support JSON-LD. In fact, the standard storage methods suggested by the Clerezza docs, Jena and Sesame, also do not support JSON-LD. So, if ODB would do what you suggest, who would ODB getting a head start on?

Scott

[thadguidry]

@smolinari I'm just helping @lvca with code examples to look at.

[smolinari]

Then the only example that comes close to helping is the Clerezza JSON-LD Module.

Scott

[acmeguy]

+1