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

Hi Martynas


> >
> >   :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 could be wrong, but there's a difference in equality comparison isn't
there?

If you did something like the following, where each line came from a
different graph:

  :Alice :at "(50.0, 50.0)"^^ex:coordinate .
  :Bob :at "(50.0, 50.0)"^^ex:coordinate .

Are Alice and Bob at the same place?
Yes

Versus:

  :Alice :at [ :latitude 50.0, :longitude 50.0 ] .
  :Bob :at [ :latitude 50.0, :longitude 50.0 ] .

Are Alice and Bob at the same place?
?

Anthony

On Sat, Oct 1, 2022 at 7:59 PM Martynas Jusevičius <martynas@atomgraph.com>
wrote:

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