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

On Sat, Oct 1, 2022 at 2:28 PM Nicolas Chauvat
<nicolas.chauvat@logilab.fr> wrote:
>
> 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 ?

What is the point of such mental gymnastics if your conventions would
not be interpreted as you intend by any existing RDF software?

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

:me :positionInPlan9 [ a :complexPosition; :first 2, :second -3 ].
:marty :driveTo [ :date "1985-10-26", :time "09:00", :tz "EST" ] .

Same thing, and no need for new standards.

> 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:57:25 UTC