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

Re: why not take just the 2 ???

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Sun, 03 Feb 2002 11:40:41 +0200
To: "ext jos.deroo.jd@belgium.agfa.com" <jos.deroo.jd@belgium.agfa.com>, RDF Core <w3c-rdfcore-wg@w3.org>
Message-ID: <B882D239.CFC4%patrick.stickler@nokia.com>
On 2002-02-03 1:03, "ext jos.deroo.jd@belgium.agfa.com"
<jos.deroo.jd@belgium.agfa.com> wrote:

> ??? why not take just the 2
> 
> dt-local = S-A + TDL-local
> 
> :Jenny :age [ xsd:int.map "30"; rdf:dtype xsd:int.val ] .
> 
> dt-global = S-B
> 
> :Jenny :age "30" .
> :age rdfs:range xsd:int.lex .
> 
> --
> Jos De Roo
> 
> 

Firstly, the above is not TDL-local. TDL-local
uses rdf:value to bind the literal (lexical form)
to the bnode and the value of rdf:type or rdf:dtype
is the URI of the datatype, not the value space.

Secondly, the above approach doesn't really do
anything more than TDL-local and TDL-global
except require that we have 4 URIs for each
datatype rather than one and preclude use of
both idioms together (see next)

Thirdly, having the range of a literal node as
*.lex and the range of a bnode *.val is precisely
the problem that S has with cohabitation of its
local and global idioms. One cannot then define
a range for the local idiom intended to express
a constraint without conflict of interpretation
(is the bnode *.lex or *.val?)

There is already alot of negative opinion about
how the RDF datatyping proposals are referencing
XML Schema datatype URIs. I suspect that any
solution that uses anything other than the pre-
defined (or user defined) single URIs for each
datatype will not be acceptable.

The TDL approach of having the datatype URI denote
the entire datatype, not just one of its components,
seems to sync the closest with the desires of the
XML Schema and "don't graze on other's grass" folks.

I think one key difference between the TDL and
S "philosophies" is that S wants/needs to use a
unique URI for each component of a datatype
in order to make the significance of those components
explicit in the representation, whereas TDL uses the
single URI of a datatype to define a context within
which the MT provides a consistent interpretation for
the lexical form (literal).

I concede (as I always have) that having an MT
that works and meets folks expectations/needs is
imperative -- but much of our discussion seems to
be focusing solely on the state of the MT and
does not sufficiently consider usability, efficiency
of expresssion, and in short, what the ramifications
will be for "common users".

Multiple URIs, synonymous idiom-specific vocabularies,
etc. etc. may make the MT easier to write, but it
makes life in general much harder for the user, and
after all, at the end of the day, if RDF datatyping
is percieved to be too complicated, regardless of
how beautiful and correct the MT is, folks won't use
it. Eh?

The S approach makes things easier for writing the
MT but harder for the users. Who should we be trying
most to make things easiest for? I think the users.

Please let us ask ourselves, not simply does it work,
but does it make life easier for the majority of folks
who want to use RDF for common metadata and knowledge
management tasks. And the majority of folks are not
necessarily those building complex KR or expert
systems to explore theorem proving, etc. but folks
who simply want to describe things and find things
based on those descriptions.

RDF is already percieved as difficult and confusing
enough -- we don't need to add to that perception by
having a cumbersome datatyping solution (if we can
by any reasonable means avoid it).

I think we should perhaps add an item to the desiderada,
that the solution be as simple and easy to use as
possible, even at the expense of a more complicated
MT.

Cheers,

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Sunday, 3 February 2002 04:39:39 EST

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