SolidLabResearch / derived-resources-component

Adds support for derived resources
MIT License
4 stars 0 forks source link

Support a demonstration of prefiltering of variables #4

Open phochste opened 6 months ago

phochste commented 6 months ago

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.

joachimvh commented 6 months ago

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 commented 6 months ago

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:

joachimvh commented 6 months ago

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 commented 6 months ago

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.