Final remark:

If you have some good refs on the difference between structure & semantics, 
very welcome!

Personally I do not see this as two poles really…both deal with defining 
possibilities and impossibilities in your data. In that sense an XSD also 
covers semantics. And a json-ld spec on schema level also covers semantics. 
Clearly math/logic/graph-based SW-semantics in RDF/RDFS/OWL/SHACL-covers much 
MORE semantics.
In that sense I think the discussions on this aspect are a bit unnecessary 
polarized…..it feels more like different degrees of semantics….

But maybe there are some other essential differences that I do not see yet…..



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 michel.bo...@tno.nl<mailto:michel.bo...@tno.nl>

Location<http://www.tno.nl/locations/DTS>



[cid:image001.gif@01D71CAF.D9886C50]<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: 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com>
Verzonden: vrijdag 19 maart 2021 09:58
Aan: topbraid-users@googlegroups.com
Onderwerp: RE: [topbraid-users] json-ld question

Thx David and Holger

Your views really put things in perspective!

My conclusion at least like:
worlds come together syntactically but this is only a practical issue.
Semantically they are (and probably will stay) worlds apart with LD having the 
compat. Edge (basis in math/logic/grpahs)

In that sense I can now more clearly see TQ following the best path…

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 michel.bo...@tno.nl<mailto:michel.bo...@tno.nl>

Location<http://www.tno.nl/locations/DTS>



[cid:image001.gif@01D71CAF.D9886C50]<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: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com> 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> 
Namens David Price
Verzonden: vrijdag 19 maart 2021 09:29
Aan: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>
Onderwerp: Re: [topbraid-users] json-ld question



On 19 Mar 2021, at 07:25, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> wrote:

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 imagine it is because they are both only modelling *data structures* in a 
narrow context. People think they are doing “data modelling” or even modelling 
semantics, but they are not. JSON schema is modelling JSON data structures, so 
JSON Schema is like using XSDs. For XSDs, people used to get very confused 
because their tools produced nice diagrams that looked at bit like UML, for 
example. However, they were actually *nothing* like UML because all they 
modelled was the structure of XML and the only “meaning” they conveyed was 
containment, attribute, ID and data value. I would get dragged into consulting 
engagements in a previous job to explain this to them - Model your data using 
better languages (e.g. UML) and then implement it in some technology (e.g. 
XML/XSDs). If you do otherwise it will often eventually come back and bite you.


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)

I imagine something like this:

In the LD world, OWL has an underlying theory (sets and logic) and SHACL has an 
underlying theory (Graph Theory). JSON-LD has Javascript under it, on its own 
what it specifies are Javascript data structures with some RDF-based patterns 
so you can simulate say RDFS with it. It’s not better or worse than Python, 
Java, etc. on that front. It’s big advantage is that it’s great for 
browser-based apps. However, that does not mean it’s great for anything else on 
its own.

Technologists who support a “data centric” view are trying to make data an 
“asset” that organisations own and manage. If you are smart about that then 
data => knowledge. Supporting that means getting data out of any app or 
programming language. They argue that JSON-LD on its own doesn’t really do that.

Cheers,
David


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 michel.bo...@tno.nl<mailto:michel.bo...@tno.nl>

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.




Van: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com> 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> 
Namens Holger Knublauch
Verzonden: vrijdag 19 maart 2021 00:06
Aan: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>
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
Holger

would deal with that….guess they just code it.

Avro was new to me…( 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 michel.bo...@tno.nl<mailto:michel.bo...@tno.nl>

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.




Van: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com> 
<topbraid-users@googlegroups.com><mailto:topbraid-users@googlegroups.com> 
Namens Irene Polikoff
Verzonden: donderdag 18 maart 2021 16:45
Aan: topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>
Onderwerp: Re: [topbraid-users] json-ld question





On Mar 18, 2021, at 10:21 AM, David Price 
<dpr...@topquadrant.com<mailto:dpr...@topquadrant.com>> wrote:





On 18 Mar 2021, at 13:01, 'Bohms, H.M. (Michel)' via TopBraid Suite Users 
<topbraid-users@googlegroups.com<mailto:topbraid-users@googlegroups.com>> 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 
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/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/).
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/)

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 in schema.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 michel.bo...@tno.nl<mailto:michel.bo...@tno.nl>

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 
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/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 
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/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 
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/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 
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/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 
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/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 
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/7c512ec4d12542adb3636bc864b7b190%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/7c512ec4d12542adb3636bc864b7b190%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 
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/36FAFF4C-D946-4902-86DE-89780532E44C%40topquadrant.com<https://groups.google.com/d/msgid/topbraid-users/36FAFF4C-D946-4902-86DE-89780532E44C%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/00f2e63557e34b8fa11d935516d646c8%40tno.nl<https://groups.google.com/d/msgid/topbraid-users/00f2e63557e34b8fa11d935516d646c8%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 topbraid-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/topbraid-users/2eb2736ed1174297a6599424565f7d8d%40tno.nl.

Reply via email to