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

"Agreed Syntax" comes from

https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0095.html

     <<:s :p :o >> :foo :bar .

is a syntax form in Turtle.

In N-triples, which is like writing the RDF data model, it would be

     _:b rdf:reifies <<( :s :p :o )>> .
     _:b :foo :bar .

Sometimes, you want to choose the name:

     <<:e | :s :p :o >> :foo :bar .

is a syntax form for

     :e rdf:reifies <<( :s :p :o )>> .
     :e :foo :bar .


<<:s :p :o >> is an occurrence (usage) of the abstract triple, and the 
"triple" is written as an RDF term <<( :s :p :o )>>.


When we say "triple T in graph G", we really mean "an occurrence of 
triple T in graph G".


<<()>> is only addition to the RDF data model.


Summary of triple-reification proposals

https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0164.html
==>
Table:
https://lists.w3.org/Archives/Public/public-rdf-star-wg/2024Jan/0164.html

     HTH

     Andy


On 03/04/2024 21:01, Kurt Cagle wrote:
> Thanks for the explanation.
> *Kurt Cagle*
> Editor in Chief
> The Cagle Report
> kurt.cagle@gmail.com <mailto:kurt.cagle@gmail.com>
> 443-837-8725<http://voice.google.com/calls?a=nc,%2B14438378725>
> 
> 
> On Wed, Apr 3, 2024 at 10:50 AM Gregg Kellogg <gregg@greggkellogg.net 
> <mailto:gregg@greggkellogg.net>> wrote:
> 
>>     On Apr 3, 2024, at 10:43 AM, Kurt Cagle <kurt.cagle@gmail.com
>>     <mailto:kurt.cagle@gmail.com>> wrote:
>>
>>     I have a question for clarification. I've noticed a shift to the
>>     notation:
>>
>>     <<(:s :p :o)>>
>>
>>     from
>>
>>     << :s :p :o >>
>>
>>     Is there a distinction between the two, or simply a new syntax?
> 
>     In the CG report, the << :s :p :o >> syntax was used for a quoted
>     triple. Because of various issues with this, RDF 1.2 now uses <<( :s
>     :p :o )>> for a Triple Term, which is intended to mostly be used as
>     an implicit part of a “reifier”. A “reifier” has the same syntax is
>     the CG version << :s :p :o >> and can have an optional identifier,
>     << :id | :s :p :o >> which is effectively syntactic sugar for :id
>     rdf:reifies <<( :s :p :o )>> .
> 
>     The state of RDF Concepts is in the middle of this transition, we
>     haven’t even agreed on the name of a “reifier”, much less the
>     semantics. N-Triples does not include the reifier syntactic sugar
>     and only supports the use of Triple Terms directly.
> 
>>     *Kurt Cagle*
>>     Editor in Chief
>>     The Cagle Report
>>     kurt.cagle@gmail.com <mailto:kurt.cagle@gmail.com>
>>     443-837-8725<http://voice.google.com/calls?a=nc,%2B14438378725>
>>
>>
>>     On Wed, Apr 3, 2024 at 10:01 AM Franconi Enrico
>>     <franconi@inf.unibz.it <mailto:franconi@inf.unibz.it>> wrote:
>>
>>         On 3 Apr 2024, at 18:56, Gregory Williams
>>         <greg@evilfunhouse.com <mailto:greg@evilfunhouse.com>> wrote:
>>>
>>>>         On Apr 3, 2024, at 8:19 AM, Franconi Enrico
>>>>         <franconi@inf.unibz.it <mailto:franconi@inf.unibz.it>> wrote:
>>>>
>>>>         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.
>>>
>>>         For LPG interop use-cases, we want to be able to uniquely
>>>         identify occurrences of triples (edges). Your proposed
>>>         alternative wouldn’t capture the same semantics, as it would
>>>         be asserting properties of the triple term itself, not on a
>>>         specific occurrence of that triple.
>>
>>         My proposed alternative would surely capture the one-to-one
>>         cases, as I specified. LPG use cases are many-to-one, and my
>>         example above would not work for them, as you correctly point out.
>>         —e.
>>
>

Received on Wednesday, 3 April 2024 21:13:20 UTC