You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@mielvds suggested Grasp as a way for the Network of Terms to manage its SPARQL queries. Graph’s use case is different: a single GraphQL query results in a single SPARQL query, whereas in the NoT we have different queries per endpoint.
Still, the idea of using templates to generate SPARQL queries is interesting.
Pros
We can move pre-processing from network-of-terms-api back to the catalog. This results in a better separation of concerns, as the catalog already knows about SPARQL endpoints. The API would no longer supply several query variants. Instead, the catalog calls the query variant functions as template functions.
We can reduce duplication in queries, particularly between lookup and search queries that are usually very similar.
Some operations that are impossible or very complex to express in plain SPARQL can be expressed in the template language.
Cons
Flat .rq files are easy to debug and collaborate on with third parties. Collaborators need to understand the template language and the (TypeScript) functions called from the templates to see what’s going on.
I'm still very much figuring out the roadmap on this thing. It's not because Grasp doesn't support different queries per endpoint right now, that it shouldn't in the near future. As always, the more projects that adopt a generic framework like this one, the stronger it (normally) becomes.
Meemoo will use grasp in production for at least a year and will continue to do so unless our future vendors offers something better. I was also thinking of informing Triply about the existence of grasp; they might be interested to integrate this.
The Grahpql Schemas that you currently use are more elaborate than what I've tested so far (ie. the use of Enums). There might already be some development needed there.
One thing that I already plan is a bootstrapping function: you annotate a graphql schema with the types and properties you'd like to map to, and the templates are generated automatically. These can be extended if more complex constructs are needed.
The templating is simple, but might indeed be
For me, it's already interesting to know what would have to change, even if you don't plan to adopt it.
Interesting idea although it is a bit hard for me to get a clear picture of the end result and the benefits. I am a little concerned that implementing Grasp will have a major impact on the architecture and will introduce more complexity for the catalogue. Because the catalogue is the only part of the NoT were other parties will contribute to on a regular basis, we should avoid to much complexity there. But I might be wrong, I suggest we plan a meeting to discuss this idea and the possibility of a small exploration in this direction.
@mielvds suggested Grasp as a way for the Network of Terms to manage its SPARQL queries. Graph’s use case is different: a single GraphQL query results in a single SPARQL query, whereas in the NoT we have different queries per endpoint.
Still, the idea of using templates to generate SPARQL queries is interesting.
Pros
Cons
@EnnoMeijers What do you think?
The text was updated successfully, but these errors were encountered: