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

On 3 Apr 2024, at 15:22, Andy Seaborne <andy@apache.org> wrote:

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.

My question was different. Let me try to explain it better.
Ora wrote: "While the primary use-case for reifications may be 1-1, …”.
In these specific 1-1 cases, I believe that instead of:

:e rdf:reifies <<( :s :p :o )>> .
:e :p1 :o1 .

you should write directly:

 <<( :s :p :o )>> :p1 :o1 .

since this implicitly implements a 1-1 relationship.

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?

The difference is the the open/closed nature.

Again, I guess I should explain myself better.
Suppose we have:

:e rdf:reifies <<( :s1 :p :o1 )>> .
:e rdf:reifies <<( :s2 :p :o2 )>> .

by taking seriously the assumption that rdf:reifies is many-to-one or one-to-one (as opposed to many-to-many), the query:

ASK WHERE { _:x rdf:reifies <<( :s1 _:y :o2 )>> }

should return TRUE.
The question is: would you consider the above RDF graph not to be in the well formed fragment, in order to avoid this case?
If you do so, then the well-formed fragment would be strictly opaque, while the WG concluded that all use cases need transparency.
Indeed, under transparency, the following should be in the well-formed fragment characterising the many-to-one or one-to-one case:

:e rdf:reifies <<( :s1 :p1 :o1 )>> .
:e rdf:reifies <<( :s2 :p2 :o2 )>> .
:s1 owl:same-as :s2 .
:p1 owl:same-as :p2 .
:o1 owl:same-as :o2 .

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?

Of course, as I argued several times, if everybody in the world decides to model things in the same way, there is no problem, and in principle there would be no need of reification either - people would systematically write statements by explicitly introducing their referent and their properties.
It is the very same spirit as the liz/richard wedding, in the case of merging two graphs - one modelling weddings and the other wedding locations:

:w1 rdf:reifies <<( :liz : married :richard )>> .
:w1 :location :miami .
:w2 rdf:reifies <<( :liz : married :richard )>> .
:w2  :location :las-vegas .

:w1 rdf:reifies <<( :liz :married-in :las-vegas )>> .
:w1 :groom :richard .
:w2 rdf:reifies <<( :liz :married-in :miami )>> .
:w2 :groom :richard .

And, by the way, you couldn’t even support graphs with explicit symmetric properties, since the following would be illegal in the well-formed fragment:

<< :w1 | :liz :married :richard >> :location :las-vegas .
<< :w1 | :richard :married :liz >> :location :las-vegas .

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.

Why are you now talking about graphs? How is this related?

cheers
—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>
*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.