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

Am 2. April 2024 21:50:29 MESZ schrieb Andy Seaborne <andy@apache.org>:
>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.


I'd prefer this a lot to the wellformedness approach ("LPG-wellformed"?) 

Maybe use

    rdf:reifies

in the general case (any kind of one-to-one, one-to-many, many-to-one, many-to-many relation between reifier and triple term) 
and sometthing like

     rdf:edgeOf 

for the LPG-aligned many-to-one (and also the special one-to-one) case. 

Introducing a wellformedness condition would very much discourage any experimentation with xxx-to-many use cases. A special property like rdf:edgeOf to accomodate what we now expect to be the predominant use case should well suit the LPG interop requirements. 

I'm not against wellformedness constraints in general where they make sense, e.g. lists and reification quads, which are clearly disfunctional (or at least not very functional) if they are malformed. xxx-to-many relations however can make a lot of sense, so shouldn't be treated as malformed. 

Thomas 


>    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 22:59:09 UTC