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

Last one from me.

If you wanted to strip it down to the minimum possible idea, a
syntactically simpler way of grouping things than first-rest ladders, it
might look like the following:

Changes from last proposal:

   - No inline definition of a collection - they take their own line, and
   only the collection ID is used in other triples.
   - Type information is described on its own line, the same as it is in
   existing RDF.
   - No compact representation of multiple triples.
   - Delimiter syntax closer to Turtle than JSON.


1. Open set.

  [
    @id: :TeamUSA2020,
    @set: (
      :SimoneBiles,
      :MeganRapinoe,
      :KevinDurant,
    )
  ]
  :TeamUSA2020 :type :OlympicTeam
  :TeamUSA2020 :medalCount 113

2. Closed list.

  [
    @id: :NycToSydneyFlight,
    @closedList: (
      :NycToLAFlight,
      :LALayover,
      :LAToSydneyFlight,
    )
  ]
  :NycToSydneyFlight :type :Flight
  :NycToSydneyFlight :durationInHours 22

3. Value set (value collections are closed by definition, like all value
types).

  :MichaelJordan :jerseyNumbers @set(23, 45)

Anthony

On Wed, Sep 21, 2022 at 10:53 PM Anthony Moretti <anthony.moretti@gmail.com>
wrote:

> If the aim was to migrate everyone away from core RDF to these extra
> layers then I'd agree, but if it's not and if there's still a significant
> percentage of people using core RDF shouldn't we continue trying to make
> core RDF more complete and maybe easier to use?
>
> People have been asking for a better way to do lists for so long, there's
> something behind that isn't there? Maybe there's something I'm not getting
> though (if so, maybe someone could explain it to me). Happy to keep trying
> to contribute ideas anyway.
>
> Anthony
>
> On Wed, Sep 21, 2022 at 4:46 PM Pierre-Antoine Champin <
> pierre-antoine@w3.org> wrote:
>
>>
>> On 20/09/2022 00:17, David Booth wrote:
>> > Hi Pierre-Antoine,
>> >
>> > On 9/18/22 21:36, Pierre-Antoine Champin wrote:
>> >> it seems to me that RDF + Shapes + Ontology gives you all this already:
>> >
>> > Agreed, but that kind of illustrates the point: yes, these things are
>> > *possible* to do using RDF, but they are substantially more difficult
>> > than they should be.  Objects (composed of key-value pairs, which can
>> > also give us n-ary relations) and arrays are so basic to developers,
>> > they should be *easy*, not merely possible.
>>
>> I totally agree.
>>
>> However, I am more inclined to handle this as an extra layer on top of
>> the core of RDF, than by making the core more complex.
>>
>> For example, JSON-LD provides such an extra layer, as it is designed to
>> let people use it as "plain" JSON if they want to, handling objects,
>> lists... as one is used to. (I'm not implying, of course, that JSON-LD
>> solves all the problems -- only illustrating my point above.)
>>
>>    pa
>>
>> >
>> > According to the DB-Engines site, of the top 10 graph databases, RDF
>> > databases have only 14% of the market.  And even that is probably an
>> > over-count, because most of those RDF databases are actually
>> > multi-modal, so it isn't clear how many of them are being used for
>> > their RDF capability.
>> > https://db-engines.com/en/ranking/graph+dbms
>> >
>> > If it were easier in RDF to do things that are trivially easy for
>> > programmers to do in non-RDF applications, I think RDF could get much
>> > greater uptake.
>> >
>> > Best wishes,
>> > David Booth
>> >
>> >>
>> >> - Shapes can be used to guarantee that any node with a :disease
>> >> property also has a :probability property (and vice-versa) -- and
>> >> that these properties can't have multiple values.
>> >>
>> >> - Ontologies can be used to guarantee that any two nodes with the
>> >> same :disease and :probability values are owl:sameAs.
>> >>
>> >> All your examples would then work with the standard [] syntax instead
>> >> of the new @[] syntax.
>> >>
>> >>
>> >> Note that Shapes + Ontologies can also be used for lists,
>> >> constraining first/rest ladders to be well-formed. Granted, this
>> >> would require
>> >>
>> >> 1) to solve the problem of rdf:first/rdf:rest being not allowed in
>> >> OWL A-boxes, and
>> >> 2) to extend the SPARQL syntax to make it more convenient to query
>> lists
>> >>
>> >> but none of it, in my opinion, calls for an extension of RDF itself.
>> >>
>> >>    pa
>> >>
>> >> On 18/09/2022 13:20, David Booth wrote:
>> >>> Great discussion!  It seems that lists and n-ary relations are
>> >>> closely related, in that one could view a list as a set of key-value
>> >>> pairs (or predicate-object pairs) of an n-ary relation.
>> >>>
>> >>> For example, if the Turtle list syntax were used to express a
>> >>> built-in list object -- or more properly an *array* object -- rather
>> >>> than a first-rest ladder of triples, then this example:
>> >>>
>> >>>   # Example 1
>> >>>   :dogShow winners ( :ginger :bailey ) .
>> >>>
>> >>> might be almost equivalent to:
>> >>>
>> >>>   # Example 2
>> >>>   :dogShow :winners [
>> >>>     0 :ginger ;
>> >>>     1 :bailey
>> >>>   ] .
>> >>>
>> >>> if integers could be used as predicates, which they can in
>> >>> generalized RDF.
>> >>> https://www.w3.org/TR/rdf11-concepts/#section-generalized-rdf
>> >>>
>> >>> However, example 1 expresses a single triple, whereas example 2
>> >>> expresses three triples.
>> >>>
>> >>> In languages that manipulate RDF, such as SPARQL and various
>> >>> programming languages, it is always helpful to have ways to convert
>> >>> between a built-in construct and its constituent parts, and this can
>> >>> either be done implicitly or with explicit operators.  Implicit
>> >>> conversion offers more convenience, but at the price of being more
>> >>> error prone.  For example, if SPARQL did this conversion implicitly,
>> >>> the ordered list of winners from example 1 above might be obtained by:
>> >>>
>> >>>   # Example 3: implicit conversion from list to set of triples
>> >>>   SELECT ?winner ?index
>> >>>   WHERE {
>> >>>    :dogShow :winners [ ?index ?winner ]
>> >>>    }
>> >>>   ORDER BY ?index
>> >>>
>> >>> On the other hand, if an explicit "@[ ... ]" operator were instead
>> >>> added to SPARQL, to convert a built-in list to its equivalent set of
>> >>> explicit triples, then the query might look like this:
>> >>>
>> >>>   # Example 4: explicit conversion from list to set of triples
>> >>>   SELECT ?winner ?index
>> >>>   WHERE {
>> >>>    :dogShow :winners @[ ?index ?winner ]
>> >>>    }
>> >>>   ORDER BY ?index
>> >>>
>> >>> I'm just making up a possible syntax here for illustrative purposes.
>> >>> Some other syntax might be better.
>> >>>
>> >>> A method should also be provided to go the other direction: convert
>> >>> a set of triples into the equivalent built-in object. And although I
>> >>> think that sets and bags would also be useful, I think they could be
>> >>> readily layered on top of lists/arrays if we get proper built-in
>> >>> list/array support.
>> >>>
>> >>> Example 2 above is strikingly similar to a commonly used idiom for
>> >>> encoding an n-ary relation:
>> >>>
>> >>>   # Example 5
>> >>>   :christine :diagnosis [
>> >>>     :disease :breastCancer ;
>> >>>     :probability 0.8
>> >>>   ] .
>> >>>
>> >>> Idioms for n-ary relations are explained in
>> >>> https://www.w3.org/TR/swbp-n-aryRelations/
>> >>>
>> >>> This similarity that others have pointed out between lists and n-ary
>> >>> relations seems like good news, because it suggests that if we can
>> >>> figure out how to add one to RDF, we can also add the other, and
>> >>> both are sorely needed for convenience.  For reasons why, see:
>> >>> https://github.com/w3c/EasierRDF/issues/74
>> >>> https://github.com/w3c/EasierRDF/issues/20
>> >>>
>> >>> Example 5 above is really a work-around for the lack of native n-ary
>> >>> relations in RDF.  It expresses three triples:
>> >>>
>> >>>   # Example 5a -- ntriples for example 5
>> >>>   :christine :diagnosis _:b0 .
>> >>>   _:b0 :disease :breastCancer .
>> >>>   _:b0 :probability 0.8 .
>> >>>
>> >>> However, inspired by example 4 above, perhaps a similar syntax could
>> >>> be used to write an n-ary relation that would treat Christine's
>> >>> suspected disease and probability as a single entity participating
>> >>> in the :diagnosis relation:
>> >>>
>> >>>   # Example 6
>> >>>   :christine :diagnosis @[
>> >>>     :disease :breastCancer ;
>> >>>     :probability 0.8
>> >>>   ] .
>> >>>
>> >>> This differs from example 5 because example 6 expresses a *single*
>> >>> triple that connects :christine with a diagnosis object -- not 3
>> >>> triples.  The order in which the diagnosis properties are listed has
>> >>> no effect -- they are a set:
>> >>>
>> >>>   # Example 7a: property order does not matter
>> >>>   @[ :probability 0.8 ; :disease :breastCancer ]
>> >>>      owl:sameAs  @[ :disease :breastCancer ; :probability 0.8 ] .
>> >>>
>> >>> and adding or removing a property makes it different:
>> >>>
>> >>>   # Example 7b
>> >>>   @[ :probability 0.8 ; :disease :breastCancer ]
>> >>>      :NOT_sameAs  @[ :disease :breastCancer ; :probability 0.8 :year
>> >>> 2022 ] .
>> >>>
>> >>> Trying to specify the same property twice should be a syntax error:
>> >>>
>> >>>   # Example 7c -- INVALID -- SYNTAX ERROR!
>> >>>   :christine :diagnosis @[
>> >>>     :disease :breastCancer ;
>> >>>     :disease :colonCancer ;
>> >>>     :probability 0.8
>> >>>   ] .
>> >>>
>> >>> But the following would not be a syntax error, even if it may be
>> >>> semantically wrong:
>> >>>
>> >>>   # Example 7d
>> >>>   :malady owl:sameAs :disease .
>> >>>   :christine :diagnosis @[
>> >>>     :disease :breastCancer ;
>> >>>     :malady :colonCancer ;
>> >>>     :probability 0.8
>> >>>   ] .
>> >>>
>> >>> And of course, these constructs could be nested as desired.
>> >>>
>> >>> I think something like this could meet the need for n-ary relations
>> >>> in some future RDF syntax.  And based on previous comments by Pat
>> >>> and Anthony, it sounds like the semantics would not be a problem.
>> >>>
>> >>> Thanks very much to Thomas, Pat, Anthony and others for a very
>> >>> helpful discussion!
>> >>>
>> >>> David Booth
>> >>>
>> >
>>
>