json-ld question

[Bohms, H.M. (Michel)]

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….

 

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.

 

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…

 

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?

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)?

 

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/)

 

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 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?”😊

 

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...@tno.nl Location   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.

 

[David Price]

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

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 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?”😊

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...@tno.nl Location

<image001.gif>

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-user...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/5402dc770eb948068fe971f523d7879e%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Thx David, all clear!

 

 

Wrt the red below, the editor things differently in: http://manu.sporny.org/2014/json-ld-origins-2/

 

Where he says:

 

“

I’ve heard many people say that JSON-LD is primarily about the Semantic Web, but I disagree, it’s not about that at all. JSON-LD was created for Web Developers that are working with data that is important to other people and must interoperate across the Web. The Semantic Web was near the bottom of my list of “things to care about” when working on JSON-LD, and anyone that tells you otherwise is wrong. 

TL;DR: The desire for better Web APIs is what motivated the creation of JSON-LD, not the Semantic Web. If you want to make the Semantic Web a reality, stop making the case for it and spend your time doing something more useful, like actually making machines smarter or helping people publish data in a way that’s useful to them.

"

 

For someone with an RDF-hat that sees JSON-LD as “just” a RDF serialization (like turtle, drf/xml, nriples etc.)  I can see your point.

But we have to be aware of people with other heads.

 

And yes, I know RDFS/OWL/SHACL are providing features not in json-ld (when used on schema level), JSON Schema or  graphql schema.

 

So indeed as you say the truth will be in the middle (of webdev & LD) depending on the specific use cases.

Its more that we are promoting LD so much but at the same time and we encounter people  that like manu sporny want to do things simpler, webdev-based, etc. and then we need a good story.

Sometimes wished we good look 5 /10 years ahead 😊

 

THX Michel

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/242E6E67-AA35-47FB-B836-438F84EE42C6%40topquadrant.com.

[Bohms, H.M. (Michel)]

Wrt my first issue I just came across:

 

https://json-ld.github.io/json-ld-star/

 

😊

 

Which was exactly I was looking for !

 

(This NOTE explores an extension of JSON-LD which can allow the value of an @id property to be an embedded node, and the description of an annotation object which serves as a short-hand when the annotated value also is described directly in the graph.)

 

{

 "@context": {

    "@base": "http://example.org/",

    "@vocab": "http://example.org/"

 },

 "@id": {

    "@id": "bob",

    "age": 42

 },

 "certainty": 0.8

}

 

Gr 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...@tno.nl Location

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.

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/242E6E67-AA35-47FB-B836-438F84EE42C6%40topquadrant.com.

[Irene Polikoff]

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

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

[Bohms, H.M. (Michel)]

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” 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...@tno.nl Location

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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Irene Polikoff
Verzonden: donderdag 18 maart 2021 16:45
Aan: topbrai...@googlegroups.com
Onderwerp: Re: [topbraid-users] json-ld question

 

--

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-user...@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.

 

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.

 

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.

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/242E6E67-AA35-47FB-B836-438F84EE42C6%40topquadrant.com.

 

--
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-user...@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.

[Irene Polikoff]

On Mar 18, 2021, at 12:28 PM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

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)

I think this would be up to the GraphQL community. What GraphQL spec already has is the ability to use directives for extensions: https://graphql-ruby.org/type_definitions/directives which is what we used

[Holger Knublauch]

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

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/971d3d366d874dcea265391c5ab5b5be%40tno.nl.

[Bohms, H.M. (Michel)]

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 michel...@tno.nl Location   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.

 

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f4c2c3ed-6b8c-6b04-9a11-b8426b5f61ce%40topquadrant.com.

[Holger Knublauch]

Both RDF/XML and JSON-LD have the problem that there are so many syntactic variations for the same graph. They both offer various rendering options, JSON-LD also has a notion of context that makes it even less predictable. So basically those developers who want to use it just like any other JSON need to define a very specific subset of JSON-LD or else they need to go through a graph data structure, which defeats the purpose of having the JSON tree structure in the first place. Of course, as long as you follow one very strict subset of JSON-LD then you may be able to benefit from the best of both worlds: having a "normal" JSON serialization while being also compatible with infrastructure that understands RDF.

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/7c512ec4d12542adb3636bc864b7b190%40tno.nl.

[David Price]

On 19 Mar 2021, at 07:25, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@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...@tno.nl Location

<image001.gif> 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: topbrai...@googlegroups.com <topbrai...@googlegroups.com> Namens Holger Knublauch
Verzonden: vrijdag 19 maart 2021 00:06
Aan: topbrai...@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...@tno.nl Location

-- 
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-user...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/7c512ec4d12542adb3636bc864b7b190%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

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...@tno.nl Location

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.

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/36FAFF4C-D946-4902-86DE-89780532E44C%40topquadrant.com.

[Bohms, H.M. (Michel)]

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...@tno.nl Location   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.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/00f2e63557e34b8fa11d935516d646c8%40tno.nl.

[David Price]

On 19 Mar 2021, at 10:06, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Final remark:

 

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

Even Wikipedia is your friend and then just read the specs themselves  - see below.

 

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…..

XML & XSDs are syntax/structure, that’s different from semantics.  Using your phrasing - one says what’s possible wrt storing your data, the other says what data is possible and how that data is to be interpreted.

Syntax: the set of rules that defines the combinations of symbols that are considered to be correctly structured statements or expressions in that language

Semantics: 

• (general) is the study of meaning, reference, or truth; 
• (logic) the study of the interpretations of formal and natural languages;
• (programming) is the field concerned with the rigorous mathematical study of the meaning of programming languages. It does so by evaluating the meaning of syntactically valid strings defined by a specific programming language, showing the computation involved.

XML/XSD:

The first sentence on the W3C XML Schema page says “An XML Schema is a language for expressing constraints about XML documents.”

XML says: Extensible Markup Language describes a class of data objects called XML documents and partially describes the behavior of computer programs which process them. XML is an application profile or restricted form of SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML documents. 

XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.

Clearly, XSDs specify exactly zero semantics as it’s about “constraints” on “storage units” and “markup of storage layout”.  I’m sure there are blogs claiming XSDs have “meaning” aka semantics, but those blogs are demonstrably wrong if you just read the specs (nobody reads any more … my rant :-)

JSON-LD:

JSON-LD on its own has some semantics, but only because Javascript is a formal language with semantics showing the computation involved in processing the language. However, on its own as a specification language it certainly comes nowhere near the definitions of semantics above.

Change:

The discussions get a bit “polarised” because people pushing “data as an asset” and getting closer to "data => knowledge "are trying to make *change*, and change is hard and often slow (e.g. I’ve been at it since the 1990s, first with the ISO STEP standards and now with W3C semantic/LD standards).

That *change* is to make industry understand that you must move away from syntax and into semantics that are closer to “the study of meaning, reference, or truth" to get to knowledge. Many enterprises have made huge successes on that front, others are stuck in 1990s with XML (…Oh well, you can’t win ‘em all). 

The rationale for all this are things like not crashing landers into Mars due to confusion about UoMs and so that the UK government can know which UK apartment blocks have very flammable cladding on them - which they could not answer after 72 people died in a completely avoidable fire. The UK started a giant National Digital Twin Programme to enable with Smart Cities/Roads/etc (and to be able to answer questions about cladding).

FWIW folks who are very serious wrt “meaning/truth” in this discipline go as far as choosing a specific metaphysic as a foundation and that’s where you get ISO 15926/BORO/IDEAS (4-dimentionalism), BFO (categories of continuant and occurrent) and other similar upper ontologies. Full disclosure - when working on STEP I also I worked on the ISO 15926 standard myself too.

I’m not saying everyone should use an upper ontology, and please don’t get me wrong - JSON-LD is a great thing, as is GraphQL. I’m just saying let’s just be honest/accurate and not get carried away with what they really are and really mean.

Cheers,

David

 

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...@tno.nl Location   <image001.gif> 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 <topbrai...@googlegroups.com> 
Verzonden: vrijdag 19 maart 2021 09:58
Aan: topbrai...@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...@tno.nl Location

<image001.gif> 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.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/2eb2736ed1174297a6599424565f7d8d%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

I fully agree that adding generic upper ontologies increase semantic meaning of the stuff below specialized.

(we do that ourselves in our cen European Semantic Modelling & Linking standard by providing a “top level model” covering PhysicalObject, Event, State, Activity etcetc.)

 

(But..) here I just wanted to focus on the language level

 

So say: XSD versus OWL or, graphql schema versus shacl

 

The second seems quite semantically compatible (given your 1-to-1 link in your tooling).

 

Lets focus on the first.

 

What does an OWL ontology provide essentially more than an XSD schema.

 

Yes owl defines semantics and xsd defines ‘just’ structure following defs below but…what does it mean exactly?

 

When I define a elementtype in xsd or class in owl..both indicate a declaration of a thing of interest.

Attributes and subelements in xsd give further meaning like datatype props and object props in owl.

 

Is it the fact that owl defines the restrictions and xsd cannot that is distinguishing the “structure” from the “semantics”?

(guess not because datatypes also limit values and they are on both sides…)

 

Or is it the fact that xsd misses the underlying logic entailment?

 

Or …. ???

 

THAT are the kind of arguments I am looking for…….

 

(of course Wikipedia is a high level source here but not really giving precise answers…)

 

 

 

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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/B7A4EB90-968E-4DC6-A7B2-97A90B88095F%40topquadrant.com.

[robatki...@gmail.com]

Holger is on the money in that there are many ways of doing RDF -> JSON-LD.    

Personally I think from the perspective of interoperability and ease of use we need to work on patterns to contextualise JSON schemas - not create JSON schemas to match one of many possible ways of expressing models.

Would always want to model in RDF modelling languages - but always want to choose my serialisation frame either for simplicity or to match some frame already in use.  So for me the requirement is to be able to retrofit JSON with contexts.  

RDF models should provide canonical reusable contexts to support this.   IMHO namespaces should resolve to json schema and json contexts using HTTP content negotiation for the relevant MIME types.

An interesting experiment would be to see if graphql json schemas can be automatically annotated with contexts derived from the RDF models that drive them.  SHACL seems to have all the information we need to do this.

I have been exploring tooling to normalise RDF models -  https://github.com/RDFLib/profilewiz  - generating JSON schema and contexts seems quite feasible, but usually you have to unpack the anti-pattern of declaring modelling intent by bundling statements from many resources into a graph with preserving the underlying dependencies.

[Irene Polikoff]

May be this https://timzhao.blogspot.com/2010/09/3-different-xml-design-styles-russian.html with concrete examples will help.

In addition to the 3 popular styles demonstrated in this example, there is also “Garden of Eden” XSD design style and the “Bologna” style actually representing absence of style.

On Mar 19, 2021, at 8:05 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

I fully agree that adding generic upper ontologies increase semantic meaning of the stuff below specialized.

(we do that ourselves in our cen European Semantic Modelling & Linking standard by providing a “top level model” covering PhysicalObject, Event, State, Activity etcetc.)

 

(But..) here I just wanted to focus on the language level

 

So say: XSD versus OWL or, graphql schema versus shacl

 

The second seems quite semantically compatible (given your 1-to-1 link in your tooling).

 

Lets focus on the first.

 

What does an OWL ontology provide essentially more than an XSD schema.

 

Yes owl defines semantics and xsd defines ‘just’ structure following defs below but…what does it mean exactly?

 

When I define a elementtype in xsd or class in owl..both indicate a declaration of a thing of interest.

Attributes and subelements in xsd give further meaning like datatype props and object props in owl.

 

Is it the fact that owl defines the restrictions and xsd cannot that is distinguishing the “structure” from the “semantics”?

(guess not because datatypes also limit values and they are on both sides…)

 

Or is it the fact that xsd misses the underlying logic entailment?

 

Or …. ???

 

THAT are the kind of arguments I am looking for…….

 

(of course Wikipedia is a high level source here but not really giving precise answers…)

 

 

 

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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d58ecc117b364e19b7cb6ed84ee1772a%40tno.nl.

[David Price]

On 19 Mar 2021, at 12:05, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

I fully agree that adding generic upper ontologies increase semantic meaning of the stuff below specialized.

(we do that ourselves in our cen European Semantic Modelling & Linking standard by providing a “top level model” covering PhysicalObject, Event, State, Activity etcetc.)

 

(But..) here I just wanted to focus on the language level

 

So say: XSD versus OWL or, graphql schema versus shacl

 

The second seems quite semantically compatible (given your 1-to-1 link in your tooling).

 

Lets focus on the first.

 

What does an OWL ontology provide essentially more than an XSD schema.

 

Yes owl defines semantics and xsd defines ‘just’ structure following defs below but…what does it mean exactly?

Hi Michel,

Just reading the XSD/XML spec to see what it means exactly: 

An XML Schema is a language for expressing constraints about XML documents. XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is made up of characters, some of which form character data, and some of which form markup. Markup encodes a description of the document's storage layout and logical structure. XML provides a mechanism to impose constraints on the storage layout and logical structure.

An XML Schema is a schema about XML documents - it quite literally means nothing else, by-definition.

Phrases like “storage layout” tell you the level at which XSDs and XML are important and if people read that and still misunderstand, then I’ll just have to admit defeat wrt how to talk to those people on this topic.

When I define a elementtype in xsd or class in owl..both indicate a declaration of a thing of interest.

An element type is declaring a constraint on an XML document storage structure/layout. It quite literally has nothing to do with “a thing of interest” unless that thing is an XML document,.

Attributes and subelements in xsd give further meaning like datatype props and object props in owl.

Same again.

 

Is it the fact that owl defines the restrictions and xsd cannot that is distinguishing the “structure” from the “semantics”?

(guess not because datatypes also limit values and they are on both sides…)

 

Or is it the fact that xsd misses the underlying logic entailment?

As XSD is only about the structure of an XML document, it literally misses *everything* else.

As I mentioned, that misunderstanding of XML/XSD is not uncommon. That misunderstanding is often helped along by XSD tools that show nice digraphs into which people’s brains add meaning that just isn't actually there. People use the tools without reading the specs, so I’d suggest they should read the specs if they want to participate in any debate on the topic.

 

Or …. ???

 

THAT are the kind of arguments I am looking for…….

 

(of course Wikipedia is a high level source here but not really giving precise answers…)

I used Wikipedia definitions because they seem very clear to me and if someone doesn’t already understand the difference between XML Schema and OWL and between syntax and semantics, then they are unlikely understand the technical language in the OWL specs themselves.

Have a look at https://www.w3.org/TR/owl-direct-semantics/ for one formal definition (i.e. interpretation) of what OWL means. That doc specifies the rules about what you can infer from what you have, for example.

As an aside, it also occurs to me that if your conversions are with people who don’t understand a lot of this already, then you may be talking to the wrong people in the organisation. Maybe look more for IT architects who usually understand more about this level of thinking?

I’m repeating myself again, again .. so will stop now and get back to work. For more on this argument see: https://www.youtube.com/watch?v=ohDB5gbtaEQ

Cheers,

David

 

 

 

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...@tno.nl Location   <image001.gif> 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.

 

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d58ecc117b364e19b7cb6ed84ee1772a%40tno.nl.

UK +44 (0) 7788 561308

US +1 (336) 283-0808‬

[Bohms, H.M. (Michel)]

Dear David

 

The issue between structure/semantics is certainly not the same issue between syntax/semantics.

 

A data file (xml or turtle) has a certain syntax (say xml or turtle) and potentially a specification governing its contents. This specification defines the semantics of the data file. It can be a uml diagram, an xsd schema or a owl ontology, etc.

 

Surely one specification is “more semantic” then another: has more or less power to say something about the data. So an owl ontology because of its logic nature is more semantic than an xsd schema allowing for logic inference.

 

But in the end any specification says something about the possibilities and impossibilities in the data via the classes/elementypes/concepts used for classification.

 

When promoting the LS/SW stack in NL/Europe we encounter a lot of skepticism esp. from software developers (who think json is good enough, even schemaless json.).

WE explain them indeed that this is just syntax and that it is good that they add a specification (in their situation say : use json-ld involving also @type etc.).

 

If they understand that we still have to convince them that the linked data specifications are the better, more semantic option (better than xsd, better than json-ld spec, or a json schema schema….)

 

So for that issue I was looking for the best arguments…..what does an owl ontology or shacl graph do better than an xsd schema.

 

(Graphql schema seems somewhere in the midlle, with some extension on the grahql side you get a 1-to-1 to shacl as in your code).

 

One “indicator” is as in Irene’s latest reference:

If there are many ways to model exactly the intended semantics both data/schema are more structural than semantic.

Aside from the order of declarations (which always gives variability since “order” is non-semantic), a linked data file seems more deterministic than an xml file in that sense.

 

But in the end it is the fundament of logic (/maths/graphs) that gives the ontologies the more precise semantics then the mere structure of say xsd.

 

But ok, let’s not keep you from your work anymore,

Greetings 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...@tno.nl Location

.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E14CA62C-3B8E-4B3A-8D73-A3D3784D0712%40topquadrant.com.

[Irene Polikoff]

Michel,

If someone is satisfied with whatever technology they are using, trying to convince them that something else is better is typically a waste of time. In order to make a change, they first need to feel some pain, experience some problem that they feel must be solved. 

Changing what one is doing always has a cost. People change their ways only if they see that the new way offers a solution that addresses their perceived issues and the gain they get is larger than the cost of change. If these developers do not see any issues with their current approach and/or they already created satisfactory (to them) solutions for the issues, chances are there is nothing you can say that will convince them.

To have a listening, you need to find a person with a problem.

On Mar 20, 2021, at 11:36 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:

Dear David

 

The issue between structure/semantics is certainly not the same issue between syntax/semantics.

 

A data file (xml or turtle) has a certain syntax (say xml or turtle) and potentially a specification governing its contents. This specification defines the semantics of the data file. It can be a uml diagram, an xsd schema or a owl ontology, etc.

 

Surely one specification is “more semantic” then another: has more or less power to say something about the data. So an owl ontology because of its logic nature is more semantic than an xsd schema allowing for logic inference.

 

But in the end any specification says something about the possibilities and impossibilities in the data via the classes/elementypes/concepts used for classification.

 

When promoting the LS/SW stack in NL/Europe we encounter a lot of skepticism esp. from software developers (who think json is good enough, even schemaless json.).

WE explain them indeed that this is just syntax and that it is good that they add a specification (in their situation say : use json-ld involving also @type etc.).

 

If they understand that we still have to convince them that the linked data specifications are the better, more semantic option (better than xsd, better than json-ld spec, or a json schema schema….)

 

So for that issue I was looking for the best arguments…..what does an owl ontology or shacl graph do better than an xsd schema.

 

(Graphql schema seems somewhere in the midlle, with some extension on the grahql side you get a 1-to-1 to shacl as in your code).

 

One “indicator” is as in Irene’s latest reference:

If there are many ways to model exactly the intended semantics both data/schema are more structural than semantic.

Aside from the order of declarations (which always gives variability since “order” is non-semantic), a linked data file seems more deterministic than an xml file in that sense.

 

But in the end it is the fundament of logic (/maths/graphs) that gives the ontologies the more precise semantics then the mere structure of say xsd.

 

But ok, let’s not keep you from your work anymore,

Greetings 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...@tno.nl Location

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f52ce05d62cd4bfdbc59dd28e9ac443c%40tno.nl.

[robatki...@gmail.com]

Am wondering if I've missed some update in EDG capability... can we have a link to the latest documentation on JSON-LD if there has been a change from GraphQL -> JSON (not JSON-LD)

In one of my lives I'm keen to explore the intersection of SHACL and JSON  and I think a minimal level of lossless interoperability for graph data exposed by a service using JSON should look like this:

OWL (concepts) + SHACL (shapes = schema + constraints) ->  JSON + JSON-schema + JSON-LD context 

where...

JSON-schema and JSON-LD contexts reflect the underlying modularity and reusability of the original OWL ontologies 

i.e. if   X (OWL) imports Y (OWL)

then X (JSON-LD context) has a nested reference to Y (JSON-LD context)

(yes it does probably imply content negotiation for the ontologies to access the relevant schema and context views of the ontology - but thats Linked Data 101 and not relevant to the conceptual split)

the challenge is there are many ways of encoding JSON-LD - so we are assuming the JSON-Schema enforces one, and the JSON-LD context just preserves the IRI context for each element.

so if EDG uses GrahphQL for SHACL -> JSON  then I guess there is a constraint on the JSON-Schema based on the way the GrpahQL schema is used (which is OK - schemas are relatively easy to  transform) - which means its really only the JSON-LD context that requires to be generated and included.

[Holger Knublauch]

Hi Rob,

this is a complex topic, and I am not sure what your actual question is apart from "this sounds like an interesting area of future investigation". The main documents that describe our GraphQL mapping are on

    https://www.topquadrant.com/technology/graphql/

and this mapping has remained unchanged for a couple of years now.

The "other" technology that has sprung up recently in this space is Active Data Shapes, which makes it easier to parse or generate JSON from TopBraid, and that has its own mapping from shapes to JavaScript classes and thus instance structures.

    http://datashapes.org/active/

Holger

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9cc981c9-5af8-4b2d-b2e5-cfc800ff1f50n%40googlegroups.com.

[Rob Atkinson]

the question was "have i missed something?" - so your answer helps me be sure i havent - thanks..  will look at this again when we explore the future OpenAPI options.

To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/a96c834f-0b77-78c0-80a8-2f3873e21cda%40topquadrant.com.