|GraphQL in TopBraid Click image for an expanded view||We fielded several questions as part of our recent webinar, GraphQL: Bringing the Worlds of JSON and RDF Together.
The webinar focused on the new GraphQL capabilities of TopBraid 6.0.
Questions about TopBraid Enterprise Data Governance (EDG) and GraphQL included:
Q1: In terms of getting JSON, how does this approach compare to using JSON-LD with SPARQL?
This question may require a dialog. Please feel free to post your question again on the topbraid-users list. I don’t see how SPARQL could be used to produce the nested JSON structures that GraphQL can produce.
Q2: In respect to GraphQL and SPARQL: Can you select subgraphs (CONSTRUCT) and expert aspects like (ASK) in GraphQL?
Our GraphQL implementation does not produce graph. It returns nested JSON objects. If you need to return RDF graph, SPARQL CONSTRUCT is the way to go and TopBraid offers SPARQL endpoint. For ASK queries, yes, you can use the filter parameter, see Filtering by SPARQL Expressions.
Q3: Is the transformation capability part of GraphQL, or a TopBraid extension? Is it restricted to SPARQL built-ins?
GraphQL, in general, is only a very light-weight language. The standard only defines how to fetch fields but does not prescribe any meaning to operations such as transformations. The transform parameter is therefore necessarily a TopBraid extension. It uses standard syntax, but other engines would likely not understand what it does. And yes, it is currently using SPARQL only, including any user-defined SHACL or SPIN functions that are part of your TopBraid installation. If you have other suggestions for transformation languages, let us know.
Q4: When do you think GraphQL support will be added to TopBraid Free Edition?
We are not planning on adding GraphQL to TBC FE. GraphQL is a query language for APIs. It is a syntax that describes how to ask for data, and is generally used to load data from a server to a client. It lets the client specify exactly what data it needs. Thus, we support it in the server products and also in TBC-ME because it is used as an IDE for the server. It would not make sense to have it in TBC-FE or TBC-SE since they can not be used as a server, nor can’t they be used as an IDE for the TopBraid server.
Q5: Can EDG also edit SHACL annotations (if I got that term right)?
Yes, EDG offers editing capabilities for SHACL. See this blog post for examples. . This has been written nearly 2 years ago, and there are more features now. The best approach is to try it out for yourself. See the video “Overview of Ontology Modeling with TopBraid EDG” video which shows a demo of editing SHACL in TopBraid EDG including editing what you may be calling annotations i.e., statements that are not used for data validation, but used to support UI construction.
Q6: Have you given up SPARQL because it was not used enough?
We have not given up on SPARQL. TopBraid products continue full support for SPARQL. We are leveraging SPARQL in many ways and will continue to do so. However, SPARQL queries return tabular structures and applications and APIs today mainly require JSON. Further, GraphQL is a simpler language for developers to work with. TopBraid products have libraries for producing JSON (e.g., SWON in SWP) from SPARQL results, but GraphQL is a simpler, more accessible approach. Both languages have their individual strengths and weaknesses and can complement each other. For example, many SPARQL features can be used as “fallback” in GraphQL queries when the built-in capabilities are not expressive enough.
Q7: Any logical operators?
If your GraphQL query contains multiple where clauses (e.g. both minCount and maxCount) then they are interpreted as intersection. The where clauses do not have a syntax for “or” or “not” yet. If you have example use cases and maybe a surface syntax that you’d like to see, we can probably add them. Meanwhile, use filter and express any complex conditions in SPARQL.
Q8: Have you or would you be interested in standardizing your set of GraphQL extensions?
The GraphQL support is very new and we will monitor how the user community will react to it, and will likely go through a couple of iterations before it gets feature-complete. If the design patterns turn out to be widely used, I expect that other vendors and implementations may follow the same, or similar, extensions. We do not have plans to take this to something like W3C at this stage, as this would be a very lengthy process and the GraphQL base standard is not under W3C control.
Q9: You showed mostly syntactical aspects. What is the semantically difference between RDFs/OWL and GraphQL in respect to formal expressions, e.g. in respect to inference, FOL/DL?
GraphQL is not in any way an inferencing or logic language. It is an API query language. Client applications use it to specify JSON structures they need to get. GraphQL schemas are also JSON structures. It is a very traditional schema language.
Q10: Are you doing anything or have plans to surface JSON-LD via your GraphQL functionality?
We could add a @context element in the response if there is customer demand for it. If someone needs this, we’d like to hear about use cases, e.g. on the TopBraid-users mailing list.
Q11: Is there a way to express equivalence like OWL equivalent property?
GraphQL is not an inferencing language. It lets you specify JSON structures you want to get from the server. TopBraid EDG can take a GraphQL schema and translate it to SHACL. You can then extend the result with SHACL Rules or even OWL axioms.
Q12: In GraphQL are we still able to construct knowledge graphs and not only Trees?
GraphQL returns nested JSON objects generated from the RDF/knowledge graphs. When GraphQL is used in TopBraid to modify or create data, data is stored in RDF i.e., knowledge graphs with graph relationships. View example
Q13: Using TBC-ME do you only have to write the SHACL and it generates the GraphQL schema?
Yes, enhanced GraphQL schemas are auto-generated from SHACL Shapes. Further, if you already have GraphQL Schema it can be used to generate SHACL which then produces enriched GraphQL Schemas.
Q14: Is the conversion to Graph QL done through the import-export wizard? in TBCME?
No. There is GraphQL endpoint for query that works over RDF data (instances). No conversion is necessary. Data remains in RDF. To provide access to it via GraphQL, TopBraid will generate enhanced GraphQL schemas from SHACL Shapes. This all happens transparently and dynamically, users do not need to do anything other than provide some minimal annotations for the generator. See explanation
But if your question is how to convert your existing GraphQL schemas to SHACL, then yes. There is a new Import option in TBC ME that can get a GraphQL Schema from a URL.
Q15: In respect to other graph database products, how compatible remains TopBraid with GraphQL (e.g. Virtuoso, Allegro Graph, etc.?
TopBraid provides standard SPARQL 1.1 support. This should be compatible across all vendor products. We are using SPARQL extensively and have no plans to discontinue or diminish its support.
In practice, however, every product offers their own set of extensions (stored functions and other pre-builds) that can be used in SPARQL queries or together with SPARQL queries. Extensions are there in response to users’ requirements – to provide value-add, convenience and productivity gains. These extensions are unique to each product. Depending on a particular need, vanilla SPARQL 1.1 may be sufficient for you – or it may not. In the latter case, user has a choice to use vendor-specific functionality or to stay with vanilla SPARQL and write a possibly significant amount of code of their own to supplement it.
Returning to GraphQL, our GraphQL syntax is standard meaning that you can use standard GraphQL parsers and other GraphQL tools. GraphQL offers standard syntax designed for extensions. While the extension syntax is standard, other GraphQL engines would likely not understand or support our extensions and vice versa. Further, we are not aware of any GraphQL support in Virtuoso or AllegroGraph. Nor, for that matter, are we aware of SHACL support in these products.
Q16: Is EDG support for GraphQL in place or planned? How soon?
It is available now in 6.0 Beta
Q17: Round trip conversion will be very useful for data processing pipelines. When do you estimate a stable production release of 6.0?
Depends on the feedback we get from the beta testers. The plan is to have it released in about 4 weeks – by the end of July 2018.