Re: RDF lists/arrays and n-ary relations [was Re: OWL and RDF lists]

Hi David,

On 22/09/2022 23:38, David Booth wrote:
> On 9/22/22 16:34, Pierre-Antoine Champin wrote:
>> I think it is useful to consider every proposed extension, and 
>> carefully consider whether it really requires an extension of the 
>> underlying data model, or whether it can be managed purely as 
>> syntactic sugar.
>
> Agreed.  That would be best for backward compatibility.  And it occurs 
> to me that some of these ideas for new "built-in" object types, such 
> as arrays and composite object, could actually be implemented as 
> syntactic sugar for named graphs.  For example, this array of dog show 
> winners:
>
>   # Example 1
>   :dogShow winners ( :ginger :bailey ) .
>
> might be treated as syntactic sugar for this TriG:
>
>   # Example 1-expanded
>   :dogShow :winners N2 .
>   N2 { :dogShow :winners
>          [
>            0 :ginger ;
>            1 :bailey
>          ] .
>      }

That's intriguing :)

But I'm not sure exactly what you gain here... Querying lists in SPARQL 
would be hardly easier as what it is today...

>
> where N2 is an auto-generated named graph name of some kind (TBD) -- 
> perhaps a blank node, a relative URI, or a Skolem URI.  By 
> "unblessing" N2, you get to "see" the triples that implement that list 
> object.
>
> And this composite diagnosis object, used for an n-ary relation:
>
>   # Example 6
>   :christine :diagnosis @[
>     :disease :breastCancer ;
>     :probability 0.8
>   ] .
>
> might be treated as syntactic sugar for this TriG:
>
>   # Example 6-expanded
>   :christine :diagnosis N6 .
>
>   N6 { :christine :diagnosis
>          [
>            :disease :breastCancer ;
>            :probability 0.8
>          ] .
>      }
>
> And this RDF-star syntax:
>
>   # Example 9
>   :a :name "Alice" {|
>       :statedBy :bob ;
>       :recorded "2021-07-07"^^xsd:date
>       |} .
>
> could be syntactic sugar for this TriG:
>
>   # Example 9-expanded
>   :a :name "Alice" .
>   N9 { :a :name "Alice" . }
>   N9 :statedBy :bob ;
>       :recorded "2021-07-07"^^xsd:date .

This pattern for expressing triples about triples has been largely 
discussed as an alternative to RDF-star (or, as you propose here, as a 
the plain RDF interpretation of Turtle-star / Sparql-star).

The outcome of the discussion was, IIRC, that this was not ideal, 
because it overloads named graphs with new uses. Since a dataset is a 
flat collection of named graphs, there is no easy way to distinguish 
"quoted-triples-named graphs" from "plain-old-named-graphs"...

Also, I think I read that some implementations do not behave well with 
too many named graphs.

Now, about the elephant in the room: it may seem strange that I am 
strongly advocating against extending the core model of RDF, while being 
a co-editor of RDF-star [1], which does exactly that. For the record, I 
first lend towards making RDF-star only syntactic sugar, but was 
eventually convinced that it deserved to become an integral part of the 
core model. I still believe, however, that such extensions should be the 
exception.

>
> This would have the benefit of supporting labeled property graphs, 
> n-ary relations and arrays all under the same mechanism, without 
> adding anything to the RDF core.
>
> Thoughts?

For ordered lists, Dan Brickley made a suggestion some time ago (on a 
github issue that I can't find right now, unfortunately): they could be 
encoded using RDF-star, like that:

   # Example 10 expanded
   <#paper1> schema:creator
       <#alice> {| ex:order 1 |},
       <#bob> {| ex:order 2 |},
       <#charlie> {| ex:order 3, ex:last |}.

It has the advantage of keeping the "simple" triple for each creator, 
and is quite easy to query in SPARQL. Of course, some syntactic sugar 
could be created to make this easier to write/read, e.g.:

   # Example 10 syntactic sugae
   <#paper1> schema:creator (| <#alice> <#bob> <#charlie> |).

It occurs to me that RDF-star could be leveraged in a similar way with 
your Example 6:

   # Example 6 expanded with RDF-star
   :christine :diagnosis _:d.
   _:d
     :disease :breastCancer {| ex:propertyOf _:d |};
     :probability 0.8 {| ex:propertyOf _:d |}.

(although this does not quite capture the "closed-ness" of properties... 
work in progress)

   pa

> David Booth
>