Re: rdf:reifies many-to-many vs. many-to-one

On 02/04/2024 23:40, Franconi Enrico wrote:
> Just an obvious question: why use cases willing to refer 1-to-1 to a 
> triple don't use directly the triple term as the referring term. I don’t 
> see why you would need a reifier.

In "agreed syntax" there is the named occurrence and the triple term.

The only change to the RDF data model is adding the triple term.
Other uses of triples are not prohibited by the data model.

Hence different properties.

> And these use cases should explain how to deal with transparency, namely 
> that there could be different triple terms with the same 1-to-1 reifier 
> without the respective subject, predicate, object being treated as equal 
> by SPARQL queries; or you would disallow these cases?
> —e.

The difference is the the open/closed nature.

When reifying triple, all the consequences of that triple apply. It's 
not referring to anything unrelated to that triple.

It's a single assertion and the building block. That is what is "closed".

I don't understand in your example what is being reified. It isn't the 
triple any more. It's more like some kind of a compound assertion event 
and it's open-ended.

<< :b1 | :enrico :born-in :rome >> :date 1962 .
<< :b1 | :enrico :born-on 1962 >> :location :rome .

For a table of birth-certificate, why not model the birth certificate?


My view is that area of graph assertion, graph terms, ..., needs 
exploration, including validation in real use (multiple uses and 
community consensus). The WG have tried to make sense of that and the 
problem got too big. Then we switched to consolidating around "agreed 
syntax".

The Working Group process is not well suited to experimentation. It is 
better to build a solid base and let further work happen for another cycle.

     Andy

> 
>> On 2 Apr 2024, at 21:50, Andy Seaborne <andy@apache.org> wrote:
>>
>> We can also have different properties rdf:reifies for the one-to-one 
>> case and rdf:reifSomeName for one-to-many.
>> There is a difference in that the first is closed, while the second is 
>> open.
>>
>>     Andy
>>
>> On 29/03/2024 12:02, Lassila, Ora wrote:
>>> Technically, the restrictions on cardinality that RDF does have all 
>>> fall within the “well-formedness” idea (in addition to the 
>>> rdf:first/rdf:rest case, instances of rdf:Statement should only one 
>>> have rdf:subject, rdf:predicate, and rdf:object each). We could 
>>> handle rdf:reifies the same way.
>>> Ora
>>> *From:*Gregg Kellogg<gregg@greggkellogg.net>
>>> *Date:*Thursday, March 28, 2024 at 4:07 PM
>>> *To:*Kurt Cagle<kurt.cagle@gmail.com>
>>> *Cc:*Thomas Lörtsch<tl@rat.io>, Souripriya 
>>> Das<SOURIPRIYA.DAS@oracle.com>, RDF-star WG<public-rdf-star-wg@w3.org>
>>> *Subject:*RE: [EXTERNAL] rdf:reifies many-to-many vs. many-to-one
>>> *Resent-From:*<public-rdf-star-wg@w3.org>
>>> *Resent-Date:*Thursday, March 28, 2024 at 4:06 PM
>>>
>>> *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.
>>>
>>> While the primary use-case for reifications may be 1-1, I think it 
>>> would be short sighted to try to limit this in the data model. Our 
>>> descriptions should focus on the 1-1 use case (unless we decide to 
>>> promote 1-many for some use cases). No place else in RDF has 
>>> cardinality restrictions, although it may not be considered to be 
>>> well-formed (similar to rdf:first/rest).
>>> My suspicion has been that if you provide a way for people to use 
>>> features such as 1-many reifications, they will use it. We noted on 
>>> the call about how a multi-statement reification has some 
>>> similarities with named graphs, but the semantics are different and 
>>> we should lean on that.
>>> (Perhaps Kurt may be helpful in helping to frame this in a future 
>>> What’s New in RDF 1.2 document, but contributions to RDF Concepts 
>>> would also be welcome when the time is ripe).
>>> Gregg Kellogg
>>> gregg@greggkellogg.net
>>>
>>>
>>>     On Mar 28, 2024, at 9:12 AM, Kurt Cagle<kurt.cagle@gmail.com>wrote:
>>>     > How do the following RDF datasets appear to a reader?
>>>     > DS-1 (requires many-to-many)=>
>>>     >     :e rdf:reifies <<( :s rdf:type :Married )>>, <<( :s rdf:type :Single )>> .
>>>     >     :e :accTo :marriageRegistrar .
>>>     > DS-2=>
>>>     >     :e1 rdf:reifies <<( :s rdf:type :Married )>> .
>>>     >     :e2 rdf:reifies <<( :s rdf:type :Single )>> .
>>>     >     :e1 :accTo :marriageRegistrar .
>>>     >     :e2 :accTo :marriageRegistrar .
>>>     >
>>>     > Would the following be a reasonable assessment, keeping the (naive) reader in mind?
>>>     > - DS-1 is more concise, but could be confusing.
>>>     > - DS-2 is simpler and less confusing.
>>>     This implies that DS-1 is a hypergraph. I'm for that personally.
>>>     This has been an objection I've had with RDF for some time, but
>>>     it potentially necessitates a bigger change in RDF.
>>>
>>>     *Kurt Cagle*
>>>     Editor in Chief
>>>     The Cagle Report
>>>     kurt.cagle@gmail.com <mailto:kurt.cagle@gmail.com>
>>>     443-837-8725
>>>     On Thu, Mar 28, 2024 at 7:02 AM Thomas Lörtsch <tl@rat.io> wrote:
>>>
>>>
>>>
>>>         > On 28. Mar 2024, at 13:00, Souripriya Das
>>>         <SOURIPRIYA.DAS@oracle.com> wrote:
>>>         >
>>>         > Wondering if staying with many-to-one for rdf:reifies will
>>>         keep things simpler for the reader. Consider the following
>>>         example.
>>>         >
>>>         > Assuming that the following should hold in a domain:
>>>         >     :Single owl:disjointWith :Married .
>>>         >
>>>         > How do the following RDF datasets appear to a reader?
>>>         > DS-1 (requires many-to-many)=>
>>>         >     :e rdf:reifies <<( :s rdf:type :Married )>>, <<( :s
>>>         rdf:type :Single )>> .
>>>         >     :e :accTo :marriageRegistrar .
>>>         > DS-2=>
>>>         >     :e1 rdf:reifies <<( :s rdf:type :Married )>> .
>>>         >     :e2 rdf:reifies <<( :s rdf:type :Single )>> .
>>>         >     :e1 :accTo :marriageRegistrar .
>>>         >     :e2 :accTo :marriageRegistrar .
>>>         >
>>>         > Would the following be a reasonable assessment, keeping the
>>>         (naive) reader in mind?
>>>         > - DS-1 is more concise, but could be confusing.
>>>         > - DS-2 is simpler and less confusing.
>>>
>>>         To me DS-1 feels immediatly familiar whereas DS-2 feels
>>>         verbose. To me the verbosity of DS-2 is confusing, not the
>>>         simple list of triple terms in DS-1.
>>>
>>>
>>>         Some thoughts:
>>>
>>>         Grouping reifications by their attribute can probably be
>>>         considered a very basic use case, a need that will inevitably
>>>         arise.
>>>
>>>         Up to now grouping is realized with named graphs, but there
>>>         is strong opposition towards basing the annotation mechanism
>>>         on named graphs. Ergo we should make sure that what we design
>>>         doesn’t work only on single triple terms but also on sets of
>>>         them.
>>>
>>>         That should be done in a way that users don’t need to know
>>>         upfront if an annotation targets a reification refering to
>>>         only a single or triple term or a multiple thereof. (That
>>>         should be easy with SPARQL-star, but is impossible when
>>>         single triple annotations are encoded as triple term
>>>         reifications but multiples thereof are encoded as named graphs).
>>>
>>>         The annotation syntax, e.g.  '<< :e1 | :s :p :o >>', should
>>>         be extended to allow multiple triples as well, e.g. '<< :e2 |
>>>         :s :p :o. :x :y :z . >>'. Otherwise annotating multiple
>>>         triple terms always has to resort to the more verbose
>>>         N-triples syntax with explicit rdf:reifies statements.
>>>
>>>         Such a solution would make sematically sound grouping
>>>         available to RDF proper. The guidance w.r.t. named graphs
>>>         would be to only use them for application specific purposes,
>>>         outside the realm of data sharing and integration. This would
>>>         mean that we bite the bullet that named graphs can not be
>>>         saved for anything else than out-of-band activities. Note
>>>         that this is not my position, but it is a position that would
>>>         allow us to move forward.
>>>
>>>         Keeping named graphs as a (semantically unsound) grouping
>>>         device and designing triple term annotations as a one-trick
>>>         pony to enable LPG-style modelling in RDF is not a very
>>>         elegant and coherent design, and that lack of elegance and
>>>         coherence will lead to a lot of questions, frustrations, need
>>>         for explanations - exactly the thing that Ora fears.
>>>
>>>         Note also that another need will inevitably appear as well:
>>>         the desire to state AND annotate a set of statements in one
>>>         go, leading to the need for another syntactic device.
>>>
>>>
>>>         Please note as well that the Nested Named Graphs proposal [0]
>>>         has all those issues and needs covered. However, it stumbled
>>>         into a roadblock that so far we weren’t able to overcome:
>>>         SPARQL is not really made for querying quads and annotations
>>>         too easily can get lost in the course of a query. That
>>>         requires a lot more effort than we can currently master.
>>>
>>>
>>>         Best,
>>>         Thomas
>>>
>>>
>>>         [0]https://github.com/rat10/nng
>>>
>>>
>>>         > Thanks,
>>>         > Souri.
>>>
>

Received on Wednesday, 3 April 2024 13:22:07 UTC