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

Dear all,   If I understand these options correctly, considering these factors, Option 2 seems to be the most suitable for most use cases involving property graphs, especially if the primary concern is the relationships and structures represented by the graph rather than the nodes' identities. This approach offers a balance between expressiveness and manageability, facilitating easier data integration and graph analysis without the overhead of maintaining node identities. This method is also more aligned with the standard practices in graph theory and databases where structural properties are often more significant than the identities of individual nodes.   Best regards,  Dominik   Dnia 03 maja 2024 20:11 Doerthe Arndt <doerthe.arndt@tu-dresden.de> napisał(a):  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.