Re: Datatypes, syntax and equality

Jonathan,

I wrote:

> >     <John> <AgeInYears> "20"
> >     <Mary> <AgeInMonths> "20"
> >
> > Comparing John's AgeInYears and Mary's AgeInMonths using
> > equal(string) or equal(decimal) is fine. So you might conclude,
> > as above, that the two values are equal. However, you forgot to
> > consider the equality predicate equal(months). Using this predicate,
> > the two are certainly not equal. Of course, I wasn't able to obtain
> > all the information that I needed from the string "20" - but then
> > again the elements of RDF triples don't occur in isolation.

You replied:

> That is the point. Unless there is a _syntactic distinction_ between a
> string that is interpreted _only_ as years vs. _only_ as months, then
> "20" might be either years or months.

I agree. But I was only using this to show that your earlier example of
equality testing couldn't be construed as valid. I only changed the
details to avoid being too contrived. I'll now be contrived. You wrote:

>>> :John :age "20" .
>>> :Mary :size "20" .
>>>
>>> Does John's age equal(string) Mary's size: YES
>>> Does John's age equal(decimal) Mary's size:YES
>>> Does John's age equal(binary) Mary's size: illegal syntax for type
>>>
>>> it is YES for all valid equality functions => YES

But you didn't consider my equality function equal(contrived), which
I now (partially) define as follows:

 x's age equal(contrived) y's age
   iff x's age equal(decimal) y's age

 x's size equal(contrived) y's size
   iff x's size equal(hexadecimal) y's size

 x's age equal(contrived) y's size
   iff there exist strings s and t and an integer n such that:
     *  x <age> s
     *  y <size> t
     *  s is a decimal representation of n
     *  t is a hexadecimal representation of n

If you allow this as a valid equality function, then John's age is _not_
equal to Mary's size for all valid equality functions.

This may seem contrived, but it's really just a case of a fixed numeric
interpretation of the string literal being in some sense encapsulated in
the interpretation of the property at the centre of the triple.

It'll probably turn out that we're both arguing the same thing here. :o)

You also wrote:

>>> When using typed literals the equality function is predicated on the
>>> types of the arguments
>>>
>>> :John :age xsd:decimal"2" .

I responded:

> > Why extend the relatively simple idea of triples to quadruples, as you
> > appear to be doing here (necessitating a more-complex RDF model theory)
> > when instead you could write the following two triples?
> >
> >     <John> <Age> :_a
> >     :_a <xsdr:decimal> "2"
> 
> Quads? I don't follow. xsd:decimal"2" is intended to be a token -- read:
> 'the value obtained by interpreting the lexical string "2" as xsd:decimal'
> hence
> 
> xsd:binary"10" = xsd:decimal"2"

OK - I understand what you're doing. All I'm saying is that you're
presenting four pieces of RDF-ish information here:

    <John>         a resource
    <age>          a resource
    <xsd:decimal>  a resource
    "2"            a literal value

Had you instead written

    <John> <age> 2

with the `2' being a new kind of syntactically distinguished literal
- a numeric literal as opposed to a string literal - I'd have been happy
to accept that you were dealing with a triple (in a modified RDF).

Even if you choose to consider `<xsd:decimal>"2"' as a `token', all you're
doing is temporarily wrapping up two pieces of information in an arbitrary
package. My point is that the model theory still has to deal with the
added complexity.

> The reason not to do the b-node thing is to avoid the problem Brian McBride
> points out in:
> http://lists.w3.org/Archives/Public/www-rdf-logic/2002Jul/0080.html

I'm not sure what you mean by `the b-node thing' and I'm afraid your
reference doesn't help make it any clearer. :o(

Sandy

Received on Tuesday, 23 July 2002 11:40:37 UTC