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

> On 27 Sep 2022, at 14:58, Pierre-Antoine Champin <pierre-antoine@w3.org> wrote:
> 
> 
> 
> 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).
I don’t know what you mean by “closeness”.
They give you a common relation between entities that gives an ordering if you want to think of it like that, with a distinguished (first) entity.
I still have no idea why anyone would want such a thing, other than they are used to them in programming languages.
They don’t give anything extra than something akin to arrays, and arrays have indexing, which is what is needed.
(The more general dictionaries/associative arrays might be interesting too/instead, of course.)
> 
> 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.
Open world: absolutely.
A question I was addressing is the meaning of having a husbandList such as you assert, and how it can make things somewhat more complex when querying.
I would nitpick with you here, however :-)
I would expect that
>   :alice ex:husbands ().
tells me noting about whether Alice has any husbands either.
Just as
>   :briana ex:husbands (:bob).
surely doesn’t tell me that Briana only has one husband.
We really wouldn’t want to assume anything more, as it does conflict with the Open World assumption, I think.

When trying to find Alice’s husbands, you might need to remember that there may be no husbandList or the husbandList might be empty.
Unless you choose to always assert a husbandList, even if it is empty.
I don’t like that.
But for me it is all moot, as I don’t like the whole thing :-)
> 
>> 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).
Sorry, of course I meant “bnodes”, not “bonds” (autocorrected).
So yes, a real mess.
> 
>   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
>>>> 
>>>> 
>>> 
>> 
> <OpenPGP_0x9D1EDAEEEF98D438.asc>

Received on Tuesday, 27 September 2022 14:37:02 UTC