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

> On Jan 21, 2022, at 9:38 AM, Andy Seaborne <andy@seaborne.org> wrote:
> 
> 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 :-)

Within Ruby RDF, the representation is equivalent, with the TRIPLE/3 function being just a constructor.

> On 20/01/2022 22:10, Gregg Kellogg wrote:
> > While, Ruby RDF outputs:
> >
> > (prefix ((:<http://bigdata.com <http://bigdata.com/>>)
> >           (foaf:<http://xmlns.com/foaf/0.1/ <http://xmlns.com/foaf/0.1/>>)
> >           (ex:<http://example.org/ <http://example.org/>>))
> >   (project (?age ?c)
> >    (bgp
> >     (triple ?bob foaf:name "Bob")
> >     (triple (triple ?bob foaf:age ?age) ex:certainty ?c))))
> >
> > I’m not sure if this is intentional on Andy’s part, as  `triple << ?bob foaf:age ?age >> ex:certainty ?c)` doesn’t really look like an S-Expression to my eyes,
> 
> "intention" is too strong :-)
> 
> <<>> is another kind of RDF term, like <uri> or "string". I'd happily swap to a ()-form. It's messy and special case to parse.
> 
> There again, parsing <<>> is a bit fiddly. Nested <<>> is allowed.
> 
> Without a separate word, those three uses of (triple) have context sensitive meaning and have to be coded around at each usage site which is not nice.
> 
> A word for quoted triple? (qtriple)?

“qtriple” seems like a good compromise, which should simplify the to_sparql implementation. I’ll give that a shot.

Thanks for your input, Andy.

Gregg

> 
> On 21/01/2022 11:13, Daniel Hernandez wrote:
>> Hi all,
>> Gregg Kellogg writes:
>>> Of course, there is no real standard for expressing queries as
>>> s-expressions, but Ruby RDF generally follows Jena. (Creating a
>>> normative S-Expression representation would be interesting, though).
>> I agree on that a normative for S-Expressions would help for
>> interoperability.
>>> I’m not sure if this is intentional on Andy’s part, as `triple << ?bob
>>> foaf:age ?age >> ex:certainty ?c)` doesn’t really look like an
>>> S-Expression to my eyes, and the “triple” expression has already been
>>> established, but using that embedded triple expression made the most
>>> sense to me. It does lead to some complications in re-serializing, as
>>> SPARQL-star does have a TRIPLE function, which gets the same
>>> representation in Ruby RDF, and distinguishing between their use took
>>> some doing, but internally, it’s never been an issue.
>> Gregg, I agree with you on that the notation <<...>> doesn't look as
>> look as an S-Expression.  Hence, this notation requires implementing an
>> additional type of parenthesis.  Indeed, if S-Expressions allow for the
>> notation <<...>>, then it is also needed to support nested triple
>> expressions, for example << << ?s ?p ?o >> ?q ?r >> ?s ?v.
> 
> Yes. It does.
> 
>>> I wasn’t able to get qparse to parse either form of S-Expression, but
>>> that’s likely an operator error.
> 
> qparse does not parse SSE. It is only an output format.
> 
>> I have tested how Jena parse both forms, and seems that Jena support
>> both forms. It translates << ?s ?p ?o >> as an embedded triple
>> expression << ?s ?p ?o >>, whereas (triple ?s ?p ?o) is translated as
>> the triple function triple(?s, ?p, ?o).
>> Daniel