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

Hi Peter and List,

Le Fri, Sep 30, 2022 at 04:18:09PM -0400, Peter F. Patel-Schneider a écrit :
> 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 .

Yes, I agree my example would be better put this way, thank you.

> 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

That's exactly my point. There are literals for numbers, that are
compounds of numerals but not for other values that would be compounds
of say, characters and numerals (as in chess positions or complex numbers).

> and using lists as a stand-in isn't a good idea in my opinion.

I am *not* saying we should use a list for chess positions, I am
saying it would be nice to have a way to define values that are
compounds of characters and numerals (let's start with that, but
(date, time, timezone) would also be nice, if you ask me).

> This is saying that :me's :name is a list, not a string.

But a string *is* a list of characters and characters are often seen
as lists of bits, aren't they ? I am not inventing anything by
representing a string as a list, just making a design decision or
chosing an abstraction level that's fit for my domain.

> 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".

I am not sure I follow you here. When you say you may want to be
little-endian and write

  :me :name "boB"

aren't you supporting my previous point by saying that you encoded the
name "Bob" in a string as "boB" ?

You are not changing the name, just changing how you represent it with
RDF triples.

Does it mean that you agree with the fact that there is some
implicit/obvious encoding/decoding for numbers and strings, but not
for other types (yet) ?

> 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
> [...]
> Ideally the last two should be represented in RDF(S), but that goes beyond
> the capabilities of RDFS.

Yes, you could use two predicates rank and file, but I would like to
design my vocabulary so that you can not state one without the other,
by making them stick together in a compound value as in (one character,
one numeral).

I agree I could model things as:

  :name :range :nameString
  :firstChar :domain :nameString
  :firstChar :range :Character
  :secondChar :domain :nameString
  :secondChar :range :Character
  :thirdChar :domain :nameString
  :thirdChar :range :Character
 
that would allow me to write

  :me :name :bobsname
  :bobsname :firstChar "B"

but since I am only interested in the complete name, what is the point
in designing a model that would allow me to assert just some letters of a
name ?

Would you treat my other example, the complex number, in the same way and use
two predicates realPart and imaginaryPart ?

What would you think of something like this ?

  :me :positionInPlan9 (2, -3)^:complexPosition
  :marty :driveTo ("1985-10-26", "09:00", "EST")^:timeDateTZ

I very much doubt to be the first person to suggest this kind of
thing. Could anyone point me to archives of previous discussions about
this ?

-- 
Nicolas Chauvat

logilab.fr - services en informatique scientifique et gestion de connaissances

Received on Saturday, 1 October 2022 12:22:48 UTC