-
Notifications
You must be signed in to change notification settings - Fork 12
Engine and Configuration
Among the various query engine prototypes that populate the RSP state of the art, it is common to provide
a RSPEngine
abstraction to the language users. Similarly to traditional database technologies, the RSPEngine
acts as a client, mediating the interaction with actual execution engine.
Since differente engines have different interaction patters, RSP4J adopts a very generic and flexible approach based on the feature definition of VoCaLS and inspired by a simplified vision of semantic web services.
A Feature
is an interface with only one method. In practice, an RSPEngine can implement any number of Feature
to describe
its behavior in details. In principles, developers could use such interfaces to automatically generate semantic engine descriptions
such as those defined in VoCaLS.
Here we present two examples, i.e., Stream and Query Registratio Features.
public interface StreamRegistrationFeature<S1 extends WebDataStream, S2 extends WebStream> {
S1 register(S2 s);
}
The StreamRegistrationFeature
defines how the engine interacts with the input streams. in RSP4J, a WebDataStream
represents a connection to the WebStream endpoint (cf Defining the Streams). The engine must have a memory reference to the WebDataStream object, in order to rout the data to the query execution runtime.
public interface QueryRegistrationFeature<Q extends ContinuousQuery> {
ContinuousQueryExecution register(Q q);
}
The StreamRegistrationFeature
defines how the engine interacts with the input query. in RSP4J, a ContinuousQuery
represents an RSP-QL-compliant instance of a continuous query. Howver, RSP4J decouple the query instantiation for the parsing, allowing its users to extend the syntax and the semantics with new operators. Nevertheless, the engine must have a memory reference to the ContinuousQuery object, in order to rout the data to the execution runtime.
YASPER's CSPARQL and CQELS engine implementations have such features above, i.e.,CQELS
public class CQELSmpl implements QueryRegistrationFeature, StreamRegistrationFeature<RDFStream, RDFStream> {
[...]
@Override
public ContinuousQueryExecution register(ContinuousQuery q) {
return new ContinuousQueryExecutionFactoryImpl(q, registeredStreams, report, report_grain, tick, t0).build();
}
@Override
public RDFStream register(RDFStream s) {
registeredStreams.put(s.uri(), s);
return s;
}
}
}
While writing an RSP application, you might want to configure your RSP engine.
EngineConfiguration ec = EngineConfiguration.loadConfig("/default.properties");
Custom properties can be passed to the EngineConfiguration in the form key=value In the following, we list some existing configuration values that we identified studying existing engines.
rsp_engine.query_class=it.polimi.deib.sr.rsp.api.querying.ContinuousQuery
rsp_engine.tbox_location=""
rsp_engine.sds.mantainance=NAIVE
rsp_engine.query.recursion=false
rsp_engine.reasoning=true
rsp_engine.reasoning.entailment=None
rsp_engine.time=EventTime
rsp_engine.partialwindow=true
rsp_engine.response_format=TTL
- rsp_engine.query_class indicates the class to use for parsing, allowing custom parsing and syntax extensions
- tbox_location allows specifying a engine-wide background knowledge
- sds.maintenace NAIVE, INCREMENTAL allows configuring the SDS content maintance at engine level
- partial-window enable/disable querying partial windows as explained by Tommasini et Della Valle
- query.recursion enable/disable the consumption of the outputstream in a query
- reasoning enable/disable the use of reasoning (we plan to refactor this according with Graph-Level/Window-Level/Stream-Level)
- entailment specify which entailment to use of reasoning (RDFS,OWL2QL...)
- time specify what timestamp to use when processing, event-time requires to specify a timestamp extractor
- response_format globally sets the format of the output stream
EngineConfiguration ec = EngineConfiguration.loadConfig("/csparql.properties");
Yasper sr = new Yasper(ec);