Re: Question: DAML cardinality restrictions

From: David Allsopp <dallsopp@signal.dera.gov.uk>
Subject: Re: Question: DAML cardinality restrictions
Date: Mon, 02 Apr 2001 16:14:19 +0100

> 
> 
> "Peter F. Patel-Schneider" wrote:
> > 
> > This is not a naive question at all.
> > 
> > DAML+OIL does not require that you have the actual father, just that you
> > know that you have one.  This is very different from the situation in
> > databases.  To see why it is a good thing to be able to talk about your
> > father without knowing who he is, all you have to do is remember the
> > problems with (and endless debate about) null values.
> 
> I think I understand that; my question was from the point of view of
> dealing with actual data representing specific instances of a class.  In
> such a scenario, I would perhaps be using the DAML+OIL ontology to
> validate my data (and probably make inferences about the data).  My
> question is, how could this process work?
> 
> Let's say I have data for a person 'A', but not for their father. Does
> this mean my data do not conform to the ontology/schema (since A can't
> point to a father instance in my small model of the world)?

Not at all.  There is nothing in DAML+OIL that requires the data to make
everything explicit.  It is perfectly OK to require that people have
exactly one father, and also have object that belong to that class and have
no known specific father.

> Alternatively, if it is OK for A to not point to a specific father, then
> the cardinality restriction isn't doing anything; it isn't restricting
> anything! As far as one can tell from the data, A does _not_ have a
> father.

NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! NO! 
I cannot be more emphatic that this is ******NNNNNOOOOOOTTTTT****** the
case.  You have to realize that there are more kinds of representation
languages than data bases.   Just because you haven't specified the father
does not mean that there is no father.  

For example, if you used (an extension of) first-order logic for all this,
you might have something like:

	Ax person(x) => E!y father(x,y)
		every person has exactly one father

	person(joe)
		joe is a person

From this you cannot infer that joe does not have a father, even though you
have not provided one.  On the contrary, from this you can conclude that
joe does have a father.

It is possible to specify that joe does not have a father, but this has to
be stated explicitly, such as in 

	Ay ~ father(joe,y)

> I'm hoping that there is a third possibility. If I go to the data
> directly, I find that A does not have a father. Perhaps I'm not meant to
> do that; I should check first in the ontology, finding that A _must_
> have a father, then deduce from the absence in the data that the father
> is unknown?  If I carry out this process via an ontology-aware query
> engine, and ask "Who is A's father?", what would it return:
> 
> - an error?
> 
> - null?
.
> - An new instance of Person (person-who-is-the-father-of-A)? 
> [Assuming here that the query returns 'objects' - if I'd asked for the
> URI resource of A's father, I guess this wouldn't make sense?]
> 
> - something else?
> 
> ...0r is the behaviour application-dependent?

Again, you cannot restrict your thinking to the sorts of things that happen
in databases.  In some sense, the behaviour is application-dependent,
because there is as of yet no specification of how queries are to work in
this language.   (Query-answering in first-order languages is a bit complex.)

One way to proceed would be in the same way the PROLOG (a restricted
version of first-order logic) querying works.  You would turn the
implication above into something like:

	person(x) => father(x,f(x))

i.e., there is a mapping from person to their father, ignoring the
uniqueness of fathers.  You would then pose the query as

  father(joe,?x)

where ?x is special syntax for a variable, and get back an answer something
like:

  father(joe,f(joe))

namely, the father of joe is the father of joe.

This looks rather circular, but what else would you expect if this is all
that you know about joe. 

> Generalising my question, I think what I'm asking is: to what extent can
> DAML+OIL be used to validate data, checking that the expected properties
> of an instance have defined values of the correct type (in the way that
> one can check the range and domain of RDF properties). It seems from the
> example above that some restrictions may perhaps not be 'checkable' in
> this sense?

You have to move from the prescriptive meta-data of databases, where a data
schema specifies the ``shape'' of the data to a descriptive meta-data
regime, where ontologies provide more fluid constraints on the data.  Much
more sophisticated checking is possible in DAML+OIL.  For example, we can
can create classes like ``a person with exactly two friends, one of which
is a doctor and another of which is a lawyer'' which will perfectly well
allow the presence of people with no known friends, but, if also told that
doctors and lawyers are disjoint, will reject a person with two doctors as
friends.

> regards,
> 
> David Allsopp.

Peter F. Patel-Schneider
Bell Labs Research

Received on Monday, 2 April 2001 12:30:07 UTC