Re: RDF-star profile "functional opaque” [Was: Re: The way forward]

On 2 May 2024, at 15:16, Franconi Enrico <franconi@inf.unibz.it> wrote:

Le 02/05/2024 à 14:58, Franconi Enrico a écrit :
Hi Antoine,
I’m perfectly aware of this issue, which has been discussed at length in the past: does such canonical mapping exist?
Clearly, there should be a solution which makes everybody happy.
My current intuition so far is to (a) make it concrete-syntax-dependent, and (b) make bnodes input syntax matter.
This means that, according to my intuitive definition, the literalisation of two occurrences of <<([] <p> <o>)>> in distinct turtle graphs would be the same.
Of course the literalisation of <<([] <p> <o>)>> would be different from the literalisation of <<(_:a <p> <o>)>>.
And the literalisation of <<(_:a <p> <o>)>> would be different from the literalisation of <<(_:b <p> <o>)>>.
I disagree with your argument:
  If there are 2 separate files that each contains the following
  triple: << [] :p :o >> :x :y . Then it is not the case that the
  graph represented by the first file entails the one represented by
  the second file, because, a priori, the blank nodes in these two
  graphs are distinct. This is very counter intuitive.
If we take seriously the fact that /_only the syntax matters in the “opaque” semantics_/, then the syntax of those blank nodes is the same, and therefore their respective literalisation would be the same.
Wouldn’t it be a sound fix?

This would fix the problem at a technical level, but it would create issues at the user's level. People who are used to the Turtle syntax and how it deals with bnodes would have a hard time understanding and getting used to the fact that bnode IDs inside triple terms work differently from bnode IDs outside.

But this is exactly the point! Opaque triple terms are opaque, and for them only their syntactic expression matters. Obviously, this is completely different from how classical triples are interpreted.
I understand why this sounds strange for bnodes, whose syntactic form most of the time does not matter in RDF: it matters only to distinguish semantically different bnodes.
But here we want the semantics to matter.

I meant: here we want the syntax to matter.
—e.