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

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