Would compliance require support for arbitrary recursion in a triple-term?

[sdasoracle]

For compliance, would an implementation be required to accept the following N-Triple statement as a line in a .nt file?

:s :p <<( :r1 rdf:reifies <<( :r2 rdf:reifies <<( :r3 rdf:reifies ... <<( :rn rdf:reifies <<( :x :q :y )>> )>> ... )>> )>> )>> . [EOL]

If we decide (see this issue) to allow any arbitrary IRI to appear as predicate in a triple that has a triple-term as object, then we should consider the following as a more general example:

:s :p <<( :r1 :p1 <<( :r2 :p2 <<( :r3 :p3 ... <<( :rn :pn <<( :x :q :y )>> )>> ... )>> )>> )>> . [EOL]

[pchampin]

I'm assuming that by "uncountably infinite", you actually mean "unbounded": in my reading of the definition, every triple term has a finite depth, but this depth can be (in theory) as large as desired (hence "unbounded").

In my opinion, your question is similar to asking:

• would an implementation be required to accept IRIs / Literals of arbitrary length?
• would an implementation of Turtle be required to accept nested blankNodePropertyLists of arbitrary depth?

I'm pretty sure that no implementation meets these requirements, if only because of memory limits. And even an implementation imposing arbitrary limits on those things would not strike me as non-compliant... as long as the limits are "reasonable", of course.

So the answer to your question would be "it depends", as everyone's definition of "reasonable" may vary depending or their use-cases. Given that we expect most people to use the syntactic sugar rather than raw triple terms, a max-depth of 1 for triple terms seems reasonable enough for me.

[afs]

Given that we expect most people to use the syntactic sugar rather than raw triple terms, a max-depth of 1 for triple terms seems reasonable enough for me.

Question for clarification: are you proposing that there is a spec defined maximum depth?
Or an implementation decision to only work with a certain maximum depth?

[pfps]

This is the same issue as whether RDF graphs of arbitrary size must be accepted and the same as for any syntax that allows entire inputs or portions thereof of arbitrary size. (Well, not quite, as it is possible to do some processing of RDF 1.1 graphs of arbitrary size with only a constant extra amount of storage. With triple terms some of this processing might require extra storage that depends on the depth of nesting.)

[sdasoracle]

Ideally I'd like to claim some form of compliance even with no support for nesting of triple terms, i.e., supporting only up to depth=1 (in the following expression: 2 + depth*2 + 1) to limit the number of terms in an RDF triple to at most 5. That would allow only the following two forms of triples: :s :p :o (as in RDF 1.1) and :r rdf:reifies <<( :s :p :o )>> .

Given that we expect most people to use the syntactic sugar rather than raw triple terms, a max-depth of 1 for triple terms seems reasonable enough for me.

So, by "max-depth of 1 for triple-terms", do you mean allowing regular 3-term triples and 5-term triples only? Or, do you mean allowing 7-term triples of the form :r rdf:reifies <<( :r1 rdf:reifies <<( :s :p :o )>> )>> as well?

[sdasoracle]

Here is a possible way of avoiding nested triple terms. Uses a new property, rdf:tripleTerm whose range is restricted to set of all (non-nested) triple terms.

# no-nesting
:r :p <<( :x :q :y )>> .

# 1-level nesting: :r :p <<( :r1 :p1 <<( :x :q :y )>> )>> .
:r :p <<( :r1 :p1 _:b1 )>> .
_:b1 rdf:tripleTerm <<( :x :q :y )>> .

# 2-level nesting: :r :p <<( :r1 :p1 <<( :r2 :p2 <<( :x :q :y )>> )>> )>> .
:r :p <<( :r1 :p1 _:b1 )>> .
_:b1 rdf:tripleTerm <<( :r2 :p2 _:b2 )>> .
_:b2 rdf:tripleTerm <<( :x :q :y )>> .

[franconi]

As I mentioned during the discussion at the TF, in order to preserve the semantics your rdf:TripleTerm predicate should be owl:sameAs. As a matter of fact, you are mimicking the RE semantic injective mapping, but as a many-to-many relation.

[sdasoracle]

rdf:TripleTerm predicate should be owl:sameAs

Yes, but I wanted to avoid the baggage that comes with owl:sameAs. So, rdf:tripleTerm, a single-valued property (a owlLFunctionalProperty), is restricted to only have triple term as value.

[franconi]

I don't understand. If you want to use an OWL property, it would be better to use the right one :-)
Indeed, even if rdf:TripleTerm is declared as a owl:FunctionalProperty, this would not be enough to capture correctly the semantics of rdf:reifies with nested triple terms.
Moreover, simple entailments and SPARQL BGP matching queries may give an incorrect answer wrt the semantics as defined in the spec.
So, I guess that it would be fine if you want to do it by yourself, but I believe that your suggestion can not be written in the spec...

[sdasoracle]

If you want to use an OWL property

I want to use an RDF property rdf:tripleTerm. (I am not sure what an OWL property is.)

All I care about this (RDF) property is that 1) if an RDF triple uses this property as predicate, it can only have (non-nested) triple term as object, and 2) it is single-valued (in a closed world sense).

My principal motivation is that use of this approach (in N-Triple) will limit the max number of terms in an N-Triple record, going from 3 in RDF1.1, to just 3 + 2 in RDF1.2, as opposed to 3 + 2 + 2*n where n can be arbitrarily large.

[franconi]

By declaring rdf:tripleTerm to be single-valued, you use an OWL property, which can not be dealt correctly by RDF engines.
Your motivation is clear, but your solution can not be part of RDF or RDFS.

[sdasoracle]

Ok, then as we did for rdf:reifies, let us assume that rdf:tripleTerm too is multi-valued (i.e., allows many-to-many relationships). How would that fit into RDF and RDFS?

In order to support associating reifiers to RDF triples while maintaining its 3-element structure, we went from simple (ground) terms in RDF1.1 to the idea of triple terms (for use in the object position). This was already a big leap in complexity. Now we are trying to make it even more complex by allowing such triple terms to have nesting.

I am just trying to see if we can avoid further complicating the core elements used in RDF triples and, still, get the same expressive power.

[franconi]

You can have a rdf:tripleTerm many-to-many property, and this would fit well within RDF/RDFS.
But, again, your proposed encoding of nested triple terms with rdf:tripleTerm would not be faithful wrt the semantics of triple terms, so I do not see how can we have it in the spec.

[sdasoracle]

rdf:tripleTerm would not be faithful wrt the semantics of triple terms

Could you please elaborate exactly how? If there is a way to avoid the leap to nesting of (the already complex and new concept of) triple term, it may be worth trying to tweak things a bit to address those issues.

[doerthe]

@sdasoracle One problem I see with your current proposal (if I understand it correctly) is that you introduce equality to RDF with your rdf:tripleTerm and the semantics as you proposed it. So, let's assume that we have:

_:b1 rdf:tripleTerm <<( :x :q :y )>> ,<<( :x1 :q :y )>>.

Now, let's additionally assume that we have our current semantics and that rdf:tripleTerm is a functional property (in the owl sense even though we won't state it, only make the semantics accordingly). Then, we would get as a consequence that :x and :x1 map to the same resource (they are equal in the owl:sameAs sense, this has to do with the fact that RE is injective).

We have the same problem if we'd say that rdf:tripleTerm has the same meaning as owl:sameAs.

So, the proposal as it is does not "fit" into the semantics as we have it. We could weaken our current semantics or we could try to get weaker semantics for rdf:tripleTerm with the consequence that the translation as you want it (nested<->unnested) would not happen automatically.

[franconi]

We could weaken our current semantics

no way! 😊

or we could try to get weaker semantics for rdf:tripleTerm with the consequence that the translation as you want it (nested<->unnested) would not happen automatically.

This option does not need to be standardised, since the proposed rdf:tripleTerm would have no special semantics. Anybody could introduce her personal URI to pretend to un-nest nested triple terms in this lossy way.

It is important to emphasise that this encoding does not have the same properties as standard reification of nested triple terms with rdf:reifies.

Moreover, I don't see why we should introduce an incorrect shortcut, while the language provides the correct way to do it.