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

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.
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.

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><mailto:gregg@greggkellogg.net>
Date: Thursday, March 28, 2024 at 4:07 PM
To: Kurt Cagle <kurt.cagle@gmail.com><mailto:kurt.cagle@gmail.com>
Cc: Thomas Lörtsch <tl@rat.io><mailto:tl@rat.io>, Souripriya Das <SOURIPRIYA.DAS@oracle.com><mailto:SOURIPRIYA.DAS@oracle.com>, RDF-star WG <public-rdf-star-wg@w3.org><mailto: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><mailto: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<mailto:gregg@greggkellogg.net>


On Mar 28, 2024, at 9:12 AM, Kurt Cagle <kurt.cagle@gmail.com><mailto: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<mailto:tl@rat.io>> wrote:


> On 28. Mar 2024, at 13:00, Souripriya Das <SOURIPRIYA.DAS@oracle.com<mailto: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.