I dont think I misunderstood you .. the annotation would be the URI On Tuesday, 3 March 2020 23:58:56 UTC+11, Irene Polikoff wrote: > > 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 > > On Mar 3, 2020, at 2:22 AM, Rob Atkinson <robatki...@gmail.com > <javascript:>> wrote: > > 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. > > > > On Tuesday, 3 March 2020 17:35:21 UTC+11, Irene Polikoff wrote: >> >> 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 <robatki...@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 >> >> 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 topbrai...@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 topbrai...@googlegroups.com <javascript:>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/topbraid-users/edd186f6-26ae-4959-bfcb-ca5422790674%40googlegroups.com > > <https://groups.google.com/d/msgid/topbraid-users/edd186f6-26ae-4959-bfcb-ca5422790674%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/3aa7a14c-dca9-45db-86a4-f1afaf55cce9%40googlegroups.com.
