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

Hi Nicolas

Yes, this makes sense to me too. I've brought it up a few times, it
actually seems like people have been more receptive to it lately. I've been
calling them "composite value types", to which I can add your examples:

  Coordinates
  Polygons
  Fractions
  Addresses
  ComplexNumbers
  ChessPositions

They don't need an IRI, the value's components and its type are enough to
uniquely identify the value. A comparison operation can be canonically
defined for each type.

DateTime is another example, in my opinion DateTime literals are syntactic
sugar for an extremely common composite value type.

Once you have composite value types I think a class of collections—"value
collections"—falls out of that, so collections where members are values and
not IRIs.

Anthony

On Sat, Oct 1, 2022 at 3:25 AM Peter F. Patel-Schneider <
pfpschneider@gmail.com> wrote:

>
> On 9/30/22 13:49, Nicolas Chauvat wrote:
> > Hi Peter,
> >
> > Le Fri, Sep 30, 2022 at 10:42:56AM -0400, Peter F. Patel-Schneider a
> écrit :
> >>> 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.
> > Hmm. Don't we have numbers and strings in RDF ?
> >
> > When you say "the e and the 1 do not have to stick together at all", I
> > understand the following. Is it what you mean ?
> >
> > """
> > You want to write
> >
> >     :me :age 9.876e+01
>
> Yes, your age is 98.76 (years?).
>
> >
> > but it is perfectly fine to write
> >
> >     :me :age_tens 9
> >     :me :age_units 8
> >     :me :age_fraction 76
>
> I don't view this as acceptable, but only because it is bad modelling.
>
> Better would be
>
>    :me :age _x .
>
>   _x rdf:type numbers:Number .
>
>   _x numbers:tens 9 .
>
>   _x numbers:units 8 .
>
>   _x numbers:fraction_two_digits 76 .
>
> as this keeps a single predicate to express years and there can be a place
> that describes what the predicates mean.
>
> But there is still a problem here.  This doesn't say that :me's age is
> 98.76.
> It says that :me's age is something with tens 9, units 8, and fraction
> 76/100.  :me's age could be 198.76, for example.  You could fix this in
> several ways.
>
>
> But it is rather silly to do this kind of indirect modelling as RDF has
> built-in (more or less) literals that do the trick. However, I don't think
> that there are built-in literals for chess positions, and using lists as a
> stand-in isn't a good idea in my opinion.
>
>
> >
> > You want to write
> >
> >     :me :name "Bob"
> >
> > but it is perfectly fine to write
> >
> >     :me :name :_letter1
> >     :_letter1 rdf:first "B"
> >     :_letter1 rdf:rest :_letter2
> >     :_letter2 rdf:first "o"
> >     :_letter2 rdf:rest :_letter3
> >     :_letter3 rdf:first "b"
> >     :_letter3 rdf:rest rdf:nil
> > """
> >
> > Why allow numbers and strings that are compounds of numerals and
> > letters, but not allow compounds of numbers and strings as in a chess
> > position ("e", 1) or a complex number with an imaginary part 2-3i <=>
> > (2, -3) ?
> >
> This is saying that :me's :name is a list, not a string.  This is bad for
> starters, but it is also not stated anywhere what the correspondence
> between
> the lists and strings is.  For example, I might want to be little-endian,
> so I
> mean that the name is "boB". Or I might want to alternative between
> forename
> and surname letters, so the name would be "Bb o".
>
>
> In my view it it much better to make these decisions explicit (and write
> them
> down in the namespace document), which for chess positions would be
> something like
>
> chess:Position rdf:type rdfs:Class .
>
> chess:rank rdfs:domain chess:Position .
>
> chess:rank rdfs:range xsd:string .
>
> chess:file rdfs:domain chess Position .
>
> chess:file rdfs:range xsd:integer .
>
>
> # a chess:Position represents a square of (position in) the standard
> chessboard
>
> # chess:rank is the rank of the position, in chess algebraic notation and
> must
> be between a and h inclusive
>
> # chess:file is the file of the position, in chess algebraic notation and
> must
> be between 1 and 8 inclusive
>
>
>
> Ideally the last two should be represented in RDF(S), but that goes beyond
> the
> capabilities of RDFS.
>
>
>