W3C home > Mailing lists > Public > www-archive@w3.org > February 2002

FW:

From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 13 Feb 2002 12:54:29 +0200
To: <www-archive@w3.org>
Message-ID: <B8901285.E307%patrick.stickler@nokia.com>

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com


------ Forwarded Message
From: Patrick Stickler <patrick.stickler@nokia.com>
Date: Wed, 13 Feb 2002 09:48:36 +0200
To: Pat Hayes <phayes@ai.uwf.edu>
Cc: <bwm@hplb.hpl.hp.com>
Subject: Re: 

On 2002-02-12 21:07, "ext Pat Hayes" <phayes@ai.uwf.edu> wrote:


>> The datatype triple idiom is not local because the following
>> 
>>    xxx ddd "foo" .
>> 
>> in isolation of any schema statements that declare
>> ddd to be an rdfs:subPropertyOf rdf:value and an
>> rdfs:subClassOf rdfs:Datatype an application has no
>> clue that ddd is in fact a datatyping property.
> 
> True, but none of the idioms provide this information in themselves.

Not true. The doublet idiom itself communicates the fact that
datatyping is being used. Any application may interpret a bNode
with an rdf:value with literal object and rdf:dtype property
with URIref as being a doublet idiom. It is recognizable by its
structure and vocabulary alone.

This is not true for the datatype triple idiom.

> And you don't NEED to use the subProperty of rdf:value as a signal
> that something is a datatype: I see that as an *entailment* of being
> a datatype, not a signal. We have to have some way to 'recognise'
> datatype names. Maybe we can just assume that they are globally
> known, ie if you use a name that's in a publicly registered namespace
> that just plain IS a datatype, then you got a datatype, and that's
> all there is to it.

Again, you have to have external, additional knowledge to
recognize the datatype triple idiom as a datatyping idiom. You
have just admitted as much above, by saying that there must be
some way to 'recognize' datatype names, if that idiom is to
be interpreted as a datatype idiom. Do you now see my point?

>> In contrast, given
>> 
>>    xxx rdf:value "foo" .
>>    xxx rdf:dtype ddd .
>> 
>> an application knows, based solely on the doublet
>> idiom, that ddd is a datatype.
> 
> No, it doesn't!  You can perfectly correctly assert that when ddd is
> *any* uriref (and if ddd isn't a datatype it just means the same as
> if you had used rdf:type).

The rdf:dtype property has a pre-defined range of rdfs:Datatype,
provided by the MT itself, no? So why can't some application expect
that (barring bad data) that the URIref is a datatype? Of course it
can.
 
> All the idioms presume some automagical way of recognizing datatype
> names; that's why I proposed rdfs:Datatype as a class, just to be  a
> way to 'declare' datatype names.

But the fact that ddd is-a rdfs:Datatype is why rdf:dtype exists. Thus,
an idiom that uses rdf:dtype embodies that semantics.

IMO, it makes no sense to use rdf:dtype with a non-datatype class. And
in fact, the range constraint would either assert or require that it
is a datatype class. No?

> But that only one idea and I'm not
> very happy about it (either :-) .

Well, that's the idea used by the proposal, which has been
the basis of our 'discussion'. Please don't tell me you have
been basing your arguments on other premises.

>> What makes an idiom 'local' is whether the datatyping
>> is clear from the idiom itself, without any additional
>> knowledge.
> 
> OK, we have been misunderstanding one another. I took 'local' to
> refer to the scope of the datatype name. In your sense, none of the
> RDF idioms is local.

Again, I disagree. See above.

And if none of the idioms are trully local, then we have failed
to provide the users with what they require.

Patrick

--
               
Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com


------ End of Forwarded Message
Received on Wednesday, 13 February 2002 05:53:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 7 November 2012 14:17:16 GMT