Enrico Daga

I like the idea of using SERVICE clauses to glue existing queries altogether. In the case of SELECT queries this is trivial, I am unsure about how to handle CONSTRUCT...

If it is a SELECT query, then no pattern is allowed inside (I thought this was the intended use of the service clause with provided external query)

Ah! What @luigi-asprino is suggesting is to interpret the SELECT query as tabular data! This is also possible, applying the same FX-based transformation -- but I would leave it as...

Additionally, queries can be parametrised and parameters passed via options: ``` SERVICE { fx:properties fx:query "select-query.sparql" ; fx:param [ fx:var "x" ; fx:value "10"^xsd:int ] ; fx:param [ fx:var "y"...

I see three scenarios: 1 - execute SELECT query and use output ``` PREFIX xyz: PREFIX fx: prefix schema: select distinct ?radioChannelName WHERE { service { fx:properties fx:query.location "/app/aSelect.rq" ....

I think we can leave this issue for any commit related to improvements in the docs

Cool, I would also add a section on resources with links to external material that may be relevant

Another thing to add in the guidelines is that example files need to be published at https://github.com/SPARQL-Anything/sparql-anything.cc-site.git in folder `/root/examples/`

In the last few commits I tried to clean the left side menu

That's an interesting point. I am not sure about how extensive the SPARQL protocol is assumed to be used in SERVICE clauses, apart from the GET/POST query methods. However, the...