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. . > On Mar 2, 2020, at 11:56 PM, Rob Atkinson <robatkinson...@gmail.com> 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 > <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 >>> >>> <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 <>. >> 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/F1B2AC01-30F7-49AD-85C9-03CBAAA45469%40topquadrant.com.
