Re: Datatyping differences

On 2002-01-28 15:03, "ext Dan Connolly" <connolly@w3.org> wrote:

> On Mon, 2002-01-28 at 04:53, Patrick Stickler wrote:
>> On 2002-01-25 19:22, "ext Dan Connolly" <connolly@w3.org> wrote:
>> 
>> 
>>> What's necessarily
>>> the case is that in S, "30" denotes the same thing in all
>>> interpretaions, but in TDL it doesn't.
>> 
>> But how do you know?
> 
> Because the specification says so.
> 
>> If you don't define the datatype,
>> or if your knowledge migrates out of the circle of your
>> control?
> 
> I don't know how to make sense of that.

It's called the global semantic web, where RDF encoded
knowledge is interchanged around the world between disparate
applications.

>> What if I need "30" to mean something else?
> 
> I doubt you really need "30" to mean something else.
> Zillions of perl and tcl programmers, for example,
> do just fine with just one kind of literal.

But, again, perl and tcl have *BUILT IN DATATYPES*.

Sorry for shouting, but I keep having to repeat that
point.

RDF has *NO* built in datatypes -- therefore, all typing
must have some explicit definition, either locally or
globally, if we are to consistently interpret the literals
to the values they are intended to denote.

You seem to presume that your own, personal applications
will provide the datatyping knowledge for interpretation,
and that in such a context, you have no need of local
or global datatyping mechanisms in RDF -- fine, that is
true so long as you stay in your own little isolated
bubble.

If you expect to interchange knowledge freely around the
world, then you'd better figure out how to express your
datatyping knowledge (and expectations) in a portable
way.

> I expect you just need to talk about something closely
> related to "30", such as the integer whose decimal
> (or octal or ...) numeral is "30". You can do that with S.

The S approach seems contrary to the very purpose of having
standardized datatypes -- so that applications know what
to expect. S allows folks to change the rules on the fly,
and that won't facilitate global interoperability.


>> What if it is
>> supposed to be a monthDay?> How about a human age in years?
>> What if it is a magnitude of kilograms?
> 
> All handled by S, to my satisfaction.

Fair enough, but there are other people who also need
to be satisfied here, no?

> I have working
> calendar applications, stuff that does mathmatical
> calculations, etc., all using S (S-B, in particular).
> See http://www.w3.org/2000/01/sw/ .

I'd love to take a look, but perhaps you could narrow
the reference a bit, eh?

 
>> And how could one assign some other interpretation either
>> in S or TDL if "30" always denotes the same thing?
> 
> One doesn't. If one wants to refer to something other
> than the two character string '3' followed by '0',
> one uses a different expression than "30".

And *how* dear sir will an application know what that
*other* expression is supposed to mean.

You seem to have a view that RDF is like a programming
language with a well defined, native, built in set
of datatypes with disjunct lexical spaces where there
is a an implicit datatype membership determinable for
every lexical form encountered.

I'm not sure you are evaluating these datatyping
proposals with the same scope of expectation that
others (myself included) are.
 
>> I think that your argument has nothing to do with any
>> limitation of TDL. I think you will encounter the
>> same problems with S as well if you leave datatyping
>> knowledge implicit in your application and yet expect
>> your data values to be portable to other application
>> spaces with the same interpretation.
> 
> After several months of implementation experience with S,
> I have not run into any problems with S.

Good for you. How much of your data is globally exchanged
with other applications? And do those applications share
your implicit expectations regarding datatyping of literals?

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 Monday, 28 January 2002 08:35:02 UTC