Open phochste opened 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.
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:
physics
and highenergy
are mapped into something that SPARQL could useI 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).
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.
In the current solution it is possible to add a
derived:template
: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 afoaf:name
variable. And if the user sends as second variable2
it should be mapped to"2"^^xsd:integer
.