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

I think I can clean those examples up actually, and also make them more
consistent with the general structure of JSON/JSON-LD. The only example
that expands to a set of triples is example 4, which uses the spread
operator (...).

1. Open set.

{
  @id: :TeamUSA2020,
  @type: :OlympicTeam,
  @set: [
    :SimoneBiles,
    :MeganRapinoe,
    :KevinDurant,
  ],
} :medalCount 113


2. Closed list.

{
  @id: :NycToSydneyFlight,
  @type: :Flight,
  @closedList: [
    :NycToLAFlight,
    :LALayover,
    :LAToSydneyFlight,
  ],
} :durationInHours 22


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

:MichaelJordan :jerseyNumbers @set[23, 45]


4. Compact form of multiple triples.

:BillClinton :nickName ...[
  "Bubba",
  "The Comeback Kid",
  "Slick Willie",
]


Anthony

On Tue, Sep 20, 2022 at 10:59 AM Anthony Moretti <anthony.moretti@gmail.com>
wrote:

> I agree with David, first-rest ladders are kind of like writing assembly.
>
> Regarding Example 1 though, I think it's important to clearly
> differentiate the case where the list expands to a set of triples and where
> it doesn't, they're very different things. JSON-LD addresses this
> somewhat by using plain arrays vs ones annotated by "@list", but it seems
> to me their use of "@set" isn't consistent with their use of "@list"
> because "@set" gets "optimized away" and becomes the same as a plain
> array that expands to a set of triples. I'd also avoid using "probability"
> in any examples, in my view it introduces a whole other category of
> problems to do with statements being true/false/inbetween and then we get
> into RDF-star.
>
> Thomas, I didn't comment on your earlier proposal because although it was
> quite comprehensive it seems to suffer in terms of usability, I'd like to
> try and build on some of the concepts though.
>
> In the following examples all fields are optional except for "@id", which
> should be required if the collection includes IRIs.
>
> 1. An *open set* that *doesn't* expand to a set of triples (the statement
> is only about the collection as a whole):
>
> @set[
>     @id: :TeamUSA2020,
>     @type: :OlympicTeam,
>     :SimoneBiles,
>     :MeganRapinoe,
>     :KevinDurant,
> ] :medalCount 113
>
>
> 2. A *closed list* that *doesn't* expand to a set of triples:
>
> @list[
>     @id: :NycToSydneyFlight,
>     @type: :Flight,
>     @closed: true,
>     :NycToLAFlight,
>     :LALayover,
>     :LAToSydneyFlight,
> ] :durationInHours 22
>
>
> 3. A value collection that *doesn't* expand to a set of triples (value
> collections don't need IDs):
>
> :MichaelJordan :jerseyNumbers @set[23, 45]
>
>
> 4. A collection that *does* expand to a set of triples (the "..." syntax
> is inspired by the "spread" operator in Dart):
>
> :BillClinton :nickName ...[
>
>     "Bubba",
>
>     "The Comeback Kid",
>
>     "Slick Willie",
>
> ]
>
>
> This type of collection doesn't need any annotations because statements
> are unordered. The "spread" operator, ..., makes it more visually clear
> that the collection expands to a set of triples.
>
> Just some ideas.
> Anthony
>
>
> On Tue, Sep 20, 2022 at 6:55 AM David Booth <david@dbooth.org> wrote:
>
>> On 9/19/22 11:53, Thomas Lörtsch wrote:
>>  > Let’s imagine - a shape X - an annotation syntax @ -
>>  > an annotation @X can be applied to most entities in RDF
>>  >
>>  > For example - X could mean List - the object could be a list
>>  > (a,b,c) - the annotation applied to the object would be
>>  > (@X a,b,c)
>>  >
>>  > The meaning would be that - this is not syntactic sugar
>>  > for an rdf:List struct - it is a list _object_ with certain
>>  > properties as described by the X shape, which in this case is
>>  > an rdf:List shape.
>>
>> I like this general idea a lot!  I think it still needs quite a bit of
>> refinement, both in syntax and semantics, but I think it's going in a
>> good direction.
>>
>> In essence, it is giving the ability to define new kinds of objects.
>> When such an object is defined, it becomes "blessed", such that it is
>> treated as a new type of object: it is no longer treated as the sum of
>> its constituent parts.  "Unblessing" it allows you to access its
>> constituent parts.
>>
>> Modern programming languages such as Java do these blessing and
>> unblessing operations implicitly when you define and implement a new
>> class, so the operations are invisible.  Inside the class definition,
>> the object is automatically unblessed, while outside the class
>> definition it is automatically blessed.  However, in a language like
>> Perl, the "bless" operation is explicit, so it is directly visible in
>> code.
>> https://perldoc.perl.org/functions/bless
>>
>> I bring this up because I think it is useful to bear in mind the
>> distinction between the blessed object and the unblessed constituent
>> parts.  As you stressed, they are not syntactically or semantically
>> equivalent, even though they are interconvertible.
>>
>> Thanks,
>> David Booth
>>
>>
>>
>>