Support for JSON-LD

[R. U.S.]

Hi, I've been working with Topbraid for a while and now I need to support JSON-LD files (importing/editing/exporting). What is the current support for it? Can you point me to the documentation for this?

[Holger Knublauch]

Hi,

TopBraid includes the JSON-LD implementation of jsonld-java 0.12.5 as integrated into Jena. You could check what version of JSON-LD that is.

You can load and save JSON-LD files throughout TopBraid products, assuming the file ending is .jsonld. For example place them in the workspace as example.jsonld and you can double-click to open in TBC. Or Save as... and enter a file ending with .jsonld. Once a JSON-LD file has been loaded it is treated as any other RDF graph.

The scripting languages built into TopBraid, such as SWP and SPARQLMotion also support JSON-LD.

HTH
Holger

On 3/03/2020 06:44, 'R. U.S.' via TopBraid Suite Users wrote:

Hi, I've been working with Topbraid for a while and now I need to support JSON-LD files (importing/editing/exporting). What is the current support for it? Can you point me to the documentation for this?

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/35c653c7-8ee3-4954-8f4a-6d022be67050%40googlegroups.com.

[Rob Atkinson]

to fully "support" JSON-LD it would be required to support it in the main query interface - i.e. the GraphQL JSON response should be decorated with a JSON-LD context statement that binds the available URI identifiers to the graphql schema elements - after all the graphql schema is generated from the underlying SHACL models.

For interoperability such JSON-LD contexts should be modular of course - if a model imports SKOS then the JSON-LD context should import a SKOS context rather than dump it out. If this is too much work in the short term, I'd suggest that the injection of a context via a URI referencing another service which constructs the context for a given graphql schema - and if necessary leave it empty, but allow this to be customised by users to be more modular in future. This at least establishes an architecture which can be evolved to seamlessly allow more natively supplied detail in future, without too much effort in the short term.

[Holger Knublauch]

Hi Rob,

I am aware that other GraphQL implementations on top of RDF do support JSON-LD context generation. Technically, this might be doable, although there are some cases like sh:path expressions where there is no single property or triple that we could map to, and of course no JSON-LD would be able to map partial queries like { label } without also having a uri field.

The thing I would like to better understand is what would clients do with that info. My assumption is that we use GraphQL to "flatten" a graph into a tree structure for easy consumption by rather traditional client-side code, e.g. written in React or other JS libraries. Would those clients really have a full RDF-based API, and would they be able to make sense of the partial graphs that would be returned by the server? If yes, isn't a SPARQL CONSTRUCT a more natural way to produce graphs, instead of relying on another set of intermediate steps?

Holger

--

You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bbe0d0c2-6326-4dda-a107-703a3cdef750%40googlegroups.com.

[Irene Polikoff]

This was my thinking as well. 

Annotating GraphQL query result with JSON-LD would seem to be useful only for converting JSON returned by the GraphQL query back to RDF. In our experience, however, GraphQl queries are used by applications that are not RDF aware. They do not need to get RDF back from the GraphQL endpoint.  We have not, so far, received any requirements (or even questions) about supporting JSON-LD context in GraphQL.

I would also not go as far as describe GraphQL as “the main query interface” in TopBraid EDG. SPARQL is and always has been fully supported. I think GraphQL is the main and preferred interface for the traditional client-side applications.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2f99615b-75f8-7820-0d3c-3bd9d77f96c0%40topquadrant.com.

[Rob Atkinson]

An example of an API that moved from JSON to JSON-LD :

https://fiware-datamodels.readthedocs.io/en/latest/ngsi-ld_howto/index.html

why? - not because they need clients to be RDF aware, but because they need data transfers to be semantically explicit - even if it just means unambiguous data values, and Linked Data as a basic client behaviour that requires no extar RDF overhead.

Its true that there is no Web of Data functioning really, and there are ad-hoc data models everywhere and dumb clients - but that doesnt mean thats the only implementation pattern that makes sense.

Would I build an API for a Web context these days without using JSON as a payload ... no! Would I use JSON without enabling Linked Data - no!  

I dont understand why it would make sense to be crippling APIs by throwing away semantic information that can be added with so little overhead, and without compromising backwards compatibility. Sure we could just build wrappers that fix this, but they are unlikely to be as efficient and add a burden to find or wrtie such extensions.

On Tuesday, 3 March 2020 12:20:13 UTC+11, Irene Polikoff wrote:

This was my thinking as well. 

Annotating GraphQL query result with JSON-LD would seem to be useful only for converting JSON returned by the GraphQL query back to RDF. In our experience, however, GraphQl queries are used by applications that are not RDF aware. They do not need to get RDF back from the GraphQL endpoint.  We have not, so far, received any requirements (or even questions) about supporting JSON-LD context in GraphQL.

I would also not go as far as describe GraphQL as “the main query interface” in TopBraid EDG. SPARQL is and always has been fully supported. I think GraphQL is the main and preferred interface for the traditional client-side applications.

On Mar 2, 2020, at 6:52 PM, Holger Knublauch <hol...@topquadrant.com> wrote:

Hi Rob,

I am aware that other GraphQL implementations on top of RDF do support JSON-LD context generation. Technically, this might be doable, although there are some cases like sh:path expressions where there is no single property or triple that we could map to, and of course no JSON-LD would be able to map partial queries like { label } without also having a uri field.

The thing I would like to better understand is what would clients do with that info. My assumption is that we use GraphQL to "flatten" a graph into a tree structure for easy consumption by rather traditional client-side code, e.g. written in React or other JS libraries. Would those clients really have a full RDF-based API, and would they be able to make sense of the partial graphs that would be returned by the server? If yes, isn't a SPARQL CONSTRUCT a more natural way to produce graphs, instead of relying on another set of intermediate steps?

Holger

On 3/03/2020 09:22, Rob Atkinson wrote:

to fully "support" JSON-LD it would be required to support it in the main query interface - i.e. the GraphQL JSON response should be decorated with a JSON-LD context statement that binds the available URI identifiers to the graphql schema elements - after all the graphql schema is generated from the underlying SHACL models.

For interoperability such JSON-LD contexts should be modular of course - if a model imports SKOS then the JSON-LD context should import a SKOS context rather than dump it out. If this is too much work in the short term, I'd suggest that the injection of a context via a URI referencing another service which constructs the context for a given graphql schema - and if necessary leave it empty, but allow this to be customised by users to be more modular in future. This at least establishes an architecture which can be evolved to seamlessly allow more natively supplied detail in future, without too much effort in the short term.

On Tuesday, 3 March 2020 09:29:44 UTC+11, R. U.S. wrote:

Hi, I've been working with Topbraid for a while and now I need to support JSON-LD files (importing/editing/exporting). What is the current support for it? Can you point me to the documentation for this?

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/bbe0d0c2-6326-4dda-a107-703a3cdef750%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "TopBraid Suite Users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to topbrai...@googlegroups.com.

[Irene Polikoff]

As an option, one could in the future provide JSON-LD context. I am saying “as an option” because I would not want to force it on applications and users that are not interested in it and will find it confusing or overcomplicating. 

With respect to what makes sense and whether this is something important enough to address, - rightly or wrongly, at the moment, we do not hear about demand for this, while we do get a lot of demand and many requests for other things. This could change in the future as the application development patterns shift. We always need to make sure we are assigning requests for features the right priority. Practically speaking, it is very important to focus on what most or, at least, a sizable percentage of customers need today.

Further, what are your thoughts about how SHACL paths would be addressed? They are quite common - for inverses, for example. . 

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/903ce7e7-012e-4bf2-af74-62439e539b5d%40googlegroups.com.

[Rob Atkinson]

well I'll leave it there having pointed out there is movement in this direction in some places - its obviously your choice :-)

re the SHACL paths issue - may need a little bit more of an example, but it may require annotation of the SHACL path, or an automated rule, to bind the graphql output data element to a URI - but its perfectly legal to leave these unbound too - you just wont be able to convert those bits to RDF in the client (if you really wanted to - we're all sceptical about that).   Anyway - this is the sort of thing I was suggesting could be left to customisable configuration, do the simple things first.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/903ce7e7-012e-4bf2-af74-62439e539b5d%40googlegroups.com.

[Irene Polikoff]

Not sure what you mean - 

it may require annotation of the SHACL path, or an automated rule, to bind the graphql output data element to a URI 

What URI? There is no property URI to bind to. It is a path that either goes in inverse of a single property or traverses a chain of properties. The chain can be of variable length.

Sent from my iPhone

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/edd186f6-26ae-4959-bfcb-ca5422790674%40googlegroups.com.

[Rob Atkinson]

I dont think I misunderstood you .. the annotation would be the URI 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/edd186f6-26ae-4959-bfcb-ca5422790674%40googlegroups.com.

[Holger Knublauch]

On 3/03/2020 14:56, Rob Atkinson wrote:

An example of an API that moved from JSON to JSON-LD :

https://fiware-datamodels.readthedocs.io/en/latest/ngsi-ld_howto/index.html

why? - not because they need clients to be RDF aware, but because they need data transfers to be semantically explicit - even if it just means unambiguous data values, and Linked Data as a basic client behaviour that requires no extar RDF overhead.

This is a valid point assuming that clients do understand JSON-LD. In the GraphQL world, which may or may not be already much larger than the RDF world, the mechanism is called schema introspection.

https://graphql.org/learn/introspection/

Basically clients can ask questions about which fields are available, and what their datatypes and cardinalities are. For a JSON client this is maybe sufficient (e.g. to understand whether a field is Boolean or Number). TopBraid's GraphQL implementation adds more details to this introspection vocabulary, and that's how the UI of the new editor in EDG is built.

https://www.topquadrant.com/graphql/graphql-queries.html#introspection

Holger

To unsubscribe from this group and stop receiving emails from it, send an email to topbraid-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/903ce7e7-012e-4bf2-af74-62439e539b5d%40googlegroups.com.