W3C home > Mailing lists > Public > www-rdf-interest@w3.org > June 2002

Re: rdfs:isDefinedBy (Was Re: Representing DCMI semantics asRDFschemas versus Web pages)

From: Dave Reynolds <der@hplb.hpl.hp.com>
Date: Fri, 07 Jun 2002 11:41:23 +0100
Message-ID: <3D008DD3.2A148B89@hplb.hpl.hp.com>
To: Patrick Stickler <patrick.stickler@nokia.com>
CC: RDF Interest <www-rdf-interest@w3.org>

> The higher level of RDF validation is RDF Schema validation, which tests
> that range and domain constraints match the subjects and objects of
> actual statements. The W3C RDF validator does not perform such checks.

Actually, AFAIK, such constraints can't be expressed in pure RDFS. So it is
entirely reasonable for the W3C validator to not perform checks for them. An
application could choose to interpret RDFS domain/range declarations as somehow
exclusive and checkable but that is not part of the RDFS specification and so
should not be part of the W3C validator.

To (ab)use Graham's recent example on the multiple rdf:type issues. If I have an
RDF schema that includes:
   ex:transport  rdf:type   rdfs:Property .
   ex:transport  rdfs:range ex:MeansOfTransport .

and I then check an RDF file containing:
   urn:me      ex:transport  urn:Dobbin .
   urn:Dobbin  rdf:type      foo:Horse .
Then all I can conclude is "that is interesting, urn:Dobbin must be both a
foo:Horse and an ex:MeansOfTransport". This might or might not be reasonable. 

If we then encounter the declaration:
   ex:MeansOfTransport rdfs:subClassOf ex:MechanicalDevice .
then we would conclude that urn:Dobbin is also an ex:MechanicalDevice. 
Given the suggestive names then as humans we might be less happy with something
being both a Horse and a MechanicalDevice but for RDFS processing there is no
reason to believe something can't be both.

To express that two classes don't overlap you currently need either DAML or some
additional application-specific assumptions or conventions.


[Apologies for the abuse of NTriple and prefix syntax in the examples, I hope
they are sufficiently clear.]
Received on Friday, 7 June 2002 07:20:26 UTC

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