Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use templates to generate queries #503

Open
ddeboer opened this issue Jan 13, 2022 · 2 comments
Open

Use templates to generate queries #503

ddeboer opened this issue Jan 13, 2022 · 2 comments
Labels
question Further information is requested

Comments

@ddeboer
Copy link
Member

ddeboer commented Jan 13, 2022

@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

  1. 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.
  2. We can reduce duplication in queries, particularly between lookup and search queries that are usually very similar.
  3. Some operations that are impossible or very complex to express in plain SPARQL can be expressed in the template language.

Cons

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

@EnnoMeijers What do you think?

@ddeboer ddeboer added the question Further information is requested label Jan 13, 2022
@mielvds
Copy link

mielvds commented Jan 13, 2022

If I may add to that:

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

@EnnoMeijers
Copy link
Contributor

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.

@ddeboer ddeboer transferred this issue from netwerk-digitaal-erfgoed/network-of-terms-catalog Feb 22, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants