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

Dear all,


I think it this is an interesting discussion and for both sides I see arguments. So, for the blank nodes we could choose:


Option 1: Blank nodes are transparent. Then we would need some grounding function B similar to our A and I would want to force as well that I(B(b))=A(b) for each blank node. But morst likely, this partial transparency is overkill for the use cases we have in mind?


Option 2: Blank nodes are opaque and the blank node name does not matter. Then I would follow Antoine's proposal and check for isomorphisms.


Option 3: Blank nodes are opaque but the interpretation of the triple term takes the concrete blank node name into account. I am not sure I fully understand that option. So far, I dislike it because blank node names are such a volatile thing.



Maybe someone who would like to model property graphs with RDF-star could help us out by explaining his or her expectation from a practical point of view? How should the blank nodes behave?


I am also not sure whether graph terms should actually be interpreted as literals. But maybe that makes it easier to ensure what I would call the "syntactic functional property" we aim for with this approach.


Kind regards,

Dörthe


________________________________
Von: Thompson, Bryan <bryant@amazon.com>
Gesendet: Freitag, 3. Mai 2024 00:39:01
An: Franconi Enrico; Antoine Zimmermann
Cc: public-rdf-star-wg@w3.org
Betreff: Re: RDF-star profile "functional opaque” [Was: Re: The way forward]


I would tend toward the interpretation that the blank node in each triple term is a new document and that all such blank nodes in different triple terms are different.


Olaf and Greg have had some similar questions about blank node handling in composite datatypes.


Bryan

________________________________
From: Franconi Enrico <franconi@inf.unibz.it>
Sent: Thursday, May 2, 2024 6:24:32 AM
To: Antoine Zimmermann
Cc: public-rdf-star-wg@w3.org
Subject: RE: [EXTERNAL] RDF-star profile "functional opaque” [Was: Re: The way forward]


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.




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.