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 15:48:39 +0300
Message-ID: <2BF0AD29BC31FE46B788773211440431621615@trebe003.NOE.Nokia.com>
To: pfps@research.bell-labs.com
Cc: devon@taller.pscl.cwru.edu, www-rdf-interest@w3.org

>   John age "Susan" .
>   age rdf:range xsd:integer .
> would be invalid in an XML Schema extension to RDF.

Right. The key word here is "extension".

RDFS says nothing about the validity of such statements. It
can only say that two statements conflict if they assert
different types (locally for the value and via rdfs:range
for the property).


It is XML Schema that defines validity of "Susan" in terms
of 'xsd:integer', not RDFS.

> > But RDF should not, and cannot care. An particular *system*
> > will likely care, but not the RDF or RDFS layer explicitly.
> Why not and why not?  RDFS certainly cares about the type of 
> entities.  

Yes, about the *type* of entities, not whether those type assertions
are valid.

> If
> datatypes are not accessible to RDFS then rdfs:range will act rather
> strangely.

No. RDFS only concerns itself with types. Not whether it is true
that some value *really* is of that type.

If I say that some particular value "foo" of a property is a
"string" and you say it is an "integer" then RDFS should let
us know that there is a conflict of opinion, but it cannot
say whether *either* of us is "correct" because it doesn't
itself *know* what a "string" or "integer" is.

> > 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?
> I come down firmly for the descriptive reading of rdfs:range. 

I believe I do as well. No real disagreement there. I was merely
pointing out how some might see it as being prescriptive in a
particular scenario.

>  I can see
> that there are some reasons for having a prescriptive 
> reading.  However I
> can not image how a mixed reading would work.  (By the way, you may be
> confusing descriptive and prescriptive above.)

Not confusing them. Stating that the prescriptive reading is only
reasonable in a single scenario -- where both local type is defined
and rdfs:range is defined. Otherwise, only the descriptive
reading is reasonable, and thus, it seems proper to view rdfs:range
as descriptive in all cases, with the exceptional "possibly
prescriptive" scenario treated as a "coincidence" (for lack of a better 

> > 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.
> I suggest that the RDF Core WG is not chartered to do any 
> datatyping.  

Maybe. But they could clarify several issues relating to 
datatyping and in particular, how different subgraphs equate
to the same data type knowledge. That is not defining a datatype
scheme, only providing guidelines for employing datatype
schemes in a reasonably consistent fashion.

> My
> concerns about datatyping with respect to the WG all center 
> around the fact
> that the way the WG was proceeding was precluding reasonable 
> datatyping
> schemes.

I agree. No datatyping solution is better than a discriminatory
solution (e.g. in favor of XML Schema only).



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 08:48:59 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:44:32 UTC