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

On 23/09/2022 22:31, Hugh Glaser wrote:
> Thanks, Anthony.
>
> In my view rdfs:ContainerMembershipProperty doesn’t model what we want, certainly not with the flexibility we/I need.
>
> What would a triple that simply asserted that Paper2 had an author called David look like?
> And then would it allow an homogeneous query to find all authors of the two papers?
> Really, all I know (yet/forever) is that
>  :Paper2 dct:creator :David .
> In general it doesn’t deal with partial knowledge very well, I think.
> Because it forces you to put an ordering on things, even if you don’t know one.
>
> A great thing about RDF is exactly that most of the time you aren’t forced to put things in order - you simply assert the facts you have gleaned (so far) from sources.
> Occasionally you realise that there is an ordering that you know, and it may be significant, so you want to assert it.
> So you need to be able to monotonically add that knowledge.
> And you don’t want to create a maintenance problem by having the information inferred in two places.
> So for example you don’t want both an “authorList” and a set of act:creator triples, I would say - a Bad Thing.
>
> There are many situations where subject entities have relations with single objects for the most part, but also some have multiple relations. And sometimes you will find out an ordering for those relations.
> It would be a pain to always have to say that a woman had a (possibly empty) :husbandList with very often one member, and allow for that when querying for their husband.
> Rather than simply saying nothing for unmarried women, and having a simple single relation for :husband.

nitpicking: RDF semantics works under the open world assumption, therefore

- saying nothing about a woman's husband(s) does *not* entail that she 
is/was not married;
- stating a single relation for :husband does not entail that this woman 
didn't have other husbands

lists do not only give you order, they give you "closedness": the 
first/rest ladder captures the fact that the list contains all these 
elements *and only them* (and in this particular order).

So there is more information in:

   :alice ex:husbands ().
   :briana ex:husbands (:bob).
   :charlie ex:husbands (:dan, :ed).

than in

   # nothing about :alice
   :briana ex:husband :bob.
   :charlie ex:husband :dan, :ed.

> And if you never find out what order the marriages happened (or indeed if they were polyandrous or bigamous and so contemporaneous), what do you assert?
>
> By the way, this is why I think that discussions of RDF changes need to be properly grounded in test cases, including how to query, although I don’t pretend I have done it well here.
>
> I also worry that if I assert exactly the same knowledge twice, a paper could end up with two authorLists, certainly if bonds got involved.

Indeed...

That's actually something that "lists as first class citizens" could 
help solve -- that is, if they were defined in such a way that two lists 
with exactly the same elements are in fact one and the same object. But 
that would depart from their current interpretation, and not necessarily 
fit all use-cases, so this is not something to decide lightly. This is 
the kind of semantic rabbit hole that Pat Hayes was warning about 
earlier in this thread (if I got his point correctly).

   pa

> There may be other concerns, but I think the above describes the major ones.
>
> Hugh
>
>
>> On 23 Sep 2022, at 16:38, Anthony Moretti<anthony.moretti@gmail.com>  wrote:
>>
>> Sorry if the naming was confusing, I tend to use list/array interchangeably (in Swift they're arrays, in Dart they're lists, they're the same though, both indexable). rdf:List I tend to think of as a "linked list".
>>
>> In any case though, don't we already have rdfs:ContainerMembershipProperty if we need to access by index?:
>>
>>    :Paper1 :authorList :Paper1Authors
>>    :Paper1Authors rdf:_1 :Alice
>>    :Paper1Authors rdf:_2 :Bob
>>    :Paper1Authors rdf:_3 :Charlie
>>
>> And something a bit out there and with potential to break things: allowing literals in the predicate position. Whenever in that position they'd be read as an array index:
>>
>>    :Paper1 :authorList :Paper1Authors
>>    :Paper1Authors "1"^^xs:integer :Alice
>>    :Paper1Authors "2"^^xs:integer :Bob
>>    :Paper1Authors "3"^^xs:integer :Charlie
>>
>> Anthony
>>
>> On Fri, Sep 23, 2022 at 9:58 PM Hugh Glaser<hugh@glasers.org>  wrote:
>> Thanks, David :-)
>>
>> Yes, it is definitely more than an array.
>> Any suggestions for a name?
>> Having a good name for a thing can be very helpful in focussing discussion, now and in the future.
>>
>> It’s sort of like a “half-ladder” to me, in terms of a data structure (which it isn’t, of course).
>> Maybe there is a name that captures this sort of knowledge pattern?
>>
>>> On 23 Sep 2022, at 14:20, David Booth<david@dbooth.org>  wrote:
>>>
>>>
>>> On 9/23/22 07:16, Hugh Glaser wrote:
>>>> I don't think talking about "lists" at all is a good term.
>>> Fully agree.  We need arrays, not lists.
>>>
>>>> . . .
>>>> 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.
>>> Yes, but note that that example is *different* from the basic use
>>> of an array, because it asserts the schema:creator relation on
>>> every element of the array -- not on the array as a whole.
>>> It is like applying a "map" operator to an array of
>>> people, in order to assert them all as schema:creators.
>>>
>>> On 9/23/22 00:21, Anthony Moretti wrote:
>>>> all the proposals are for syntactic sugar, but please
>>>> ignore them, it's clear I haven't considered things well
>>>> enough. Apologies for any time wasted.
>>> Not wasted!  They were useful contributions to the conversation.  Please
>>> continue to contribute.  We are collectively figuring this stuff out as
>>> we go along, and the process benefits from diverse perspectives and ideas.
>>>
>>> Thanks,
>>> David Booth
>>>
>>
>