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

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

Received on Sunday, 23 January 2022 20:32:31 UTC