W3C home > Mailing lists > Public > w3c-rdfcore-wg@w3.org > November 2001

RE: ACTION 2001-11-02#02: Datatyping use-cases from CC/PP

From: Pat Hayes <phayes@ai.uwf.edu>
Date: Thu, 8 Nov 2001 18:02:08 -0600
Message-Id: <p05101018b810cb268d77@[]>
To: Patrick.Stickler@nokia.com
Cc: w3c-rdfcore-wg@w3.org
>  > -----Original Message-----
>>  From: ext Brian McBride [mailto:bwm@hplb.hpl.hp.com]
>>  Sent: 07 November, 2001 13:16
>>  To: Stickler Patrick (NRC/Tampere)
>>  Cc: phayes@ai.uwf.edu; w3c-rdfcore-wg@w3.org
>>  Subject: Re: ACTION 2001-11-02#02: Datatyping use-cases from CC/PP
>>  Patrick.Stickler@nokia.com wrote:
>>  [...]
>>  > Anyway, the gist is that if both a local type and a range
>>  > are defined, then the range can be seen as prescriptive such
>>  > that a value can be deemed invalid if the local type is
>>  > not equivalent to or a subclass of the range type.
>>  Given the capabalities of RDFS, how could you know that one
>>  type is NOT a
>>  subClassOf another?
>>  Brian
>Well, I'm presuming that if no rdfs:subClassOf statements
>were encountered which define that relation prior to
>testing the range constraint,

What does 'prior' mean? There is no temporal ordering on RDF statements.

>  that one could not know for
>sure that the type absolutely was not a subtype, ever,
>but insofar as the knowledge present at hand, it would not
>be and the test of the constraint should fail.

That would not be a valid assumption. In general, you should not make 
any closed-world assumptions; more information can always arise 
later. If something follows from the knowledge presently at hand, 
then it must also follow from any larger set of knowledge; so if a 
later addition *could* consistently assert a subClassOf relation, 
then you cannot assume that such a relation is false.

>This is of course, presuming that the type is defined locally
>and a range is defined, otherwise the test can't even be made.

What sense of 'locally' do you have in mind? (Local to what?)

>But this is a good thing. After all, constraints are how we
>ensure proper operation of our systems. If I define a range
>constraint that says that some property value must be
>an xsd:integer and thus my system expects decimal notation, and
>I get [ rdf:value "12"; rdf:type foo:bar ] where I have no clue
>what data  type 'foo:bar' corresponds to, then I can't be *sure*
>that I have a lexical form that corresponds to an integer expressed
>in decimal notation. It could be a value in hexidecimal notation.

OK so far, I think. You know that the range of something is 
xsd:integer, and you know that the value of something else is "12" , 
but you don't have any datatype information to enable you to 
interpret that. OK.

>So the constraint fails

Why? Nothing 'fails' here; you just have incomplete information. 
However, this is the normal case; information is often incomplete.

>as it should, since in this case, an RDFS
>processor cannot satisfy that foo:bar is a subClassOf xsd:integer
>and the data is rejected as unreliable.

NO!! Absolutely not. You cannot 'reject' data as unsuitable just 
because it is incomplete. New data might arise at any time.

>That's what constraints
>are for. Right?

Who mentioned constraints?

>If I later load some schema that says that foo:bar is a
>subclass of e.g. xsd:decimal, great, now the constraint is
>satisfied and I know both that the value is a valid xsd:integer
>(since xsd:decimal is a subClassOf xsd:integer) and I know that
>the lexical form follows decimal notation. OK, now I can use it.

But you have already 'rejected' it, right? (What has happened to it? 
Did it get erased, or sent back as incomplete, or what? I presume 
'reject' didn't just mean 'ignore', did it?)

>It's all about having the information needed to interpret
>the lexical form. Some of that information is local. Some is
>in the schema. Both are needed.

IHMC					(850)434 8903   home
40 South Alcaniz St.			(850)202 4416   office
Pensacola,  FL 32501			(850)202 4440   fax
Received on Thursday, 8 November 2001 19:01:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:24:06 UTC