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

Hi.
I’m not sure what you mean by “meaning” here.
To me the meaning is purely what the RDF & RDFS say.
So there is nothing that "gives the extra properties any special meaning as far as RDF or RDFS is concerned?”
I consider that a requirement of the whole discussion, pretty much, which is what led me here.

In reading the expanded RDF I showed, someone might recognise an idiom or pattern that appears to show the sort of thing I described, but that, like other idioms in RDF or other descriptions and languages doesn’t mean that was the intension of anyone else.

I see nothing wrong with your example, of course - it is simply valid RDF.
But perhaps it is the sort of idiom that would be used for situations where the relation between the “parent” and “child” entities is not numeric and ordered, but named.
The shortened notation would be extended to have labels - we could call it an associative array (yuk!), dictionary or structure or whatever.

 :mary ns:child (son :alan, daughter :ann)
Is expanded to
 :mary ns:child_son :alan .
 :mary ns:child_daughter :ann .
 ns: child_son rdfs:subPropertyOf ns:child .
 ns: child_daughter rdfs:subPropertyOf ns:child .

Maybe many people already use this idiom for things like children.
But without the “child_”, which is perhaps useful here to localise the implied predicate generated from the short form, so that it is unlikely to clash with other uses of “son” or “daughter”.

As I tried to say below, the issue with comparing with Bags or other constructs, and other suggested ways of doing “lists” or “arrays”, is that there is no identified entity “children” (or “prizewinners”) as a group here.
Such groups are defined by their relationship with the subject (parent or dogShow).

Best
Hugh

> On 29 Sep 2022, at 20:27, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
> 
> This looks a lot like container membership properties except that RDF(S) doesn't know anything about the extra properties.  At least with container membership properties there is some notion that, for example, rdf:1 is the first.
> 
> What gives the extra properties any special meaning as far as RDF or RDFS is concerned?  What makes the expansion below any different from
> 
>  :dogShow ns:winners_x :ginger .
>  :dogShow ns:winners_y :Bailey .
>  ns:winners_x rdfs:subPropertyOf ns:winners .
>  ns:winners_y rdfs:subPropertyOf ns:winners .
> 
> Sure, there is absolutely nothing to prevent you from writing the expansion below and telling yourself that there is some extra meaning to it.  But that meaning doesn't survive transmission to someone who does not have access to your internal communications, at least without an extension to RDF or RDFS.  So tell us what the extra meaning is (both the formal meaning and any intended informal meaning) and how that meaning fits into the principles underlying RDF and RDFS.
> 
> peter
> 
> On 9/29/22 14:05, Hugh Glaser wrote:
>> As can often happen, I think I have led myself down a wrong path by relating RDF to data structures I know and programming languages, so I have been thinking of these ordered things wrongly.
>> Certainly for my main use case - papers and authors.
>> There is essentially not much of interest in the “nextAuthor” relation.
>> So lists are really not the right thing.
>> But also, “authorArray” is not something we usually want, unattached to the paper.
>> The fundamental relations are between the paper and the authors.
>> (Similar is true of husbands, prizes, etc.)
>> 
>> So let’s make it so.
>>  :paper ns:author_1 :alice .
>>  :paper ns:author_2 :bob .
>>  :paper ns:author_3 :charlie .
>> 
>> Of course, that means that there is no simple version such as
>>  :paper ns:author :alice .
>> 
>> But what if we also had
>>  ns:author_1 rdfs:subPropertyOf ns:author .
>> et seq?
>> 
>> I think this may well do exactly what I wanted (I don’t know if it does what you all want!)
>> 
>> And we could have syntactic sugar in the RDF languages, such as that described elsewhere:
>>  :dogShow ns:winners ( :ginger :bailey ) .
>> Expanding to:
>>  :dogShow ns:winners_1 :ginger .
>>  :dogShow ns:winners_2 :Bailey .
>>  ns:winners_1 rdfs:subPropertyOf ns:winners .
>>  ns:winners_2 rdfs:subPropertyOf ns:winners .
>> 
>> This preserves all the things we know and love about Open World and monotonicity.
>> Of course if you assert the triples individually, it is possible to have strange information created, such as two ns:winners_2, but that is as it should be in RDF.
>> And you can easily have partial information (ns:winners who are not in the ordering, and gaps), but again, that is the world we are modelling, and want to be able to do that.
>> But inconsistency of the sort we have been describing because of two relations describing similar relationships being maintained cannot happen.
>> And I can happily just use the “normal” ns:winners or ns:author whenever I don’t care or know anything about any ordering - nothing changes from what we all currently do naturally, I think.
>> 
>> It may be that this is a well-known pattern I have just described?
>> Or have I got something badly wrong?
>> 
>> Best
>> Hugh
>

Received on Thursday, 29 September 2022 20:59:24 UTC