Re: Issue-114

On Jul 1, 2008, at 3:53 AM, Rinke Hoekstra wrote:

>>> 2) A well known case is the relational nature of several roles,  
>>> such as 'father'. Sometimes 'father' is used in the sense of  
>>> 'has_father', sometimes it should be the class of fathers (or,  
>>> more precisely, the role played by persons who are fathers).  
>>> Again, using role inclusion axioms you can do a reification-like  
>>> trick to infer the 'father' relation between two classes, given  
>>> the chain has_father o played_by -> father.
>>
>> Could you write out what you mean by this in (possibly pseudo) OWL  
>> and explain how I should understand it. I can't really understand  
>> what you mean here.
>
> Sure. It's not entirely fleshed out yet...
OK. Let me try to work through it.
>
> In LKIF Core we make a distinction between roles (anti-rigid) such  
> as student, father and persons (similar to Searle's distinction  
> between intrinsic and observer-relative/social facts). A person is  
> said to 'play' or 'count as' a role. (sure, whether the father-role  
> is anti-rigid is debatable, but just assume for simplicity's sake).

As an aside, I always have have a bit of trouble with "getting" rigid  
and anti-rigid properties. When I asked Guardino about this he said  
that rigidity isn't something in reality - it is part of your theory  
of ontology.  But then Pat Hayes seemed to disagree and says that no,  
many people consider them not to be a choice. Then there is the  
aspect of whether to think about them in terms of necessity in  
possible worlds (but then the question of which possible worlds to  
quantify over), or as a classification into properties that can vary  
over time one initially acquired, versus those that can't, assuming  
one has a theory of the identity of the bearer over time.

That said, it is a little hard to figure out in what sense Father is  
anti-rigid. Are you saying that Father is anti-rigid because it is  
possible that in some possible world you are not a father? In the  
temporal sense, it's hard to imagine "father" role to be dropped, if  
defined as the property of having fathered a child, although it is  
possible to imagine it dropped if defined as active involvement with  
offspring.

> This is at odds with the common use of properties to denote roles,  
> and frequently results in odd constructions. For instance,
>
> Father subClassOf Person
> Person equiv has_father exactly 1 Father
>
> The class 'Father' cannot really be defined without the  
> 'has_father' property: a rather circular definition, where the  
> class and property have a similar status.

Not sure I understand how it can't be defined without the has_father  
property. We haven't really defined father yet, just stated a  
necessary condition. It would seem to be equally valid to have said

Person equiv has_parent exactly 1 Mother

But even though it's true it doesn't feel definitional. But that  
said, I can imagine one wanting, for modeling purposes, to reify  
relations.

> What we therefore try to do, is make the implicit role 'father'  
> explicit as the reification of a 'father' property. In fact the  
> 'has_father' property in my original example, can be regarded as  
> relating the context in which the father role is played to the role  
> itself (I'll rename the has_father property from my original  
> example to context_of, for sake of clarity).
>
> If we now have the following classes:
>
> father subClassOf (Role and played_by exactly 1 Person)

So each (instance of) father(role) is played by a single (instance  
of) Person.

> Person equiv context_of exactly 1 father

What's the domain of context_of? Or rather, how should I read this in  
english?

> and the role inclusion axiom
>
> context_of o played_by -> father

Neither context_of or played_by are specifically father related (or  
at leas they don't sound so).

> users of the ontology can choose to be either be explicit about  
> context and roles, with the advantage of expressiveness, or just  
> reuse the more implicit father property in more elaborate class  
> restrictions. This improves reusability by information hiding. Of  
> course, this only works in one direction: explicit constructions  
> allow us to infer the implicit relation, but not vice versa.

I'm going to try to rephrase to see if I've got the basic idea:

One would like to reify a relation and ideally have it be the case  
that either use of the reified relation or the relation directly,  
arranges to have the other inferred. If that were the case, we could  
equate the property to the class, as the instances of the class would  
be in a 1:1 relation with the pairs of relata. They could, in this  
sense, be understood to mean the same thing.

-Alan