W3C home > Mailing lists > Public > www-rdf-interest@w3.org > October 2001

RE: RDFCore Update

From: <Patrick.Stickler@nokia.com>
Date: Fri, 19 Oct 2001 13:35:23 +0300
Message-ID: <2BF0AD29BC31FE46B78877321144043114C035@trebe003.NOE.Nokia.com>
To: pfps@research.bell-labs.com
Cc: devon@taller.pscl.cwru.edu, www-rdf-interest@w3.org


> -----Original Message-----
> From: ext Peter F. Patel-Schneider 
> [mailto:pfps@research.bell-labs.com]
> Sent: 19 October, 2001 01:01
> To: Stickler Patrick (NRC/Tampere)
> Cc: devon@taller.pscl.cwru.edu; www-rdf-interest@w3.org
> Subject: RE: RDFCore Update
> 
> 
> From: Patrick.Stickler@nokia.com
> Subject: RE: RDFCore Update
> Date: Fri, 19 Oct 2001 00:12:41 +0300
> 
> [...]
> 
> > This ambiguity about whether rdfs:range is descriptive or
> > prescriptive (or both) was pointed out recently in a post
> > by Ora Lassila, and perhaps could be addressed in conjunction 
> > with standardized methodologies/mechanisms for data typing.
> 
> I don't know how you could handle a prescriptive meaning for 
> rdfs:range in
> an open environment.  You certainly can't say that the target 
> object has to
> belong to the range when the triple is read because there is 
> no notion of
> order in RDF.  All other prescriptive readings result in 
> non-monotonicity,
> which is not a good idea in the web, IMNSHO.
> 
> By the way, the model theory firmly comes down on the 
> descriptive side, as
> do (almost) all reasonable model theories.
> 
> > Cheers,
> > 
> > Patrick
> 
> Peter F. Patel-Schneider

It is also important to note that, unless RDF itself defines
a single, standard mechanism for data type validation, it can
do nothing more than ensure that statements about data types
do not conflict.

I.e., if I define

<abc:property>
   <rdf:value>foo</rdf:value>
   <rdf:type rdf:resource="xyz:string"/>
</abc:property>

<rdf:Description rdf:about="abc:property">
   <rdfs:range rdf:resource="xyz:integer"/> 
</rdf:Description>

An RDF schema validator can complain that the defined types
conflict. However, if I define

<abc:property>
   <rdf:value>foo</rdf:value>
   <rdf:type rdf:resource="xyz:integer"/>
</abc:property>

<rdf:Description rdf:about="abc:property">
   <rdfs:range rdf:resource="xyz:integer"/> 
</rdf:Description>

Then it will be, *must* be, satisfied with that, since
RDF does not define itself what "xyz:integer" is and
cannot therefore test that "foo" is not an instance of
that data type.

Thus, just as one may argue that "foo" is not an integer,
it is just as out of scope for RDF as arguing that any
statement is "false".

The determination of true or false is outside the scope
of RDF, right?

We must employ higher layers to do that. In the case of
typed data literals, we can use an XML Schema validating
parser (or a portion of it), or some other data type
checking layer, which knows what an "xyz:integer" is and
can tell us if "foo" is one.

But RDF should not, and cannot care. An particular *system*
will likely care, but not the RDF or RDFS layer explicitly.

Thus, at best, rdfs:range can only be prescriptive in the
context of an explicitly locally typed value, and only
insofar as the type URIs are compatible. Otherwise, it should
be seen as primarily descriptive. Eh?

So I think that the RDF Core WG should focus on (a) clarifying
just what RDF or RDFS actually define/constrain with regards to
data type declarations, and (b) define the various equivalent
means by which data type can be declared or inferred. But
RDF should not, IMO, adopt an actual data type validation
mechanism a'la XML Schema which can tell us if e.g. "foo"
is an "xyz:integer" or not. That should be left to each
individual data type scheme, and no particular data type
scheme should have any special status over any other.

Cheers,

Patrick

--
Patrick Stickler                      Phone:  +358 3 356 0209
Senior Research Scientist             Mobile: +358 50 483 9453
Nokia Research Center                 Fax:    +358 7180 35409
Visiokatu 1, 33720 Tampere, Finland   Email:  patrick.stickler@nokia.com
 
Received on Friday, 19 October 2001 06:35:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 7 December 2009 10:51:52 GMT