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

On 9/27/22 09:58, Pierre-Antoine Champin wrote:
> 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).

Small but important clarification: currently RDF lists do NOT give 
"closedness", but "closedness" is definitely what we want (for the vast 
majority of use cases).  That is precisely one of the reasons I and 
others feel such a need for (closed) arrays.

> . . .
>> Hugh Glaser wrote:
>> 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. 

Yes, that is exactly what's needed, and it is readily attainable if we 
eliminate *explicit* blank nodes.  By explicit blank nodes, I mean blank 
nodes that are written like _:b42 in Turtle.  Implicit blank nodes, 
written with square brackets like "[ ... ]", do not cause problems 
because they are guaranteed to be acyclic.  This means that it would be 
easy for tools to generate a consistent internal identifier for them, 
based recursively on their constituent elements.  (This is closely 
related to RDF canonicalization, which becomes trivially easy without 
explicit blank nodes.)  Eliminating explicit blank nodes would mean that 
we'd lose the convenience of not having to allocate an IRI.  I think 
there are ways to address that loss in other ways, but that's another topic.

 > But that would depart from their current interpretation, and not
 > necessarily fit all use-cases,

Agreed, but it would fit the most common use cases.  It doesn't have to 
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).

I hope Pat will correct me if I'm wrong, but my read of the discussion 
so far is that the semantics would not be a big problem: both arrays and 
composite objects can have very straight-forward -- and very similar -- 
semantics.  And it's clear to me at least that although the 
rdf:aboutEach functionality could be useful in some cases, it is not 
what we need as the basic array functionality.  The basic functionality 
that we need is for an assertion about an array to *only* be about that 
array -- not about every element in that array:

   ("apples" "bananas" "peaches") ex:length 3 .

And one other comment . . .

On 9/27/22 09:43, Pierre-Antoine Champin wrote:
 > If we can design other efficient design patterns for conveying order and
 > "closedness" (such as the one proposed above), I believe that the need
 > for representing lists would not be as pressing as suggested in this
 > thread.

Possibly.  But software developers have been using arrays for 60+ years, 
and they *expect* them.  So as a practical matter, I think the 
straight-forward solution is to add proper support for arrays, perhaps 
in a new higher-level RDF 2.0 syntax, to avoid breaking any existing RDF 
or tools.

As Manu Sporny put it, by not having proper array support in RDF, we're 
currently "giving developers a big fat middle finger in that area".
https://web.archive.org/web/20200119081859/https://manu.sporny.org/2014/json-ld-origins-2/

I think we should address that gap.

Thanks,
David Booth

Received on Tuesday, 27 September 2022 18:32:36 UTC