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

Support a demonstration of prefiltering of variables #4

Open
phochste opened this issue Feb 14, 2024 · 4 comments
Open

Support a demonstration of prefiltering of variables #4

phochste opened this issue Feb 14, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@phochste
Copy link
Collaborator

In the current solution it is possible to add a derived:template:

  derived:template "demo3/{var1}/{var2}";

But this provides an unlimited variation of variables that could in principle be injected into a the SPARQL query of the filter. An example could be provided (or an abstraction) how these variables first get validated, or even mapped into the the actual variables that get used by the SPARQL query.

E.g. I want to state that if a user sends name on the URL, it should be mapped to a foaf:name variable. And if the user sends as second variable 2 it should be mapped to "2"^^xsd:integer.

@phochste phochste added the enhancement New feature or request label Feb 14, 2024
@joachimvh
Copy link
Collaborator

How would you see those restrictions being defined? E.g, in your examples both of these would have to be interpreted as literals. You might even want to have a stronger restriction that the second one has to be a number. In the case of other variables you could demand a uri, prefixed or full, etc. These restrictions would either have to be defined in the metadata that generates the derived resource, or in the filter body itself. Feel free to suggest how you see it.

@phochste
Copy link
Collaborator Author

I wasn't clear in my remarks. It would be great to have an abstraction added to the code base that can be used to map variables that are written by some external actor on an URL to variables that are internally injected into the SPARQL.

E.g. an VariableMapper interface:

interface VariableMapper {
    /* Can throw a BadVariable error or something */
    map(variables: String[]) : Promise<String[]>;
}

An IdentityVariableMapper could be the current case: every variable that is written on the URL is verbatim used in the SPAQRL. But, more elaborate mappers could be imagined:

  • filtering out bad input .. only allow specific variables etc).
  • for a specific usecase E.g. a Pod could support to use derived resources URLs like:

@joachimvh
Copy link
Collaborator

I would think that you probably still want to define somewhere which mapper should be used for which variable? Assume you have a query with 2 variables in it, one that expects a URI as input, and another one that expects a literal, the server would need to know which mapper to use for which variable. Otherwise you would have to create a custom mapper for every query (and then still somehow link that query to the mapper, unless you only allow 1 type of query per server).

@phochste
Copy link
Collaborator Author

Maybe. I could also imagine that if it is known that http://pod.me/derived/blogposts/ a derived view is, than that the rest of the path could be parsed by a single mapper that could spawn as many specific mappers as it likes for each part.

A simple abstraction what to do with the physics/highenergy part could be a first step to make more elaborate solutions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants