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

On 2 May 2024, at 15:07, Antoine Zimmermann <antoine.zimmermann@emse.fr> 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.

> Also, such semantics can already be implemented in RDF 1.1 by relying on an appropriately defined datatype:
> <s> rdf:edge "_:bn123 <p> <o>"^^dt:turtle .
> (as I keep saying over and over again)

Indeed, I agree: this is what I am saying as well. The discussion is about what to put inside the quotes in place of bnodes.

cheers
—e.

>>> On 2 May 2024, at 14:38, Antoine Zimmermann <antoine.zimmermann@emse.fr> wrote:
>>> 
>>> Le 01/05/2024 à 17:27, Franconi Enrico a écrit :
>>>> I have written down the formal definition of two profiles in the wiki:
>>>>  * RDF-star profile “transparent”
>>>>    <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22transparent%22> (namely many-to-many transparent)
>>>>  * RDF-star profile "functional opaque”
>>>>    <https://github.com/w3c/rdf-star-wg/wiki/RDF-star-profile-%22functional-opaque%22> (namely many-to-one opaque)
>>> 
>>> Considering only the second item for the moment.
>>> 
>>> Assume we take 2 blank nodes b1 and b2, with b1 ≠ b2, and u1, u2 are 2 IRIs. Then the triples t1 = (b1, u1, u2) and t2 = (b2, u1, u2) are different.
>>> Then, since SRE is bijective, SRE(t1) ≠ SRE(t2).
>>> 
>>> Now, if we write things down in Turtle, how do we know if blank nodes appearing in different files, databases, or in-memory representation of RDF graphs correspond to the same, or different b-nodes.
>>> 
>>> For instance, if I have a Turtle file that just contains this triple:
>>> 
>>> <s> rdf:edge <<([] <p> <o>)>> .
>>> 
>>> And another Turtle file that contains exactly the same string, can we say that the graph of the first file entails the graph of the second?
>>> 
>>> This is a problem I already identified in Jan. 2023 when I proposed a semantics that is almost exactly the same as your RDF-star profile "functional opaque":
>>> 
>>> https://lists.w3.org/Archives/Public/public-rdf-star-wg/2023Jan/0100.html

>>> 
>>> As I said in this email: "One possible semantic extension of this could impose that isomorphic triples denote the same thing."
>>> 
>>> --AZ
>>> 
>>> 
>>>> They rely on two distinct properties - rdf:reifies and rdf:edge - and on two distinct syntactic categories - tripleTerm and opaqueTripleTerm.
>>>> For this reason, they could be just merged into a unique profile, which actually could be RDF-star itself.
>>>> Let me know comments,
>>>> cheers
>>>> —e.
>>>>> On 25 Apr 2024, at 02:37, Lassila, Ora <ora@amazon.com> wrote:
>>>>> 
>>>>> [My apologies that this comes at the last moment before tomorrow’s meeting.]
>>>>> We have had long discussions within the Neptune team about the ongoing debate in the WG. We want to find an amicable, consensus-based way forward. Obviously the support within the WG for the multi-triple reifier proposal is strong, and we understand that many WG members may not be willing to live with the single-triple reifier approach. That said, we also believe that we (Neptune and our OneGraph project) need to be true to our vision of the future of “graph interoperability”.
>>>>> Thus, we would like to bring back the idea of profiles: one for the multi-triple reifier support, another for the single-triple option. This would allow implementors some leeway, and would ultimately let the graph marketplace choose. People already make choices about what technologies they use, sometimes based on the level of support different technology vendors offer. Bottom line: we do not want to block progress in the WG, and this would let us move towards finishing the specifications. I think it is better that we get the largest possible number of implementors building RDF 1.2 -compliant products, rather than some companies “opting out”.
>>>>> Ora
>>>>> -- 
>>>>> Dr. Ora Lassila
>>>>> Principal Technologist, Amazon Neptune
>>> 
>>> -- 
>>> Antoine Zimmermann
>>> École des Mines de Saint-Étienne
>>> 158 cours Fauriel
>>> CS 62362
>>> 42023 Saint-Étienne Cedex 2
>>> France
>>> Tél:+33(0)4 77 49 97 02
>>> https://www.emse.fr/~zimmermann/

>>> 
> 
> -- 
> Antoine Zimmermann
> École des Mines de Saint-Étienne
> 158 cours Fauriel
> CS 62362
> 42023 Saint-Étienne Cedex 2
> France
> Tél:+33(0)4 77 49 97 02
> https://www.emse.fr/~zimmermann/

> 
>

Received on Thursday, 2 May 2024 13:17:03 UTC