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

If the names have to be ordered what information does this ordering impart?  
It now looks as if you want to transmit some information to another unnamed 
party without telling anyone else about it.   Go ahead and create a private 
semantic extension for RDFS.  There is no problem with that, but then why are 
you discussing what you want to do in this forum without also saying what this 
semantic extension is about.


peter


On 9/30/22 05:49, Hugh Glaser wrote:
>
>> On 29 Sep 2022, at 23:22, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>
>>
>> On 9/29/22 18:08, Hugh Glaser wrote:
>>> Hi Peter,
>>> Thanks for engaging.
>>>
>>>> On 29 Sep 2022, at 22:27, Peter F. Patel-Schneider <pfpschneider@gmail.com> wrote:
>>>>
>>>> For any of this to have use, someone has to say what the triples mean.  As far as RDFS is concerned, all they say is that there are several entities, some of which are properties and are in several subproperty relationships, and there are a few other relationships between the entities. Nothing about order, nothing about sets, nothing about lists, etc.
>>> I really don’t intend any special meaning.
>>> And I don’t think it needs anything special to be useful.
>>> It is not an extension to RDF(S) in any way.
>>> The "ns:author_1” etc could just as easily be "ns:author_a” etc.
>>> If that helps to make it clearer.
>> If this is the case, then why have the names ordered?
> That is the whole point of the exercise.
> So that tools or developers can interpret it as being ordered.
> Note that arrays in many languages are like that - they are actually dictionaries with the keys being numeric values.
>> It would be better to anonymize the names e.g., something like ns:author#xqksywbysnn with the part after the last # chosen at random.  Even better would be to use blank nodes, but this is not allowed in RDF.  But then there isn't much more than just not having the subproperties at all.  If you want the order to be used then you have to do something to make it meaningful in RDFS.
> It appears that is what we disagree on.
>
> What Pat says about David’s suggestion seems to apply pretty much:
>> On 30 Sep 2022, at 08:27, Patrick J. Hayes <phayes@ihmc.org> wrote:
>> That should be an extension on top of RDF, not a revised version of RDF. Imposing syntactic rigor doesn't change anything about RDF itself, either its syntax or its semantics. It would be an RDF app that rejects RDF graphs with 'strange' (including incomplete) collection triples. The rejection would be nonmonotonic, but the underlying RDF would not be. All of which is fine and quite consistent with the current RDF specs, so no new standard is required. Just implement the checks, document them, call it a semantic extension (refer to the specs) and run with it.
>
> Best
> Hugh
>
>>> But there might be tools around supporting the idiom.
>>> A shorthand in Turtle as discussed:
>>>  :dogShow ns:winners ( :ginger :bailey ) .
>>> which if you wanted it to look like the child example, might equivalently be
>>>  :dogShow ns:winners (1 :ginger, 2 :bailey) .
>>> if that also helps to clarify.
>>>
>>> I can also imagine there would be patterns and even shorthands in SPARQL that supported operations such as indexing.
>>>
>>> But it is all entirely captured in the way people use the RDF, not in the RDF itself.
>>>
>>> I am loathe to compare RDF in any way with programming languages, but there are any number of idioms in such languages that show how to combine constructs in agreed ways to achieve commonly-required outcomes.
>>> There are also program-generators that give higher-level constructs that encapsulate such patterns.
>>> And books about the patterns.
>>>
>>> I am worried, of course, that I don’t know whether this pattern is in some RDF book or paper that I have missed.
>>>
>>> Best
>>> Hugh
>>>
>>>> What, if any extra do you want there to be?
>>>>
>>>> The example you give immediately below, on the other hand, looks much better to me.  It is shorthand for something that doesn't appear to imply anything beyond the RDFS meaning of the triples.  The only problem is the URL construction, but I don't think that this is a significant problem.
>>>>
>>>> I agree that having the object of the triple be a set, or bag, or list is something significantly different from having several triples with different objects.
>>>>
>>>>
>>>> peter
>>>>
>>>>
>>>>
>>>> On 9/29/22 16:59, Hugh Glaser wrote:
>>>>> 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 Friday, 30 September 2022 11:41:03 UTC