Thx, VERY interesting
Quite strong statements (ora) from a semantic web principal….
At the same time I think he is not very clear in arguments why he
thinks that way (json just being next xml)
I am more in the Newres/Gregg camp I think…
When ora says: It is never just JSON, ever”
Does he mean: people are making mistakes (like your next feedback
there) or “there is much more non-json out there”?
And he also repeats all the time: syntax is not the issue…ok,
semantics is bigger issue but isn’t that possible for json-ld then in
rdfs/owl/shacl/json schema/json-ld/graphql schema… etc. (so I do not
get the point)
michel
Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability
T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E [email protected] <mailto:[email protected]>
Location <http://www.tno.nl/locations/DTS>
<http://www.tno.nl/>
This message may contain information that is not intended for you. If
you are not the addressee or if this message was sent to you by
mistake, you are requested to inform the sender and delete the
message. TNO accepts no liability for the content of this e-mail, for
the manner in which you use it and for damage of any kind resulting
from the risks inherent to the electronic transmission of messages.
*Van:* [email protected]
<[email protected]> *Namens *Holger Knublauch
*Verzonden:* vrijdag 19 maart 2021 00:06
*Aan:* [email protected]
*Onderwerp:* Re: [topbraid-users] json-ld question
On 2021-03-19 2:28 am, 'Bohms, H.M. (Michel)' via TopBraid Suite Users
wrote:
Right!
I see indeed that the “webdev world only” data modelling
capabilities (graphql schema, json/json-ld, json schema, …) are
limited compared to RDFS/OWL/SHACL/SHACL-AF.
I wonder how the “LD-haters”
https://twitter.com/oralassila/status/1364946776252420103
<https://twitter.com/oralassila/status/1364946776252420103>
Holger
would deal with that….guess they just code it.
Avro was new to me…(https://en.wikipedia.org/wiki/Apache_Avro
<https://en.wikipedia.org/wiki/Apache_Avro>, yet another data
language)
Thx for the paper!
I see also the advantages of your ‘graphql-ld’ approach over Ghent
keeping the GraphQL Schema in the picture.
I was more wondering whether graphql (and graphql schema) could
use json-ld treatment more as first class citizen in some official
GraphQL*-LD (GraphQL Schema-LD) * instead of just as being a
special version of json… (in a sense standardizing the kind of
extensions you did)
(I see this discussion in their lists without clear answers though)
Thx michel
Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability
T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E [email protected] <mailto:[email protected]>
Location <http://www.tno.nl/locations/DTS>
<http://www.tno.nl/>
This message may contain information that is not intended for you.
If you are not the addressee or if this message was sent to you by
mistake, you are requested to inform the sender and delete the
message. TNO accepts no liability for the content of this e-mail,
for the manner in which you use it and for damage of any kind
resulting from the risks inherent to the electronic transmission
of messages.
*Van:* [email protected]
<mailto:[email protected]>
<[email protected]>
<mailto:[email protected]> *Namens *Irene Polikoff
*Verzonden:* donderdag 18 maart 2021 16:45
*Aan:* [email protected]
<mailto:[email protected]>
*Onderwerp:* Re: [topbraid-users] json-ld question
On Mar 18, 2021, at 10:21 AM, David Price
<[email protected] <mailto:[email protected]>> wrote:
On 18 Mar 2021, at 13:01, 'Bohms, H.M. (Michel)' via
TopBraid Suite Users <[email protected]
<mailto:[email protected]>> wrote:
Not really TBC questions but I guess you can give the best
answer.
I see popularity of json-ld rising a lot (as optimal
compromise between webdev and ld/sw world) where people
might just forget about the (for them) complex RDF
conceptuals above….
JSON-LD does nothing to reduce the complex concepts that might
be defined in RDFS, OWL or SHACL data models. JSON-LD is an
implementation format for RDF-based data. Without the
underlying RDF-based model there is no JSON-LD.
I interpreted Michel’s words to be about complexity of
understanding/using RDF data structures and technologies when
developing applications vs making it possible for developers to
stay in the JSON word. I did not think he was talking about data
models. If one stays solely within the JSON stack, the need for
data models is addressed by things like GraphQL Schema, JSON
Schema and Avro. They are pretty simple schema languages with
minimal expressivity.
I am attaching a presentation that may be useful in understanding
why we believe the combination of SHACL with GraphQL is more
powerful than just GraphQL Schema and GraphQL.
--
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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/3548DDA7-14A7-41F9-8314-1C590149FB96%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/3548DDA7-14A7-41F9-8314-1C590149FB96%40topquadrant.com?utm_medium=email&utm_source=footer>.
GraphQL tools and infrastructure rely on having GraphQL Schema. I
am referring to tools such as GraphiQL which we integrated into
EDG to provide interactive, syntax directed query development and
she documentation capabilities expected by the GraphQL query
developers. This is why EDG autogenerates GraphQL Schema to enable
GraphQL query.
Our approach is different from Ghent University:
Ghent University implementation translates GraphQL queries into
SPARQL, then runs SPARQL over RDF data. So, this is something that
could potentially sit in front of any SPARQL endpoint. I would,
however, expect the (necessary to this approach) heavy use of
OPTIONAL in the generated SPARQL to create performance problems
for SPARQL endpoints. Their use of JSON-LD is about taking
advantage of JSON-LD context to map textual ids in GraphQL e.g.,
“prefLabel” to the full URI.
In this approach, there is no GraphQL Schema to drive GraphQL
tools or to provide documentation to GraphQL developers as to what
they could actually query for. The GraphQL capabilities are
limited to vanilla GraphQL. GraphQL is a small and simple language
for APIs with the built-in ability to extend it and most GraphQL
implementations add such extensions. There is no way to define or
provide extended GraphQL query capabilities or to query the model
itself, etc.
TopBraid EDG generates enhanced GraphQL Schemas from SHACL. The
schema then enables GraphQL query. One of the benefits of this
approach is easy/seamless integration with the GraphQL tools and
ecosystem. GraphQL directives are used to hold information
necessary to create unique identifiers, so there is no need to
craft or use JSON-LD contexts. GraphQL infrastructure would not be
expected to understand or require JSON-LD context. Directives are
also use to describe the extended query capabilities. I will not
try to repeat in text other points described in the presentation
above.
Overall, Holger is probably the best person to address this question.
It makes sense for Web developers to use anything making
Javascript development easier (e.g. eliminating having to
learn a new format/syntax) . So, for that scenario JSON-LD may
very well be their preference.
However, most folks think TTL is easier to read and write in a
text editor, for example vs JSON-LD or RDF/XML. Also, if you
don’t know/prefer Javascript and JSON you may not going to
prefer JSON-LD or if your application is not browser-based
then it may actually be a Con, not a Pro.
In that sense I see more and more projects that go json-ld
(iso rdf/xml, turtle etc.) also involving storage options
like mongodb iso triple/quad stores. At the same time
people like graphql(-ld) over sparql.
Probably depends on if you come from a database vs. Web
developer background as much as anything else.
These trends gives rise for me to some issues:
1.
If RDF* evolves bringing us better metadata options
(treating statements as objects again) on LD side would
that also give rise to a JSON-LD* next to Turtle*?
Or is json-ld already by itself more flexible here so that
no change is needed? (ie is the current use of json-ld as
RDF serialization an already restricted usage?)
I am trying to find out if turtle and hence Turtle* will
have advantages over json-ld…
Until we see the final “standards” we cannot be 100% sure, but
it seems unlikely one will be better than the other wrt this
question. I imagine the criteria for choosing between them in
a specific scenario is unlikely to change. Again, we’ll have
to wait and see though as nobody knows right now.
2.
I know graphQL-LD approach as defined/demonstrated etc. by
Ghent university
(https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/
<https://comunica.github.io/Article-ISWC2018-Demo-GraphQlLD/>).
Is your prefixes graphql schema extension doing
(functionaly) the same?
Our Web site says:
/Query schemas for use with GraphQL are automatically
generated from the data models. This includes powerful
features to select, filter, aggregate, dynamically compute and
page results. For even more power, full support for SPARQL
expressions is available from GraphQL queries. Data updates
are automatically validated using SHACL shapes./
So I’ll guess not exactly the same as what Ghent is doing.
If so isn’t there room for a_standard_graph-ql-ld variant
having those extensions in a standard way?
Or… is such a GraphQL update already in the making (much a
like json to json-ld)?
There is a working draft next release of GraphQL online but it
does not mention this topic as far as I can tell. I’m not a
GraphQL expert though.
3.
What will happen in future: shacl or graphql schema or both?
(knowing slide no. 20
from:https://www.topquadrant.com/project/graphql_json_rdf/
<https://www.topquadrant.com/project/graphql_json_rdf/>)
If you mean in EDG for the next few years, then “both”. Cannot
say for others.
4.
Why is there a graphql schema language anyway? Why not use
json-ld schema definitions for that (because it is not
powerful enough)?
(like inschema.org <http://schema.org/>if I am right)
Sorry if these questions are out of scope.
It’s just that I need some story when people ask “why do
we have shacl/sparql, graphql schema/graphql, json-ld for
schemas (and also json schema)….can’t you make up your
mind?”😊
To add to what David says below, even within a single
community/technology, it is common to have multiple
solutions/approaches to addressing needs. This is not unique to
RDF/Linked Data/Semantic Web technologies. For example, with XML
you have two popular approaches to schema languages: XML Schema
and RelaxNG. With JSON you have JSON Schema, Avro and GraphQL
Schema. And so on.
That answer is simple - there is no “your mind”. Many
communities are involved in these standards and in industry
and each have their own needs/priorities. It’s a bit like
asking why we have Java and C and C++ and Python and
Javascript and Scala and Ruby.
That said, your list mixes things up a bit.
SPARQL is based on RDF, and RDF alone. It has nothing to do
with OWL or SHACL or TTL vs JSON-LD, etc. RDF and SPARQL are
W3C standards, produced by a consensus of members.
RDFS, OWL and SHACL are “modelling” languages that are built
over RDF. W3C standards, produced by a consensus of members.
RDF/XML, N-Triples, TTL, JSON-LD, etc. are all exchange
encodings and each has their pros and cons for different
scenarios providing software developers with options. W3C
standards, produced by a consensus of members.
GraphQL was a language invented by Facebook, so nothing to do
with RDF as they did not use RDF for their knowledge graph.
Not a formal standard.
You’d have to ask Facebook why they did not want to use
JSON-LD for schemas (I imagine because it is from RDF-land).
TopBraid EDG supports it because, for example, it allows
non-RDF-literate software developers to query RDF data without
using SPARQL.
It’s seldom you find best practices’ available of the form for
any information technology:
When X is your problem, then Y and Z are the best
practice approach.
When A is your problem, then B and C are the best practice
approach.
In other words, there are benefits to having options because
that lets *You* make up your mind based on what’s best for
your situation. Most enterprises depend on knowledgable
systems/software architect to help answer that kind of question.
Cheers,
David
Thx for your views
Michel
Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability
T +31 (0)88 866 31 07
M +31 (0)63 038 12 20
E [email protected] <mailto:[email protected]>
Location <http://www.tno.nl/locations/DTS>
<image001.gif> <http://www.tno.nl/>
This message may contain information that is not intended
for you. If you are not the addressee or if this message
was sent to you by mistake, you are requested to inform
the sender and delete the message. TNO accepts no
liability for the content of this e-mail, for the manner
in which you use it and for damage of any kind resulting
from the risks inherent to the electronic transmission of
messages.
--
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
[email protected]
<mailto:[email protected]>.
To view this discussion on the web
visithttps://groups.google.com/d/msgid/topbraid-users/5402dc770eb948068fe971f523d7879e%40tno.nl
<https://groups.google.com/d/msgid/topbraid-users/5402dc770eb948068fe971f523d7879e%40tno.nl?utm_medium=email&utm_source=footer>.
UK +44 (0) 7788 561308
US +1 (336) 283-0808
--
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
[email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/242E6E67-AA35-47FB-B836-438F84EE42C6%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/242E6E67-AA35-47FB-B836-438F84EE42C6%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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/3548DDA7-14A7-41F9-8314-1C590149FB96%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/3548DDA7-14A7-41F9-8314-1C590149FB96%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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/971d3d366d874dcea265391c5ab5b5be%40tno.nl
<https://groups.google.com/d/msgid/topbraid-users/971d3d366d874dcea265391c5ab5b5be%40tno.nl?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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/f4c2c3ed-6b8c-6b04-9a11-b8426b5f61ce%40topquadrant.com
<https://groups.google.com/d/msgid/topbraid-users/f4c2c3ed-6b8c-6b04-9a11-b8426b5f61ce%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 [email protected]
<mailto:[email protected]>.
To view this discussion on the web visit
https://groups.google.com/d/msgid/topbraid-users/7c512ec4d12542adb3636bc864b7b190%40tno.nl
<https://groups.google.com/d/msgid/topbraid-users/7c512ec4d12542adb3636bc864b7b190%40tno.nl?utm_medium=email&utm_source=footer>.
