Re: Presentation about reifiers and graphs



> On 17 Sep 2024, at 15:19, Antoine Zimmermann <antoine.zimmermann@emse.fr> wrote:
> 
> Le 17/09/2024 à 06:21, Franconi Enrico a écrit :
>> On 17 Sep 2024, at 05:20, Thomas Lörtsch <tl@rat.io> wrote:
>>>> Slides 19 and 20 ==> Uh? It is not clear at all what you want to say. It i probably enough to say: a set of triples associated to the same identifier can not be seen as a named graph, since the scope of the bnodes in that graph is not limited within that graph but it spans the whole main graph.
>>> 
>>> Not necessarily, as "Blank nodes *_can_* be shared between graphs in an RDF dataset." [0]
>>> [0] https://www.w3.org/TR/rdf11-concepts/#section-dataset

>> 1. In the above “encoding” of a named graph, blank nodes *_MUST_* be
>>    shared between graphs in an RDF dataset.
> 
> I would say "can" is the right word here. There are RDF datasets in which the named graphs do not have any blank nodes in common, therefore they do not share bnodes. You probably think of "sharing" in a different sense.

I meant that in the rdf-star approach bnodes with the same label but in different named graph will necessarily have the same denotation.

> 
>> 2. Datasets have two formalisations of semantics [1]: default graph as
>>    union or as merge, characterising exactly the sharing or not sharing
>>    of bnodes.
> 
> Please don't use [1] as if it had any authority. It's just a note about the many ways of formalising semantics of RDF datasets. Among possible formalisations, there are those where the default graph is meant to be interpreted as the union of the graphs in the named graphs, those where it is the merge instead, and those where it is neither.
> 
> Also, sharing or not sharing bnodes is a question of syntax. Sec.3.2 of [1] considers that bnodes can be shared among named graphs. Yet, with the same bnodes in multiple named graphs, one can still interpret a dataset as the merge.
> 
> In case it is not entirely clear, take b a bnode, and u1, u2 two distinct IRIs. G1 = {(b,u1,u1)} and G2 = {(b,u2,u2)} are different RDF graphs that share the same bnode. If G1 is true, then there is a resource related to what u1 denotes. If G2 is true, then there is a resource related to what u2 denotes. Both G1 and G2 could be true with two distinct resources related to what u1 and u2 denote respectively. Said differently, {G1,G2} being true is equivalent to {(b1,u1,u1),(b2,u2,u2)} being true, with b1 and b2 different bnodes. This is merge.
> 
> But one could also think of G1 and G2 as pieces of a larger graph G = {(b,u1,u1),(b,u2,u2)}, thus interpreting them together as their union.
> 
> Then, when you put the graphs G1 and G2 inside named graphs, there is no standard to how the collection of named graphs must be interpreted, neither as union, nor as merge, and there are many more options that do not require any of the two choices, as exemplified in [1].

Yes. Exactly my point.
While named graphs have this “undecided” semantics, the idea of representing them in rdf-star as mentioned above enforces the union semantics.

—e.

> 
> --AZ
> 
>> 3. In Trig, a blank node label represents the same blank node
>>    throughout the TriG unique document, i.e., blank nodes sharing the
>>    same label in differently labeled graph statements are considered to
>>    be the same blank node. >  4. In general, when named graphs in a dataset have different origin,
>>    you cannot assume that the same blank node label in different named
>>    graphs represents the same blank node.
>> *My conclusion*: these things need to be discussed, and we haven’t done it yet, and therefore I’d restrain to say that we can represent named graphs.
>> —e.
>> [1] https://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225/#default-graph-as-union-or-as-merge <https://www.w3.org/TR/2014/NOTE-rdf11-datasets-20140225/#default-graph-as-union-or-as-merge>
> 
> -- 
> 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 Tuesday, 17 September 2024 07:09:33 UTC