Re: Question: DAML cardinality restrictions

"Peter F. Patel-Schneider" wrote:

> > 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.

OK. What if the data say that someone has two fathers? (for the sake of
argument, I receive an RDF message where the person's Resource has two
Father properties).  Presumably we must reject this message as logically
inconsistent? (Or invoke some process to decide which is the correct
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.

I thought that might provoke a strong response. 8-).

> 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 take your point about representation, but at some point, to make
use of our data, we will often have to leave the logical
representations;
most software does not use FOL or anything like it, and probably never
will.  That's my angle - I am trying to introduce semantic web
technology to allow _existing_ applications/agents to communicate and
interoperate more effectively, without complete re-writes.  These
applications, on the whole, cannot
deal with logic, only concrete data. (If the family-tree plotting
software can't find out _who_ Joe's father is then it isn't
interested...).  

So, I am trying to understand how I can use semantic web technology to
allow some inference, some translation of data, some
merging/collation/fusion of data, whilst eventually allowing me to
extract data into more rigid forms to be imported into
applications, displayed on screen, used to manipulate hardware, or
whatever.

Sorry to sully the pure logic with primitive unenlightened applications,
but I can't just throw everything away and start from scratch 8-)). We
have to be able to bridge between 'ordinary' applications and logic, if
only because most technology users don't know any formal logic and won't
be prepared to learn any; this group, of course, is atypical!  For this
reason I worry when I see query languages couched in terms of FOL; I
think most people just won't use them without a 'user-friendly' layer on
top, however powerful they are.

> > 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.

Thanks for the insights,

Regards,

David Allsopp.

-- 
/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 Tuesday, 3 April 2001 09:21:33 UTC