From: Sandy Nicholson <sandy.nicholson@quadstone.com>

Date: Tue, 23 Jul 2002 16:40:26 +0100

To: Jonathan Borden <jonathan@openhealth.org>

Cc: www-rdf-logic@w3.org, www-rdf-comments@w3.org

Message-ID: <20020723154026.GA2081@quadstone.com>

Date: Tue, 23 Jul 2002 16:40:26 +0100

To: Jonathan Borden <jonathan@openhealth.org>

Cc: www-rdf-logic@w3.org, www-rdf-comments@w3.org

Message-ID: <20020723154026.GA2081@quadstone.com>

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( SandyReceived on Tuesday, 23 July 2002 11:40:37 UTC

*
This archive was generated by hypermail 2.3.1
: Tuesday, 6 January 2015 21:15:18 UTC
*