Re: Integrity Checking vs. Typing [Re: RDFS bug "A property can have at most one range property"]

From: Wolfram Conen <conen@gmx.de>
Subject: Integrity Checking vs. Typing [Re: RDFS bug "A property can have at most   one range property"]
Date: Sat, 17 Nov 2001 17:14:42 +0100

> [The context below is RDFS, I briefly discuss two interpretations of
> domain/range (the old one suggested by the RDFS CR and the newer,
> DAMLish interpretation) and claim that choosing either of this
> interpretations has a different impact on deciding the
> disjunctive/conjunctive question. I also discuss the usefulness of both
> interpretations with respect to certain application context and show
> that the newer interpretation is less expressive. Sorry for returning to
> this issue but, as I briefly discuss below, the discussion has mixed
> different issues from the beginning and seldom discussed (application)
> requirements beyond compatibility to DAML/OIL.]

If you are making any claims as to what the RDFS CR suggests, then I think
that you have to consider the second paragraph of its section on
constraints:

  RDF Schema provides a mechanism for describing such constraints, but does
  not say whether or how an application must process the constraint
  information.  For example, while an RDF schema can assert that an
  <code>author</code> property is used to indicate resources that are
  members of the class <code>Person</code>, it does not say whether or how
  an application should act in processing that class information. We expect
  that different applications will use these constraints in different ways
  - e.g., a validator will look for errors, an interactive editor might
  suggest legal values, and a reasoning application might infer the class
  and then announce any inconsistencies.

There you have it---the ultimate cop-out.

From this, I don't see how anyone can claim that the RDFS CR comes down on
the side of integrity constraints.  

Peter F. Patel-Schneider
Bell Labs Research

Received on Sunday, 18 November 2001 12:08:26 UTC