SPARQL-Star grammar imprecisions

[enizor]

With the proposed SPARQL-Star grammar :

QuotedTP 		::= 	'<<' qtSubjectOrObject Verb qtSubjectOrObject '>>'
QuotedTriple 		::= 	'<<' DataValueTerm ( iri | 'a' ) DataValueTerm '>>'
qtSubjectOrObject 	::= 	Var | BlankNode | iri | RDFLiteral | NumericLiteral | BooleanLiteral | QuotedTP
DataValueTerm 		::= 	iri | RDFLiteral | NumericLiteral | BooleanLiteral | QuotedTriple

the subject of any quoted triple is allowed to be a literal, and the DataValueTerm rule (used for VALUES clauses) prevents the subject/object of the quoted triple to be a blank node.

It seems necessary to create different rules for quoted subjects and object, such as:

QuotedTP 		::= 	'<<' qtSubjectOrObject Verb qtSubjectOrObject '>>'
QuotedTriple 		::= 	'<<' DataValueTerm ( iri | 'a' ) DataValueTerm '>>'
qtSubject 		::= 	Var | BlankNode | iri | QuotedTP
qtObject 		::= 	Var | BlankNode | iri | RDFLiteral | NumericLiteral | BooleanLiteral | QuotedTP
DataValueTermSubject 	::= 	iri | BlankNode | QuotedTriple
DataValueTermObject 	::= 	iri | BlankNode | RDFLiteral | NumericLiteral | BooleanLiteral | QuotedTriple

[afs]

the subject of any quoted triple is allowed to be a literal

Yes - SPARQL allows literals in the subject position. {"foo":q "bar"} is legal syntax and the spec noted it will never match data. It arises naturally in the definition of SPARQL.

(See also "generalized RDF" in RDF 1.1).

prevents the subject/object of the quoted triple to be a blank node.

QuotedTP is "quoted triple pattern" and allows variables and blank nodes that match during BGP matching.
QuotedTriple is a constant term (no variables).

Blank nodes in patterns behave like variables - they match the data. VALUES does not involved matching and so not allow blank node syntax. So in the same way QuotedTriple variables or blank nodes.

[pchampin]

{"foo":q "bar"} is legal syntax and the spec noted it will never match data.

Is it absolutely correct, though? Under some inference regimes, triples with literals as subjects can be inferred. E.g.:

:answer owl:sameAs 42 .

would entail

42 owl:sameAs :answer .

And so

SELECT * { 42 ?p ?o }

should match if that entailment regime was supported, right?

[hartig]

owl:sameAs is defined only for individuals, not for literals (that is, according to the RDF-based semantics of OWL, the rdfs:domain of owl:sameAs is owl:Thing; and a literal is not an owl:Thing). Therefore, writing

:answer owl:sameAs 42 .

should already be inconsistent in itself. No?

[enizor]

My mistake, sorry for the noise.

[afs]

https://www.w3.org/TR/sparql11-query/#sparqlTriplePatterns

The reason literals are allowed in the subject is because special casing matching makes complication for no benefit. Ditto CONSTRUCT.

{ [] :datatypeProperty ?X .
  ?X :q 123
}

and

{
  { [] :datatypeProperty ?X } UNION { [] :objectProperty ?X }
  ?X :q 123
}

[pchampin]

@hartig
(we are getting sidetracked 😉)
Agreed, in OWL 2 Direct Semantics, you can't write that. But in OWL Full, I think you can. And my reading from [1] is that under OWL 2 RL entailment regimes, this inference holds/

[1] https://www.w3.org/TR/sparql11-entailment/#OWL2RLDS

[afs]

"we"?