Simple SPARQL-star query fails

[pulquero]

Current Behavior

With an empty MemoryStore, the following returns no results:

SELECT ?t { bind(<< <http://whatever/a> <http://whatever/val> 1 >> as ?t) }

I would have thought this should work in the same way I can bind a constant IRI or literal.

Expected Behavior

t should be returned with the constant triple value << http://whatever/a http://whatever/val 1 >>.

Steps To Reproduce

        Repository repo = new SailRepository(new MemoryStore());
        repo.init();
        RepositoryConnection con = repo.getConnection();
    	String q ="SELECT ?t { bind(<< <http://whatever/a> <http://whatever/val> 1 >> as ?t) }";
        TupleQueryResult res = con.prepareTupleQuery(QueryLanguage.SPARQL, q).evaluate();
        assertTrue(res.hasNext());

Version

3.7.6

Are you interested in contributing a solution yourself?

No response

Anything else?

Query tree is

QueryRoot
   Projection
      ProjectionElemList
         ProjectionElem "t"
      Extension
         TripleRef
            Var (name=_const_1e762b06_uri, value=http://whatever/a, anonymous)
            Var (name=_const_5997dc86_uri, value=http://whatever/val, anonymous)
            Var (name=_const_31_lit_5fc8fb17_0, value="1"^^<http://www.w3.org/2001/XMLSchema#integer>, anonymous)
            Var (name=_anon_93abe671_2aa3_48d8_a0e6_6f2fc4a51c90, anonymous)
         ExtensionElem (t)
            Var (name=_anon_93abe671_2aa3_48d8_a0e6_6f2fc4a51c90, anonymous)

I feel this should really be a ValueExprTripleRef instead of a TripleRef.

This query does work however:

"SELECT (<< <http://whatever/a> <http://whatever/val> 1 >> as ?t) {}

query tree

QueryRoot
   Projection
      ProjectionElemList
         ProjectionElem "t"
      Extension
         SingletonSet
         ExtensionElem (t)
            ValueExprTripleRef
               Var (name=_const_1e762b06_uri, value=http://whatever/a, anonymous)
               Var (name=_const_5997dc86_uri, value=http://whatever/val, anonymous)
               Var (name=_const_31_lit_5fc8fb17_0, value="1"^^<http://www.w3.org/2001/XMLSchema#integer>, anonymous)

[damyan-ognyanov]

The behaviour is correct with respect to the proposed semantics of SPARQL-star. e.g. see https://arxiv.org/pdf/1406.3399.pdf section 5.2.5

hth,
Damyan

[damyan-ognyanov]

Indeed, it may be obsolete, but that is the document(or a version of it, from around the begining of 2020) on which the current implementation is based on, including the semantincs of BIND, discused in this thread.

[pulquero]

OK, I get it now (I think), thanks. So, in essence, the issue revolves around how to interpret BIND(<<?s ?p ?o>> as ?t), i.e. triple with some non constant components. The old version says you bind values by searching in the graph, and I think this aligns with the PG evaluation mode where a triple* pattern infers the existence of any embedded triples, and is concerned with being compatible with reification where the embedded triple would of course exist as a triple in the graph. I have an SA mindset where BIND(<<?s ?p ?o>> as ?t) is in error if any of ?s, ?p, ?o are unbound - <<?s ?p ?o>> acts like a function. In the new spec, it seems it tries to avoid all these issues by simply having BIND() not support triples and having an explicit TRIPLE() function.

Is this about right?

[pulquero]

Further, I assume "Extensible Value Testing" means BIND(<< http://whatever/a http://whatever/val 1 >> as ?t) in the new spec could still behave like the old spec.

[afs]

That's the idea - it is SA, there is a new RDF term for a quoted triple. The rest follows.

by simply having BIND() not support triples and having an explicit TRIPLE() function.

as in "not support triple matching".

The difference between <<... >> as an expression for a quoted triple, and the function TRIPLE is that TRIPLE allows any expression whereas <<>> only permits an RDF term or a variable in each position. e.g TRIPLE(IRI(?str), :p, ?x+1).

https://www.w3.org/2021/12/rdf-star.html#quoted-triple-expression

[abrokenjester]

@jeenbroekstra do you know where we stand on our implementation of the final community group report specification for SPARQL-star?

Like @damyan-ognyanov mentioned, the current implementation is based on an earlier version, and I believe we have not really done much futher work on this since then - with myself changing jobs and the Ontotext team (who contributed most of the original implementation) shifting focus to other things.