Recursive definition of triple pattern and property path pattern

[hartig]

Closes #334

The new definition of triple pattern in this PR permits nesting of triple patterns in both the subject and the object position. There is a new Note that explains why a triple pattern may have another triple pattern in its subject position.

---

Preview | Diff

[Tpt]

[maybe bad idea] Could we rewrite this first case by allowing s and o to be also triple patterns and remove the need for the other cases?

Suggested change

	<ul style="list-style-type: none;">
	<li>|s| is an <a data-cite="RDF12-CONCEPTS#dfn-rdf-terms">RDF term</a>
	or a <a href="#defn_QueryVariable">variable</a>,</li>
	<li>|p| is an <a data-cite="RDF12-CONCEPTS#dfn-iri">IRI</a>
	or a <a href="#defn_QueryVariable">variable</a>, and</li>
	<li>|o| is an <a data-cite="RDF12-CONCEPTS#dfn-rdf-terms">RDF term</a>
	or a <a href="#defn_QueryVariable">variable</a>,</li>
	</ul>
	then (|s|, |p|, |o|) is a triple pattern.</li>
	<ul style="list-style-type: none;">
	<li>|s| is an <a data-cite="RDF12-CONCEPTS#dfn-rdf-terms">RDF term</a>,
	or a <a href="#defn_QueryVariable">variable</a>,
	or a <li>|s| is a triple pattern,</li>
	<li>|p| is an <a data-cite="RDF12-CONCEPTS#dfn-iri">IRI</a>
	or a <a href="#defn_QueryVariable">variable</a>, and</li>
	<li>|o| is an <a data-cite="RDF12-CONCEPTS#dfn-rdf-terms">RDF term</a>
	or a <a href="#defn_QueryVariable">variable</a>,
	or a <li>|o| is a triple pattern,</li>
	</ul>
	then (|s|, |p|, |o|) is a triple pattern.</li>
	</ul>

[hartig]

[maybe bad idea] Could we rewrite this first case by allowing s and o to be also triple patterns and remove the need for the other cases?

No, that's not how recursive/inductive definitions work. While the recursion cases may use (cases 2-4 here) may build on the concept being defined (i.e., here, the notion of a triple pattern), the base case(s) may only build on concepts that have been defined before.

[afs]

No, that's not how recursive/inductive definitions work.

The rules are recursive (build on the concept) - that is a separate issue. It already says "is defined inductively as follows:" so it is by-construction. A thing does not exist until it is the output of "then"; rules 2-4 already rely on this.

There are already multiple cases rolled up into a each if-then; it's in the use of "or".
We can use the fact that writing "or" means that a if-then applies in more than one situation.

If A then X
If B then X

is the same as (if A and B are unconnected)

If A or B then X  

Neither A nor Bcan refer toX` means no cycles

It can be stressed it's an XOR by "s is one of an RDF Term, a variable, or a triple pattern" (or use "or" twice as suggested above).

For clarity, to be like RDF Concepts, we might a base step and one other step together (2-4) but it could be one if-then because the fundamental starting point is RDF Terms and the concept of 3-tuple.

DAGs are possible (but harmless) treating equality of triple patterns as structural equality, by constructing a shared element twice. Same as (1,2,3) equals (1,2,3) - tuples by structural equality, not instance equality.

It would be worth a declarative statement (inside the definition box) of "triple patterns do not permit cycles"

[Tpt]

+1 to @afs. I think my writing does not remove the existence of a base case.

Anyway, it's just a nit, I don't care much and just found the definition a bit verbose. Feel free to keep the current definition and ignore this discussion.

For clarity, to be like RDF Concepts, we might a base step and one other step together (2-4) but it could be one if-then because the fundamental starting point is RDF Terms and the concept of 3-tuple.

Sounds like a great idea!

It would be worth a declarative statement (inside the definition box) "triple patterns only permit trees structures" or "triple patterns do not permit sharing a common sub-element.

Nit: if I am not mistaken, this is opening the pandora box of "triple pattern equality/identity?". I would just consider triple patterns as syntactic constructions and assume reuse is not possible.

[afs]

Nit: if I am not mistaken, this is opening the pandora box of "triple pattern equality/identity?".

Oh yes! See revised text in my comment 😄 -- edited about the time of your comment after I realised the equality/identity issues for tuples.

[hartig]

@afs @Tpt commit e0f2c56 removes the different cases from the definition.

[afs]

This gets entangled with it coming from the syntax because from parsing, say, an inverse property path, it is a property path, and that gets translated to a triple pattern later.

The fundamental reason is, like literals-as-subjects (SPARQL 1.0), it arises in entailment.
AKA it is just easier that way! Sometimes things are what are.

So my suggestion is to state the fact and not justify it specially.

"A triple pattern that has another triple pattern in its subject position will fail to match on any RDF graph ..."

[afs]

Approved - one suggestion to add a link.

[hartig]

@pchampin This PR is the one I mentioned in the call yesterday, adopting the definition of property path pattern to include triple patterns as possible subject or object.