Undeterministic roundtripping between Turtle-star annotations syntax and N-triples

[rat10]

Turtle-star provides two idioms to facilitate statement annotations with triple terms: the annotation syntax and reified triples. The following example uses both syntaxes to express that we know for a fact that Alice likes swimming in the ocean during summertime, but we don't know, or even doubt, that she likes swimming indoor in winter.

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .
<< :Alice :likes :Swimming >> :during :Winter ; :at :IndoorPublicPool .

To save these statements in an RDF triple store they need to be converted to N-Triples:

:Alice :likes :Swimming .
_:r1 rdf:reifies <<( :Alice :likes :Swimming )>> .
_:r1 :during :Summer .
_:r1 :at :Seaside .
_:r2 rdf:reifies <<( :Alice :likes :Swimming )>> .
_:r2 :during :Winter .
_:r2 :at :IndoorPublicPool .

Converting those triples back to Turtle-star can result in the initial rendering:

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .
<< :Alice :likes :Swimming >> :during :Winter ; :at :IndoorPublicPool .

However it can equally well result in the following renderings:

<< :Alice :likes :Swimming >> :during :Summer ; :at :Seaside .
:Alice :likes :Swimming {| :during :Winter ; :at :IndoorPublicPool |} .

or

:Alice :likes :Swimming .
<< :Alice :likes :Swimming >> :during :Summer ; :at :Seaside .
<< :Alice :likes :Swimming >> :during :Winter ; :at :IndoorPublicPool .

or

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .
:Alice :likes :Swimming {| :during :Winter ; :at :IndoorPublicPool |} .

This degree of variance is problematic.

First of all it's simply confusing that a certain construct can be presented in so many different ways. One may argue that it is not uncommon in RDF to be able to express the same meaning in different ways, but that predominantly concerns variations in modelling style which are grounded in RDF's inherent flexibility. Blank node identifiers are another common cause of variance resulting in some confusion, but that is limited to a certain kind of node. A list expressed with Turtle syntactic sugar looks very different from its representation using strictly triples. However, that only concerns the (necessary) difference between a bare bones triple structure and its syntactic sugar, not the resulting list representation.
This case here is different from all those mentioned: mapping from a specific N-triples construct to its specific counterpart in a surface syntax shouldn't be subject to such variance.

What's more, these different renderings all have the same meaning per the RDF semantics, but they convey very different intuitive meanings to users not expertly trained in RDF. The initial example conveys a clear intuitive reading, as suggested in its introduction and I claim that at least 9 out of 10 users will read it exactly that way - and not the way that the RDF semantics define it. All other mappings convey very different intuitive readings w.r.t. what we know about Alice' swimming preferences: outdoors but not indoors, indoors but not outdoors, indoors and outdoors, or maybe neither. However, the only thing we can actually say for sure according to the RDF semantics is that Alice likes swimming. That makes the whole annotation mechanism brittle and hard to interpret correctly. The provided syntactic sugar suggests otherwise, but those suggestions are only illusions that can't be relied on in production, i.e. when roundtripping between triple store and Turtle serialization.

A surface syntax has to cater to the intuitions that users can be expected to have. RDF already doesn't have the best track record in that respect, but most of the well-known pitfalls e.g. w.r.t. blank node naming or ordering of triples, are at least well substantiated by its integration-focused semantics. Many users find RDF too complicated despite those good reasons, and despite the practical applications for such ambiguity. The case discussed here is not without reason as well: an annotation without entailment powers can't annotate a triple in the graph - it can only ever annotate "such a triple", i.e. a proposition. Everything else, anything more is merely coincidence. The annotation syntax alludes to bridging that gap, but in reality it doesn't, as the following example may illustrate even more vividly:

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .

is expressed in N-triples as

:Alice :likes :Swimming .
_:r1 rdf:reifies <<( :Alice :likes :Swimming )>> .
_:r1 :during :Summer .
_:r1 :at :Seaside .

which can again be mapped to Turtle in very different ways:

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .

or

:Alice :likes :Swimming .
<< :Alice :likes :Swimming >> :during :Summer ; :at :Seaside .

The first mapping tells us that Alice likes swimming in summer at the seaside, whereas the second example may suggest that Alice likes swimming, except in summer at the seaside. The variety of interpretations - and therefore the potential for misunderstanding - that the different mappings are prone to convey is extraordinary even by RDF's standards, and although being well substantiated in the semantics it feels like an oversight.

The initial example is perfectly legal and it conveys a strong intuition, namely that RDF is able to talk about asserted and unasserted statements independently of each other. However, RDF really is only able to talk about unasserted statements as long as they are not also asserted with different annotations, or no annotations at all. This creates a tension that can be resolved by mapping the annotation syntax to a different property as has been proposed with rdfs:states (*). If this tension is not resolved, it creates a huge potential for unpleasant surprises, and the perception that even RDF 1.2's new annotation mechanism with its sleek syntactic sugar is prone to RDF's "typical" complexity.

EDIT:
(*) The proposal of rdfs:states has been discussed at length in issue #128 map the annotation syntax to rdfs:states. That issue has become too long and winded to be useful anymore, and will be closed soon and replaced by a new proposal that is currently being in the works.

[rat10]

@pchampin it doesn't show up on the RDF-star working group dashboard

[niklasl]

What any triple means (as a proposition) depend on the definition of the properties used. All we know is that these variations mean the exact same facts. Here :Alice simply :likes :Swimming. The rest is additional detail in the form of reifiers (of any kind; here I'm guessing some kind of taste or preference).

Remember that the reified triple form is not an indication that the proposition can't be true.

It would be nice if pretty-printers, when possible, use the annotation form for all (known) reifiers of asserted triples (and I expect that, with variations being more about indentation and punctuation). Like:

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |}
                        {| :during :Winter ; :at :IndoorPublicPool |} .

or:

:Alice :likes :Swimming ~ _:r1 ~ _:r2 .
_:r1 :during :Summer ; :at :Seaside .
_:r2 :during :Winter ; :at :IndoorPublicPool .

But that's a feature request per implementation (some have detailed options).

[pchampin]

@pchampin it doesn't show up on the RDF-star working group dashboard

I see it there

https://github.com/orgs/w3c/projects/20/views/1?filterQuery=undeterministic

[rat10]

@pchampin it doesn't show up on the RDF-star working group dashboard

I see it there

RDF-star working group dashboard (view)

Oh, sorry, my mistake! I had some filter active in my view.

[pchampin]

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .
<< :Alice :likes :Swimming >> :during :Winter ; :at :IndoorPublicPool .

Alice likes swimming in the ocean during summertime, but we don't know, or even doubt, that she likes swimming indoor in winter.

First, interpreting the << >> brackets as expressing "doubt" or any form of negation is wrong. They are just a mean to talk about a triple without asserting it. But not asserting a triple is not the same thing as negating it or casting doubt about it.

Second, the graph above is not a good modelling for the sentence above. No surprise, then, that this bad modelling produces undesired results. Because RDF is monotonic (and has always been, even before triple terms), by asserting the triple :Alice :likes :swimming, you are stating that, well, Alice likes swimming, without any condition or restriction on time or location. In other words, there is one activity "swimming" that you claim Alice likes. She can not both like it and dislike it. Annotations on this triple do not change that.

In your English sentence, on the other hand, you distinguish two different activities, namely "swimming outdoor during summer", and "swimming indoor during winter". Although they could be argued to be instances of a a more general activity ("swimming"), they have to be modeled as different things as you assume that Alice can like one without liking the other.

It could be modeled like that

:alice :likes [ :activity :Swimming; :when :Summer ; :where :outdoor ].
_:a2 :activity :Swimming; :when :Winter ; :where :indoor .
<< :alice :likes _:a2 >> :likelihood 0.2.

Note that I used an (unasserted) triple term to capture the doubt about the 2nd activity, but it is not the << >> brackets that express the doubt, it is the :likelihood property.

To summarize, I (and others) have argued earlier that intuitions are (by definition) subjective, and they largely vary from one person to another. Claiming (with which evidence?) that 9 persons out of 10 will share this particular intuition is not very compelling.

Furthermore, even if you are right in assuming that people will model your English sentence above with your graph above, then I would consider it a good thing that the rewriting of the graph violates their intuition. They will realize sooner rather than later that there is a problem with their modeling!

To illustrate this last point, consider the sentence "Alice likes swimming outdoor, but she hates swimming indoor." It would be tempting (intuitive?) to model it like that:

:Alice :likes :swimming; :location :outdoor.
:Alice :hates :swimming; :location :indoor.

but of course, it would not round trip, and could come back like this:

:Alice :likes :swimming; :location :indoor.
:Alice :hates :swimming; :location :outdoor.

which makes it obvious that something is wrong with the initial modeling.

[rat10]

What any triple means (as a proposition) depend on the definition of the properties used. All we know is that these variations mean the exact same facts. Here :Alice simply :likes :Swimming. The rest is additional detail in the form of reifiers (of any kind; here I'm guessing some kind of taste or preference).

Remember that the reified triple form is not an indication that the proposition can't be true.

I'm aware. It describes such a triple and in fact makes no assertion whatsoever about it's truth value. However, and that is the core of my issue, the syntactic sugar of Turtle-star gives an impression that evokes a different intuition, a different reading. Imagine a novice user of RDF 1.2, someone coming from web design or LPG and not versed in logic or formal semantics even, and with only a fuzzy understanding of "set semantics": many people, me included, learn from syntactic representations and interpret them in a way that seems obvious to them. Obviously that can't always work out, and at some point the documentation will have to be consulted. But in the case of the annotation syntax and reified triple syntax I fear that misunderstandings will abound.

It would be nice if pretty-printers, when possible, use the annotation form for all (known) reifiers of asserted triples (and I expect that, with variations being more about indentation and punctuation). Like:

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |}
{| :during :Winter ; :at :IndoorPublicPool |} .

or:

:Alice :likes :Swimming ~ _:r1 ~ _:r2 .
_:r1 :during :Summer ; :at :Seaside .
_:r2 :during :Winter ; :at :IndoorPublicPool .

But that's a feature request per implementation (some have detailed options).

That's interesting (but IMO also worrying): which implementations, and what options?

[rat10]

:Alice :likes :Swimming {| :during :Summer ; :at :Seaside |} .
<< :Alice :likes :Swimming >> :during :Winter ; :at :IndoorPublicPool .

Alice likes swimming in the ocean during summertime, but we don't know, or even doubt, that she likes swimming indoor in winter.

First, interpreting the << >> brackets as expressing "doubt" or any form of negation is wrong. They are just a mean to talk about a triple without asserting it. But not asserting a triple is not the same thing as negating it or casting doubt about it.

Describing a triple without asserting it necessarily comes with many possible connotations. It's unavoidable that people will use it with more connotations than it supports by definition. Context, vocabularies, etc will disambiguate that. All that doesn't take away from the basic fact that using a reified term instead of the annotation syntax precisely does not assert the reified triple. And that decision to not use the annotation syntax can be assumed to be an assertion in itself, a conscious decision, not an oversight. However, that decision is lost in translation. Which IMO is really a problem.

Second, the graph above is not a good modelling for the sentence above. No surprise, then, that this bad modelling produces undesired results. Because RDF is monotonic (and has always been, even before triple terms), by asserting the triple :Alice :likes :swimming, you are stating that, well, Alice likes swimming, without any condition or restriction on time or location. In other words, there is one activity "swimming" that you claim Alice likes. She can not both like it and dislike it. Annotations on this triple do not change that.

Qualification doesn't take away from the truth of the unqualified base statement. Qualification only adds detail.

In your English sentence, on the other hand, you distinguish two different activities, namely "swimming outdoor during summer", and "swimming indoor during winter". Although they could be argued to be instances of a a more general activity ("swimming"), they have to be modeled as different things as you assume that Alice can like one without liking the other.

It could be modeled like that

:alice :likes [ :activity :Swimming; :when :Summer ; :where :outdoor ].
_:a2 :activity :Swimming; :when :Winter ; :where :indoor .
<< :alice :likes _:a2 >> :likelihood 0.2.

Note that I used an (unasserted) triple term to capture the doubt about the 2nd activity, but it is not the << >> brackets that express the doubt, it is the :likelihood property.

If we would take that to the extreme then all our basic statements would consist only of blank nodes which we would then further annotate as being instances of type :X, with situation/event specific attributes :A, :B, :C, etc. Many of the proposals and issues that I'm pursuing are concerned with attempts to not go down that rabbit hole but let RDF be a simple language, and yet add expressivity on the side without making it unreadable altogether.

To summarize, I (and others) have argued earlier that intuitions are (by definition) subjective, and they largely vary from one person to another. Claiming (with which evidence?) that 9 persons out of 10 will share this particular intuition is not very compelling.

"9 out of 10" is figurative speech. It would be nice if we could rely on solid empiric data. Yes, I'm very much convinced that my intuition is right in this respect. Intuition, as diverging as it may be, is also more than just flipping a coin. It comes from experience, and I have some from prior lives as architect, designer, etc. And between the lines of counter arguments I often read that they are indeed about different perspectives. When someone argues that the immediate intuitive reading is not a problem because the semantics says otherwise, then I reckon that that argument well understands the semantics but hasn't properly taken into account the power of intuitions. We, as designers of this standard, can be prey to such intuitions - because we might know "too much", i.e. an abundance of nitty gritty details - just the same as the users - which in the beginning inevitably don't know enough. And it is often very hard to let go from initial intuitions when they seem convincing enough. So it's dangerous to lead users into intuitions that then don't hold. Maybe they will not learn that they made a mistake but that RDF is too complicated.

Furthermore, even if you are right in assuming that people will model your English sentence above with your graph above, then I would consider it a good thing that the rewriting of the graph violates their intuition. They will realize sooner rather than later that there is a problem with their modeling!

To illustrate this last point, consider the sentence "Alice likes swimming outdoor, but she hates swimming indoor." It would be tempting (intuitive?) to model it like that:

:Alice :likes :swimming; :location :outdoor.
:Alice :hates :swimming; :location :indoor.

but of course, it would not round trip, and could come back like this:

:Alice :likes :swimming; :location :indoor.
:Alice :hates :swimming; :location :outdoor.

which makes it obvious that something is wrong with the initial modeling.

Different example, because it's missing the disambiguating identifying reifier.

[afs]

But that's a feature request per implementation (some have detailed options).

That's interesting (but IMO also worrying): which implementations, and what options?
IMO also worrying

Why?

Systems have different turtle output for different tradeoffs - speed, scale (esp streaming) , machine-centric vs human-centric layout, personal preferences.

Jena has 4 Turtle writers: pretty-printed/wide,pretty-printed/long, per-subject blocks of triples (streaming, no list syntax, no blank node predicate object lists), one triple per line with prefixes (streaming).

[rat10]

@afs

Systems have different turtle output for different tradeoffs - speed, scale (esp streaming) , machine-centric vs human-centric layout, personal preferences.

Jena has 4 Turtle writers: pretty-printed/wide,pretty-printed/long, per-subject blocks of triples (streaming, no list syntax, no blank node predicate object lists), one triple per line with prefixes (streaming).

What do you envision to offer as options for annotation syntax and reified triples? Have you got requests already for certain specific renderings?

[afs]

Have you got requests already for certain specific renderings?

No.

[afs]

The issue title would more accurately be "Variance in writing Turtle-star annotations across implementations". It can apply writing from a triple store; N-triples is not a factor.

The point is not that it is non-deterministic, and it seems unlikely that a pretty writer would be non-deterministic. (Pretty writers being ones that consider the whole graph before output, whereas streaming writers do not.)

The point is that it is unpredictable across implementations.

There is possible non-determinism elsewhere (and is in RDF 1.1). The largest user visible effects being the order of subjects not reflecting the input order and also the order of subjects changing as data is added (both because of the internal use of hash tables). There is nothing new in RDF 1.2 that changes that.

[gkellogg]

Few concrete syntax documents discuss how to serialize an RDF graph, other than N-Triples and N-Quads for canonical form, and JSON-LD as part of it's transforming the RDF into a JSON-LD representation.

As Andy points out, a pretty printer can only do a best-effort at reconstructing a sensible way of presenting triples using the features of the grammar (which can be quite challenging). I don't think we should try to do any more than the minimum necessary in normatively describing requirements for the serialization of RDF to concrete forms. Of course, this makes the results unpredictable, which has been true as long as there have been multiple implementations of concrete syntax serializers.

There are no requirements on round-tripping RDF serializations, other than parsing the result of serializing should yield the same triples as the input, subject to isomorphism.

[rat10]

There are no requirements on round-tripping RDF serializations, other than parsing the result of serializing should yield the same triples as the input, subject to isomorphism.

I think this really underestimates the evocative force of certain syntaxes. Different handling of white space is in no way comparable to the effects that the initial examples illustrate. Also ordering of triples, while irritating in some cases, is of a much lesser gravity than changing the impression of something being asserted or not. IMO the examples given so far why the annotation and reification syntaxes' potential for confusion is nothing new don't account for the severity of the issue.

That said, my intention with this issue is not to propose a solution but to clarify the problem. A possible solution is the topic of issue #128 - map the annotation syntax to rdfs:states and it's still to be issued follow-up.

[pfps]

There are no requirements on round-tripping RDF serializations, other than parsing the result of serializing should yield the same triples as the input, subject to isomorphism.

I think this really underestimates the evocative force of certain syntaxes. Different handling of white space is in no way comparable to the effects that the initial examples illustrate. Also ordering of triples, while irritating in some cases, is of a much lesser gravity than changing the impression of something being asserted or not. IMO the examples given so far why the annotation and reification syntaxes' potential for confusion is nothing new don't account for the severity of the issue.

What would change "the impression of something being asserted or not" and what would that something be?