Re: Different encoding for RDF-star queries as S-Expressions with Jena

I’ve updated the develop branch of the sparql gem to use “qtriple”. As noted, there remains some context confusing with the dual uses of the “triple” operator, but “triple” as statement/pattern is always a direct operand of “bgp” (and others noted in the commit message [1]), so it’s fairly limited.

Changing the function form of “triple” to, e.g., “triplef” would actually complicate the grammar parser, as there is otherwise a 1-1 relationship between SPARQL builtins and the operator name.

Compared with Jena, the “triple” operator denoting a pattern as a chlid of “bgp” is required in Ruby RDF. But, as andy notes, it can be figured out by context, making the use of “triple” more semantic sugar, and thus unambiguous with the builtin usage.

Discussion about the semantics of Triple, Embedded Triples, Quoted Triples, and the TRIPLE function are better left to the RDF-star mailing list.

Gregg Kellogg
gregg@greggkellogg.net

[1] https://github.com/ruby-rdf/sparql/commit/ff66501985208edecb4ac7c5f6d6df320adb00d3

> On Jan 23, 2022, at 12:32 PM, Daniel Hernandez <daniel@degu.cl> wrote:
> 
> 
> Andy Seaborne writes:
> 
>> Jena parses and evaluates Daniel's original example - it is using a
>> (triple) as an expression. SPARQL-star TRIPLE.
>> 
>> The two expression are not identical - one has quoted triple term <<>>
>> pattern, the other has an expression that evaluates to a quoted triple
>> -the TRIPLE(expr, expr, expr) function in SPARQL-star.
>> 
>> So there are three cases:
>> 
>> 1 : triple pattern - 3-tuple of RDF-terms/variables.
>> 2 : quoted triple pattern, an RDF term + may have variables
>> 3 : TRIPLE/3 function - arguments are expressions.
>> 
>> triple != quoted triple.  strict typing :-)
> 
> I agree with Andy on that these three cases (depending in the type
> system) are not of the same type.  Andy proposed using two words
> (triple) and (qtriple).  Maybe, it is better to use three words, namely
> (triple) for case 1, (qtriple) for case 2, and (ftriple) for case 3.
> This way context is not needed to interpret which of the three meanings
> described by Andy correspond to the expression.
> 
> I think that the current design of Ruby RDF solves all the requirements
> needed to translate SPARQL queries to S-expressions, and to translate
> S-expressions back to SPARQL.  The only limitation is that it does not
> distinguish between quoted triple patterns and function TRIPLE in
> expressions.  However, this is a minor issue since every SPARQL query
> can be normalized so that expressions do not have quoted triple
> patterns, but function TRIPLE.  The disadvantage of the approach of Ruby
> RDF is that it requires the context to interprete the meaning of the
> word (triple).  This can be solved using different words.
> 
> Below, I write an exercise to describe the differences between the cases
> described by Andy.  To this end, I will to try to use the expression of
> one case into the context of the other case (violating the normative
> grammar) to illustrate that they are not interchangeable because produce
> undesired effects.
> 
> Case 3 is different from cases 1 and 2, because function TRIPLE allows
> for expressions as arguments, and requires the variables in the
> expressions being evaluated before evaluating the expression.  This
> difference is clear because we cannot introduce an expression with
> function TRIPLE in a BGP.  This limitation is not just because the
> grammar does not allows for it, but because it would complicate a
> semantics for such a grammar.  The problem is that it would allow for
> queries with infinite answers.  For instance, consider the query (notice
> that this is an exercise to illustrate the type difference that goes
> beyond the standard grammar and semantics):
> 
> SELECT *
> WHERE { TRIPLE(?s, ?p, ?x + ?y) :certainty 0.5 }
> 
> If the database has a triple
> 
> << :s :p 1.0 >> :certainty 0.5 .
> 
> then this query may (in principle) have infinite answers because there
> are infinite combinations of numbers summing 1.0 to bind variables ?x
> and ?y.  The fact that we cannot use function TRIPLE in the places we
> use quoted triples or triples illustrates the difference between these
> cases.
> 
> The difference between cases 1 and 2 is less clear.  For this excercise
> I use the definition by Olaf in Foundations of RDF* and SPARQL* (AMW
> 2017).  On that work, Olaf extended RDF allowing triples as components
> of triples, as was allowed for terms (see Definition 1 of his paper).
> He made no distinction between quoted triples and triples.  He also
> extended triple patterns allowing triple patterns to occur as components
> of triple patterns (see Definition 2).  The formal definition of
> RDF-star and SPARQL-star shows that there is no need to make a
> distinction between triple and quoted triple.  However, the semantics of
> RDF-star and SPARQL-star introduces a notion that correspond to quoted
> triples.  This semantics is based on a mapping of both languages to
> plain RDF and SPARQL.  In order to do this, it is assumed an injective
> function h that maps each triple t to a blank node h(t).  According to
> this semantics t and h(t) are different values, but the blank node h(t)
> acts as the quoted triple that denotes triple t.
> 
> Daniel