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<https://json-ld.github.io/json-ld-star/#dfn-embedded-node>, and the description of an annotation object<https://json-ld.github.io/json-ld-star/#dfn-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.bo...@tno.nl<mailto:michel.bo...@tno.nl> Location<http://www.tno.nl/locations/DTS> [cid:image001.gif@01D71C13.1265D960]<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 <topbraid-users@googlegroups.com> Namens David Price Verzonden: donderdag 18 maart 2021 15:22 Aan: topbraid-users@googlegroups.com Onderwerp: Re: [topbraid-users] json-ld question 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. 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?âđ 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. To view this discussion on the web visit https://groups.google.com/d/msgid/topbraid-users/ca5a3a84d98c4753ad9bd83bfc0c3163%40tno.nl.
