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

On 9/29/22 15:45, Nicolas Chauvat wrote:

> Hi List,
>
> Let's say I forget about cautiously staying out of a discussion where
> I do not think I understand everything that has been said about the
> difference in the semantics of lists/array/bags/sequences... and I
> step in saying that it seems to me people are in fact describing
> different use cases.
>
> In the Python programming language, there is a difference between a
> tuple (immutable) and a list (mutable).
>
> Could it be that some people here advocate having tuples as objects of
> RDF triples, while others state that we already have lists by using
> the rdf:first and rdf:rest predicates ?

RDF is not a programming language.  Trying to look at RDF using notions from 
programming languages can often produce problems, and indeed does here.  RDF 
lists were developed to support a notion of completeness that was lacking from 
RDF containers.  Mutability is not a notion in RDF at all - there is no way 
to, for example, change the object of a triple.  Instead RDF has the principle 
of monotonicity - adding new triples to an RDF graph does not remove any of 
the information inherent in the meaning of the graph.

Thinking back on the development of RDF lists it might have been better to 
just add an rdf:length property to RDF sequences.  That gives you a useful 
sequence class.  But the problem is that it doesn't fix bags and 
alternatives.  All uses of bags and alternatives would have to be rewritten 
using rdfs:member and rdf:size, a new property, and not the rdf:n properties 
and also the use of the rdf:n properties for bags and alternatives 
deprecated.  It was ever so much easier to just leave RDF containers alone.  
It also meant that the infinite number of container membership properties 
could more easily be ignored.

>
> One would use a tuple for a value that is composed of several "sub-values":
>
>    chess:whiteKing chess:atPosition ("e", "1")
>
> and these tuples could be used as items in a list if necessary:
>
>    chess:whiteKing chess:moves :pos1
>    :pos1 rdf:first ("e", "1")
>    :pos1 rdf:rest :pos2
>    :pos2 rdf:first ("f", "2")
>    :pos2 rdf:rest rdf:nil


This is trying to say, I think, that the white king moves from position e1 to 
position f2.  But as far as RDF is concerned it is instead saying that the 
white king has a moves relationship to a list, which isn't good modelling at 
all.  Instead there should be a separate Moves class which uses (at least) 
from and to properties, of course provided that one wanted to model chess 
moves this way.


>
> My understanding is that we do not have the tuple construct in RDF and
> would have to write
>
>    chess:whiteKing chess:atPosition :pos
>    :pos chess:positionLetter "e"
>    :pos chess:positionNumber "1"
>
> except that neither
>
>    chess:whiteKing chess:atPosition :pos
>    :pos chess:positionLetter "e"
>    
> nor
>
>    chess:whiteKing chess:atPosition :pos
>    :pos chess:positionNumber "1"
>
> alone would make any sense, for "e" and "1" have to stick together in
> a tuple for the position to exist / be defined.

Actually the e and the 1 do not have to stick together at all. The first of 
the neithers is saying that the white king is at something that has position 
letter e.   (Again ignoring whether this is a good way of representing chess 
pieces, chess boards, and chess positions.)  This is a reasonable thing to say 
and, although not as common as providing a full position description, 
certainly could come up as information to represent and transmit.  One very 
good reason to use RDF is to allow for this sort of incomplete description.

> Of course I could encode the position as the string "e1" but then I
> would have to parse it.
>
> Generalizing this idea would mean that for any compound value, I could
> write a pair to encode/decode it to a string and write:
>
>    my:individual my:property "SoMeEnc0d3dV4lue"^my:literaltype
>    
> In a way, having a definition for tuples in RDF would be equivalent to
> defining a generic encode/decode (or serialize/deserialize) mechanism.
>
> Is any of this making sense for someone else than me ? :)
>

Received on Friday, 30 September 2022 14:43:12 UTC