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: Patrick Stickler <patrick.stickler@nokia.com>
Date: Fri, 07 Jun 2002 14:41:37 +0300
To: ext Dave Reynolds <der@hplb.hpl.hp.com>
CC: RDF Interest <www-rdf-interest@w3.org>
Message-ID: <B92676A1.16526%patrick.stickler@nokia.com>

On 2002-06-07 13:41, "ext Dave Reynolds" <der@hplb.hpl.hp.com> wrote:

>> 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.
> Dave
> [Apologies for the abuse of NTriple and prefix syntax in the examples, I hope
> they are sufficiently clear.]

These are very good points.

In fact, I see now that the schema-rules.n3 module for CWM is actually
doing DAML validation, which illustrates your points above.

Of course, there could be a very useful, constrained interpretation
of RDF Schema constraints that serves the needs of testing for
agreement between different authors of knowledge. I.e.,

   If a property is specified for rdfs:range, then if the object
   is not explicitly declared to be an instance of that type, or
   of a subclass of that type, issue a warning.

   If a property is specified for rdfs:domain, then if the subject
   is not explicitly declared to be an instance of that type, or
   of a subclass of that type, issue a warning.

This does not need the additional power and machinery of DAML or
OWL, yet provides a very useful test for agreement with regards
to shared knowledge. An RDF graph that is "valid" according to
those two tests can be considered a much more reliable and
consistent source of knowledge than one where some or none of
the range, domain, or type declarations sync up.

If the owner of a given property declares that it's values must
be of class foo:bar, and I express a statement using that
property where the object is explicitly typed as foo:bar, then
that says that (a) I understand what is expected by your
property, and (b) I assert that my value is valid according to
those expectations. Now, that might not actually be the case,
but it constitutes a reasonble basis for determining agreement
between disparate users.

I would consider the above to be a reasonable definition of what
an RDF Schema validator would/should provide.

But it does appear to be an open issue, with no clear answer...



Patrick Stickler              Phone: +358 50 483 9453
Senior Research Scientist     Fax:   +358 7180 35409
Nokia Research Center         Email: patrick.stickler@nokia.com
Received on Friday, 7 June 2002 07:37:35 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:07:41 UTC