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

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 19:27:37 UTC