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: <Patrick.Stickler@nokia.com>
Date: Wed, 7 Nov 2001 13:41:01 +0200
Message-ID: <2BF0AD29BC31FE46B7887732114404316216FE@trebe003.NOE.Nokia.com>
To: bwm@hplb.hpl.hp.com
Cc: phayes@ai.uwf.edu, 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, 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.

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

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. 
So the constraint fails 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. That's what constraints 
are for. Right?

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.

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.


Received on Wednesday, 7 November 2001 06:41:22 UTC

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