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
|
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….
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 viewsMichel
Dr. ir. H.M. (Michel) Bohms
Scientist Specialist
Structural Reliability
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.
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.
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
|
|
|
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/242E6E67-AA35-47FB-B836-438F84EE42C6%40topquadrant.com.
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.
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
|
|
|
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.
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)
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”
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/971d3d366d874dcea265391c5ab5b5be%40tno.nl.
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
|
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f4c2c3ed-6b8c-6b04-9a11-b8426b5f61ce%40topquadrant.com.
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/7c512ec4d12542adb3636bc864b7b190%40tno.nl.
On 19 Mar 2021, at 07:25, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:Thx, VERY interestingQuite 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
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.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
--
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.
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
|
|
|
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/36FAFF4C-D946-4902-86DE-89780532E44C%40topquadrant.com.
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…..
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/00f2e63557e34b8fa11d935516d646c8%40tno.nl.
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!
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 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 questionThx David and HolgerYour 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
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.
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…)
|
|
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/B7A4EB90-968E-4DC6-A7B2-97A90B88095F%40topquadrant.com.
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 levelSo say: XSD versus OWL or, graphql schema versus shaclThe 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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/d58ecc117b364e19b7cb6ed84ee1772a%40tno.nl.
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 levelSo say: XSD versus OWL or, graphql schema versus shaclThe 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 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.
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
|
|
.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/E14CA62C-3B8E-4B3A-8D73-A3D3784D0712%40topquadrant.com.
On Mar 20, 2021, at 11:36 AM, 'Bohms, H.M. (Michel)' via TopBraid Suite Users <topbrai...@googlegroups.com> wrote:
Dear DavidThe 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
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/f52ce05d62cd4bfdbc59dd28e9ac443c%40tno.nl.
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.
Holger
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/9cc981c9-5af8-4b2d-b2e5-cfc800ff1f50n%40googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/a96c834f-0b77-78c0-80a8-2f3873e21cda%40topquadrant.com.