FX options via command line (no SERVICE mode)

[enridaga]

There is a point in moving the SA configuration outside the query, and just running a plain SPARQL query on a transformed dataset.

For example:

fx --options location=myFile.csv -q myQuery.sparql

Where myQuery.sparql can be as simple as

CONSTRUCT { ?A ?B ?C } WHERE { ?A ?B ?C }

We may even consider to pu them in a properties file:

fx --properties myFile.properties -q myQuery.sparql

This does not prevent the query to also include SERVICE clauses for additional operations.

[justin2004]

We may even consider to put them in a properties file

I hope the properties file contains triples (basically the triple patterns we already use in queries)!

This may not be what you are talking about here but I am still interested specifying multiple queries. I talked about this here. e.g.

service <x-sparql-anything:query.location=/mnt/first.rq>
service <x-sparql-anything:query.location=/mnt/second.rq>

Where first.rq might be defined by an ontology team and second.rq is your application's query and it operates on the triples constructed by first.rq.

[luigi-asprino]

340d4b5 adds a new option to the CLI. With -c option=value adds to the pair <option,value> to the execution context. This pair is then retrieved by the FxOpExecutor and added to the properties. A new class FxSymbol was introduced to distinguish the Facade-X symbols to the Jena Symbols.

Options passed with -c are used in every SERVICE clause, but if the SERVICE clause can override the option passed -c option

I think we can close this issue now

[enridaga]

Brilliant! I have one question, though: this was about allowing users to run the query without the need for expressing a service clause but I guess this change only allows to pass configuration options from the cli to the service clause.

This is great but I think we should make it clear that this will only work if the service clause is included:

select * where {
  service <x-sparql-anything:>{ ?s ?p ?o}
}

Then:

fx -c location=myfile.csv -c csv.headers=true -q query.rq

[luigi-asprino]

That's true, thank Enrico.

With a5632fc, when the OpBGP is evaluated, the FXOpExecutor also checks for FXSymbols. If FX symbols are present in the context and the No Service clause has been evaluated before, then the executor uses the properties to create the dataset graph and evaluate the bgp over it.

[luigi-asprino]

Everything works except for magic properties which require rethinking the FXOpExecutor.

The magic properties resolve on a different operation (called OpFunc) which may be evaluated before the BGP. When the OpFunc is evaluated the dataset graph (which is the result of the triplifcation of the input) is not already available. Therefore, the evaluation of the operation yields no bindings.

[luigi-asprino]

With 39ae05f execution of the operations OpBGP and OpService is delegated to FXWorkers (i.e. FXWorkerOpBGP and FXWorkerOpService). This favours the reuse of code.

[luigi-asprino]

https://github.com/SPARQL-Anything/sparql.anything/commit/1b7afae459ced45d39580ef84ccd54e9e1071992 introduces a FXWorker for reacting to OpPropFunc. This makes it possible to execute the FX workflow in case of queries like the one below in which the outer operation involves magic properties.

PREFIX fx: <http://sparql.xyz/facade-x/ns/> 
SELECT ?v {  
   ?root a fx:root ;   
          fx:anySlot ?v  . 
}

[luigi-asprino]

As this issue is now complete, we can close it.

[enridaga]

Is this feature documented?

[luigi-asprino]

Yes. As it is enabled via the -c option, we have the description in the CLI help, but maybe we can do a better job. Shall we create a page for each option of the CLI?

[enridaga]

Yes. As it is enabled via the -c option, we have the description in the CLI help, but maybe we can do a better job. Shall we create a page for each option of the CLI?

Yes, that would be great

[luigi-asprino]

Ok... as it is something desirable for all options, maybe better to update the issue #201 instead of reopening this one