W3C home > Mailing lists > Public > www-rdf-logic@w3.org > July 2002

Re: Input sought on datatyping tradeoff

From: Thomas B. Passin <tpassin@comcast.net>
Date: Thu, 11 Jul 2002 19:03:22 -0400
To: www-rdf-logic@w3.org
Message-id: <000801c2292f$27a7b820$fe193044@tbp1>

[Brian McBride]

>    <Jenny> <ageInYears> "10" .
>    <Jenny> <testScore>  "10" .
> Should an RDF processor conclude that the value of Jenny's ageInYears
> property is the same as the value of Jenny's testScore property?

I do not think this question is well posed.  On what basis will an RDF
processor use these literal values for anything?  They cannot be used as the
subjects of statements as things stand now.  RDF as a language does not
really provide the ability to do anything except provide a graph or data
store of triples.  To answer the question as posed, we must imagine some
logic processor or query engine, or RDF processor with extensions.  Are we
then trying to imagine what would support some "reasonable" set of
processors? Or are we really talking only about "RDFS-aware" processors?
> Test A3:
>    <Jenny> <ageInYears>   "10" .
>    <Film>  <title>        "10" .
> Should an RDF processor conclude that the value of Jenny's age property is
> the same as the value of the Film's title property?  If the value the
> <ageInYears> property is an integer, and the value of the <title> property
> is a string, they are not the same thing and are thus not equal.
> The answer must be the same for all three of these A tests.
I do not see why this would be necessary and I object to it.  If we are to
think about comparing literals and concluding equality, I think this should
only be allowed if the predicates have some relationship, like one being a
subproperty of the other.  According to this, in test A3 the two would not
be able to be compared, any more than two times can be compared if one of
them is in UTC and the other does not specify its UTC status.

Test A1 uses the same predicate and so could be compared.  It is obvious
that there can be disadvantages to doing so (e.g., one could be in octal and
the other in decimal) but also obvious that triples will continue to be
written like this.

If we are thinking ahead to processors that add capability beyond RDF, there
could be some way to tell the processor to cast or not to cast the literals.
This might make more sense than to be draconian about the useage of literals
in RDF.

> Now for a different kind of test.  How do the values of the two idioms
> Test D:
>    <Jenny>      <ageInYears> "10" .
>    <ageInYears> rdfs:range xsd:decimal .
>    <John>  <ageInYears>   _:a .
>    _:a     xsdr:decimal   "10" .
> Should an RDF processor conclude that Jenny and John have the same
> age?  [Note: in this example the range constraint is expressed using
> rdfs:range.  We may have to introduce a special datatyping range property,
> but that is an independent detail for now.]
> It is not possible to have the answers to Tests A and Test D both be
> yes.  Either the A's can be yes or D can be yes, but not both.  We have to
> decide which of these is the most important to have.

Why not both?  Test D is not at all the same kind of thing as Test A.  In
Test A, we compare objects with the same or different predicates.  In Test
D, we compare an object of a blank node where a second triple expresses a
property or constaint on the object, with the object of another triple where
yet another triple expresses a constraint on a predicate.  Test D is much
more complex than Test A.  Because of that, I do not think the two are
comparable, and so both could be "yes".

Before settling on some answer, it would be best to spell out the semantics
of the two Tests. You try to do that below for Test A, but say nothing about
Test D.  I do not think it is obvious how to relate a constraint on a
predicate to a constraint on an object, that is why I ask for the semantics.
If we knew the proposed interpretation of this comparison, it would be
easier to assess the question.


Tom P
Received on Thursday, 11 July 2002 19:04:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 March 2016 11:10:38 UTC