Re: C-SPARQL interest and questions

Dear Mark,

I try to answer inline.


On 09 Oct 2014, at 23:23, Mark Feblowitz <MarkFeblowitz@comcast.net<mailto:MarkFeblowitz@comcast.net>> wrote:

I will send in comments on the items not working or not documented. Is there a recent language reference that is consistent with the engine’s implementation? That would be quite helpful.

No. The best material we have is the RSP tutorial: http://streamreasoning.org/rsp2014
More about the naive reasoning and the background knowledge support will appear in http://www.streamreasoning.org/events/sr4ld2014

Generally speaking you should be able to register any SPARQL 1.1 query.

Are the more recent builds as stable as the May 2014 release? If so, I will happily pick up that latest stable build.

As I said, we are working on it.

As for the exception trace below. I was trying to use these FROM elements in my continuous queries:

REGISTER ...
PREFIX …
CONSTRUCT { … }
FROM STREAM <http://km.sp.ibm.com/cqeStream>  [ RANGE 30m STEP 15s ]
FROM <http://localhost:3031/km4sp/sparqlc>
WHERE {
 { SELECT ?G
...
 }
GROUP BY ?G
HAVING (  COUNT (DISTINCT  ?L ) > 5
}

The FROM <uri> is a Fuseki endpoint that I am hoping to use for C-SPARQL querying of “at-rest" triples.

the FROM clause, specify the RDF dataset as in SPARQL, but it does not support NAMED clause. If http://localhost:3031/km4sp/sparqlc returns an RDF, then the query should work.

What does ?g match? Can you send the full query with some example of data?

The exception mentions update, but that’s not what the engine is trying to do (I don’t think). When I use a file URI, the query functions as expected.

Is there something about Fuseki’s service that makes it incompatible with the May 2014 Engine and SPARQL server access?

May be.


Might it be fixed in a more recent build? Or am I pointing the engine at the wrong type of service?

<#service1>  rdf:type fuseki:Service ;
    fuseki:name             "km4sp" ;
    fuseki:serviceQuery "sparql" ;
    fuseki:serviceConstruct   "sparqlc" ;
    fuseki:serviceUpdate     "update" ;
    fuseki:serviceUpload     "upload" ;
    fuseki:dataset           <#dataset> ;

I’ve tried pointing it at the Query service (“sparql”), the Update service (“update”), and the Construct service ("sparqlc”), all with the same outcome. I’ve also tried an IP address rather than “localhost”

I’m not familiar with fuseki:serviceConstruct. Does it return the entire content of the repository in XML-RDF format? As far as I know this is the only way you can get Jena ARQ (used internally to the C-SPARQL Engine) to load a remote graph using the FROM clause.

The new version of the engine will come with an in-memory dataset where you can store and update the background knowledge. I recommend you to try this new feature. The hands on session of http://www.streamreasoning.org/events/sr4ld2014 will include an example of how to use this feature.


As for the duplicate result issue, it appears that, in the example above, each time the window closes (every 15s) , the engine appears to find the criteria in the window to identify  N > 5 distinct ?L for the group ?G and emits the CONSTRUCT clause, until such time as the  N becomes less than 5 (the slide eventually eliminates enough ?L’s). I’m not sure whether that’s the desired behavior. It may be that there are no windowing criteria that would call for the match to happen only once.

I still do not fully get the point. Probably I need to see the entire query to understand.

What I’m thinking of doing is either removing duplicate emitted “CONSTRUCT” clauses or amending my query criteria to allow for only a single match.

As I write this, though, it does seem like a streaming/windowing FAQ that, as I learn more about this particular form of windowed aggregation I will learn how to address. And I’m just learning how C-SPARQL handles its “ejection criteria" (what gets ejected from the window) and its “processing criteria” (which I now understand to be “window closing” criteria, in your words). IBM Streams and, I imagine, Esper, have different handling of each.

Indeed.

Best Regards,

Emanuele