Re: relating S-A and S-B [was: TDL conflicts with the "duh!" requirement]

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

> On Mon, 2002-01-28 at 08:33, Patrick Stickler wrote:
>> On 2002-01-28 15:29, "ext Dan Connolly" <connolly@w3.org> wrote:
> [...]
>>> It's true that S-A works better locally, and S-B works
>>> better globally, and you have to choose one or support
>>> both or whatever. This is an issue with S. But I find
>>> it acceptable.
>> 
>> Nope. Sorry. You can't use both. They are not compatible
>> in the same knowledge base.
> 
> I'm not sure what you mean by "not compatible".

What rdfs:range means in S-A versus what it
means in S-B.

>>> No, it's based on a design choice that whatever "111"
>>> denotes, it denotes that same thing in all interpretations.
>> 
>> Hmmm.... Is this an application design choice?
> 
> No; it's a design choice for RDF 1.0...
> one that I think is already made, in the
> deployed applications, by the way.

Well, since RDF 1.0 doesn't define datatyping, it's
no surprise that it would be addressed by applications.

>> How will my application know about your application's
>> typing expectations when I get your data?
> 
> I think that anything that claims to know RDF
> should know that "111" denotes the same thing
> everywhere.

My and Jeremy's examples show that this clearly
is not the case, that the literal "111" in
isolation of datatyping context (either expressed
in the RDF graph or imposed by an application
environment) does not mean the same thing everywhere.

If literals mean the same thing everywhere, then why
do we bother with URIs? Let's just use literals for
the labels of all resources, since they are never
ambiguous. We could then bypass the whole URI taxonomy
issue...

>>> Nope. All I need to say is that "111" denotes
>>> the same thing in all interpretation and
>>> the inference follows.
>> 
>> Well, you're going to have a very tough
>> time freely exchanging knowledge with others
>> when your expectations about what
>> are (to RDF) local names are not shared
>> globally by others.
> 
> Yes; that's why this must go in the RDF 1.0 spec.

No. I meant that if "111" denotes an integer in
decimal notation rather than e.g. an integer
in binary or octal or hexidecimal notation, or
perhaps the string name of a club for folks who are
one hundred and eleven years old, then how are you
going to communicate that expectation/constraint
to other applications?

>>> Yes, the scalar datatype.
>> 
>> So RDF datatypes can only be integers or strings?
> 
> RDF datatypes can span the range of human expression,
> more or less. RDF literals better denote just
> one thing each, though. Call it a string if you like,
> or a scalar, or whatever.

OK, I meant "lexical datatypes". So at least
now I understand you, I think, to be saying that
insofar as RDF encoded knowledge is concerned,
literals are just strings, and we can't express
in RDF their interpretation beyond their being strings
(or maybe integers, if they parse OK as integers).

So you really are supporting neither proposal,
but saying we should stick to what is defined
by 1.0 and let the applications handle the
rest. 

Right?

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 10:53:09 UTC