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

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
>
>
>
>