search

glaciers-in-archives / snowman

A static site generator for SPARQL backends.
GNU Lesser General Public License v3.0
112 stars 11 forks source link

Support more than one parameter for the query function #55

Closed despens closed 1 year ago

despens commented 1 year ago

It would be nice to support more than one parameter for queries. This would support for many common use cases, such as querying for start and end dates, simulating facet search, etc.

Abbe98 commented 1 year ago

It would be interesting to hear more about such use cases and see examples!

One thing to consider would be if one goes down the route of ordered parameters or tries to make a interface supporting named parameters.

despens commented 1 year ago

From my own work I would want to create overviews of different types of items in different time frames. For instance, artworks from 2009 to 2014, or exhibitions from 2009 to 2014. For a performance that has a beginning and an end, starting 2008 and ending 2012 for instance, I would want to query for other items that happened in the same timeframe.

I guess positioned parameters would be enough; if it was easy enough to create dictionaries, it might even be fine to keep the single parameter option.

Abbe98 commented 1 year ago

I guess positioned parameters would be enough; if it was easy enough to create dictionaries, it might even be fine to keep the single parameter option.

Yeah I think ordered parameters would at least be step one, named ones would likely not be backwards compatible and require a new function.

Abbe98 commented 1 year ago

Ordered parameters have been implemented on the main branch! Each parameter will replace one instance of {.}.