W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > January 2002

Why I cannot live with S

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 25 Jan 2002 18:44:32 +0200
To: RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B8775810.C57F%patrick.stickler@nokia.com>

OK, here are the reasons why I cannot live with S, in no particular
order:

1. Local and global idioms are not compatable in the same knowledge base
without having to resort to a duality of ontolgies, one for local idiom
and one for global idiom. Cohabitatino of local and global idioms
is IMO not just a desiderada, but a requirement.

2. Allows definition of alternate notations in lexical forms (e.g. octal)
which are not supported by the actual datatype. I consider this to
violate the precision of the datatype definition and a bug. It also
means that there are two means to subclass a lexical datatype, either
by reference to a new, subordinate datatype or by localized definition
of (unsupported) lexical notations. TDL has only one single means of
doing so, which respects the boundaries of definition of the datatype
creator. With S, applications (and users) must know not only datatypes
but ontologies of notational variant properties (octal, decimal, inKg,
inOz, etc.) rather than, as with TDL, just datatypes.

3. Requires four (4) URIs for each datatype rather than just one. How
can we ask every authority that has already defined datatypes and given
them URI identity to now go back and mint three more URIs so that RDF
can use them?! TDL has already shown that one URI is sufficient.

4. Requires users to understand the MT to understand which URI
variant to use in which idiom (*.lex, *.map, *.val, or *) rather
than addressing such distinctions in the MT alone, as TDL does.
TDL allows you to talk about those different components, but it
does not require you to do so simply to denote the type of a
literal so that some application knows which value it corresponds
to.

5. Requires additional clarification regarding semantics and use
of rdfs:subPropertyOf relation between properties which convey
datatyping.

6. Use of rdfs:subPropertyOf relation between datatyping property
and non-datatyping property is valid in the absence of domain
constraints but not valid if domain constraints defined.

E.g.

   #Bob ex:age "30" .
   foo:integer rdfs:range xsd:integer.lex .
   ex:age rdfs:subPropertyOf foo:integer .

implies that "30" is a member of the lexical space of
xsd:integer, and this is correct and (even arguably)
intuitive and efficient, avoiding the need for
an anonymous node idiom.

But with the additional constraint

   foo:integer rdfs:domain xsd:integer.val .

which is valid for idioms using anonymous nodes, e.g.

   #Sue ex:age _:1 .
   _:1 foo:integer "30" .

where _:1 is then inferred to denote a member of
the value space of xsd:integer, it also means that,
when these two graphs are merged, #Bob, from the
example above is *also* inferred to be a member of
the value space of xsd:integer, and thus a perfectly
valid use becomes an invalid use.

7. Provides no additional expressive power over TDL
yet requires significantly more machinery and deeper
understanding of the model by users, and is not as
compatable with current idioms as is TDL. Per Occam's
razor, TDL is the simpler and better choice.

8. The S model, particularly literal labeled nodes
participating in graph tidying, precludes any later
adoption of a P+ treatment, which is a more ideal
local idiom than D given the consistency of representation
of local and global typing in the graph; I.e. with P+
the literal object node is not shifted to an anonymous
node as with D, it just stays where it is and the local
type is specified for the literal node directly
via rdf:type -- elegant, efficient, and worth keeping
as a desirable future option. S would prevent this
option forever.


In short, S is too complex, too different from present
usage, able to result in conflicting knowledge on
merge that is valid separately, and too burdensome
from the practical point of URI management to be
acceptable.

If S were the only option, I'd still not choose to
use it. I'd look for some other KR solution that dealt
with datatyping in a more economical and user friendly
manner. But since there is another option, TDL, which
has none of the above faults yet meets all of the
specified desiderada, the choice for TDL is obvious.

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 25 January 2002 11:55:32 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 3 September 2003 09:44:00 EDT