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



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 <javascript:>> 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 <javascript:>.
    To view this discussion on the web visit
    
https://groups.google.com/d/msgid/topbraid-users/bbe0d0c2-6326-4dda-a107-703a3cdef750%40googlegroups.com
    
<https://groups.google.com/d/msgid/topbraid-users/bbe0d0c2-6326-4dda-a107-703a3cdef750%40googlegroups.com?utm_medium=email&utm_source=footer>.

-- 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 <javascript:>.
    To view this discussion on the web visit
    
https://groups.google.com/d/msgid/topbraid-users/2f99615b-75f8-7820-0d3c-3bd9d77f96c0%40topquadrant.com
    
<https://groups.google.com/d/msgid/topbraid-users/2f99615b-75f8-7820-0d3c-3bd9d77f96c0%40topquadrant.com?utm_medium=email&utm_source=footer>.

--
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-users+unsubscr...@googlegroups.com <mailto:topbraid-users+unsubscr...@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 <https://groups.google.com/d/msgid/topbraid-users/903ce7e7-012e-4bf2-af74-62439e539b5d%40googlegroups.com?utm_medium=email&utm_source=footer>.

--
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-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/d065bb24-1520-143e-7ef6-55ee25a72ff9%40topquadrant.com.

Reply via email to