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

Hi Hugh.


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

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.


How is this currently dealt with? I'd imagine this problem already exists
when merging data.

Is there an existing term that could connect two predicates like so?:

  :creator :singularOf :creators
  :author :singularOf :authors
  :member :singularOf :members

Or:

  :pluralOf :inverseOf :singularOf

  :creators :pluralOf :creator
  :authors :pluralOf :author
  :members :pluralOf :member

Then anytime the plural predicate is used it would entail a set of triples
involving the singular predicate, and any potential duplicates in the
resulting graph could then be removed:

  :Paper1 :authors :Paper1Authors
  :Paper1Authors rdf:_1 :Alice
  :Paper1Authors rdf:_2 :Bob
  :Paper1Authors rdf:_3 :Charlie

Would then entail:

  :Paper1 :author :Alice
  :Paper1 :author :Bob
  :Paper1 :author :Charlie

That way it wouldn't matter if someone wanted to use the singular predicate
or a collection, they'd be interoperable.

Anthony

On Sat, Sep 24, 2022 at 3:32 AM Hugh Glaser <hugh@glasers.org> 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.
> 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.
> 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
> > >
> >
> >
>
>