Re: Question: DAML cardinality restrictions

"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)?

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.

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?


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?

Regards,

David Allsopp.


> DAML+OIL does not have a finite model restriction.  It is entirely possible
> to have DAML+OIL models with an infinite number of objects that are not
> datatype values.
> 
> [Yes, there are many world views where everyone having a father (even an
> unknown one) is contrary to fact, but I don't think that this is the
> question.]

> > I hope you'll forgive a (probably very naive) question: In the DAML+OIL
> > walkthrough, we have the following example of a cardinality restriction
> > (plus another minCardinality restriction).
> >
> >  <rdfs:subClassOf>
> >     <daml:Restriction daml:cardinality="1">
> >       <daml:onProperty rdf:resource="#hasFather"/>
> >     </daml:Restriction>
> >   </rdfs:subClassOf>
> >   <rdfs:subClassOf>
> >      <daml:Restriction>
> >        <daml:onProperty rdf:resource="#shoesize"/>
> >        <daml:minCardinality>1</daml:minCardinality>
> >      </daml:Restriction>
> >   </rdfs:subClassOf>

> > My question is: how can such a restriction (cardinality=1) be enforced
> > in practice, since we always deal with finite datasets - at some point
> > our family tree will run out and we shall have an instance of Person
> > without a corresponding Father instance.  Can one specify a
> > 'placeholder' of some kind or is there some other solution? Or will such
> > data always cause a warning when validated against the ontology/schema?


-- 
/d{def}def/u{dup}d[0 -185 u 0 300 u]concat/q 5e-3 d/m{mul}d/z{A u m B u
m}d/r{rlineto}d/X -2 q 1{d/Y -2 q 2{d/A 0 d/B 0 d 64 -1 1{/f exch d/B
A/A z sub X add d B 2 m m Y add d z add 4 gt{exit}if/f 64 d}for f 64 div
setgray X Y moveto 0 q neg u 0 0 q u 0 r r r r fill/Y}for/X}for showpage

Received on Monday, 2 April 2001 11:18:19 UTC