RE: SEM: circular primitive

> > Of course we could spend another 6 months
> > trying to work that out... It seems a much more efficient use of the time
> > and energy of the combined RDFCore+WebOnt team to fix this problem and move
> > on. Dark triples is the only proposal on the table for which there appears
> > any sort of consensus that it would actually work.
> 
> Please point me to this dark triples proposal -- the one that
> explains how they work. I'm pretty sure there isn't one,
> and I've done quite a bit of looking (and phoning people,
> and so on.)
> 

I have been making efforts to put up proposals that have enough detail 
so that they can be knocked down. I, like Dan, do not find the dark
triples proposal having that level of detail.


Showing that I am still playing the game according to my preferred
rules of discussing concrete cases in sufficient, but hopefully
not exhaustive detail, let us consider Peter's child case.

(In this case I fear it is exhausting but not exhaustive!)

> R:
> 
>      John rdf:type Person .
>      Bill rdf:type Person .
>      John child Bill .
> entailing
>      John rdf:type _:1 .
>      _:1 rdf:type daml:Restriction .
>      _:1 rdf:onProperty child .
>      _:1 rdf:hasClass :_1 .

I personally think this, as stated, is false. But like Jonathan
I think it points to an important use case, for which I will give
my treatment.
I think R is false because:
  If R is true then the premises also entail that
  
  Bill rdf:type _:1 .

and hence
  
  Bill child _:x .
  _:x rdf:type _:1 .

and I do not think that the premises should license the first triple 
of such a conclusion.


So, here is my attempt to capture the semantics of child
in DAML+OIL (as I read it).
Frankly, I have no idea whether this is intended to be
permissable under the current D+O spec. If it is then
it seems a ludicrously cryptic way of saying it. But perhaps
the constraint is complicated.

Note I use classes as instances here.

Note I think the following is sufficiently disgusting that
I would be quite happy to have it as illegal; but I don't
think Jonathan will be able to describe the notion
of inherited disease without something like it. (He can of 
course describe individual inherited diseases quite well 
enough).

====

# Let's not use child but parent.
# parent has the advantage that in general
# it's mincardinality is 1 not 0.

parent daml:inverseOf child .

InheritableClass rdfs:subClassOf daml:Class .

# Informally, an InheritableClass is one such that 
# your parent is in that class iff you are.
# Moreover, we will only use the parent property
# on things that have an inheritable class.

parent rdfs:domain _:ParentDomain .

_:ParentDomain rdfs:subClassOf _:WithInheritableClass .

_:WithInheritableClass rdf:type daml:Restriction .
_:WithInheritableClass daml:onProperty rdf:type .
_:WithInheritableClass daml:hasClass InheritableClass .

# Now, an InheritableClass is one which restricts the
# semantics of parent in a special way.
# Thus InheritableClass is a daml:Restriction.

InheritableClass rdfs:subClassOf daml:Restriction .

# It is a restriction on the parent property.
# The following is the daml idiom of saying that.

InheritableClass rdfs:subClassOf _:par .
_:par rdf:type daml:Restriction .
_:par daml:onProperty daml:onProperty .
_:par daml:hasValue parent .

# Saying the same in English is
# Within the class InheritableClass the
# property daml:onProperty has a local constraint
# restricting it to be present and with the value
# parent.

# Similarly we want to say that the minCardinality 
# is 1.

InheritableClass rdfs:subClassOf _:min .
_:min rdf:type daml:Restriction .
_:min daml:onProperty daml:minCardinality .
_:min daml:hasValue "1" .

# Now we want to restrict the class of the 
# parent property, so we introduce
# toClass.

InheritableClass rdfs:subClassOf _:to .
_:to rdf:type daml:Restriction .
_:to daml:onProperty daml:toClass .
_:to daml:cardinality "1" .

# The above forces every InheritableClass
# to have a daml:toClass property.

# Now we need to force that daml:toClass 
# property to locally be a subPropertyOf 
# identity.

# Well, this too is possible (at least in
# the cardinality = 1 case)

# Let's introduce a superProperty as a technical
# device.

daml:toClass rdfs:subPropertyOf _:superProp .
daml:sameClassAs rdfs:subPropertyOf _:superProp .

# We now restrict the cardinality of both
# the superProp and daml:sameClassAs to 1
# on InheritableClass.

InheritableClass rdfs:subClassOf _:sup .
_:sup rdf:type daml:Restriction .
_:sup daml:onProperty _:superProp .
_:sup daml:cardinality "1" .

InheritableClass rdfs:subClassOf _:same .
_:same rdf:type daml:Restriction .
_:same daml:onProperty daml:sameClassAs .
_:same daml:cardinality "1" .

# And that is it.
# The circular primitive is generated by requiring
# All three of the properties
#  _:superProp
#  daml:sameClassAs
#  daml:toClass
# on each member of InheritableClass.
# The subPropertyOf relationship and the cardinality
# constraints then generate the circularity.

===================

I know, someone will ask me to show how this works 
against my proposed axioms.

A) I am not sure it does
B) If it does, it is sufficiently complicated that I need to 
install a KIF reasoner.


The test is that, all of the above and:


>      John child Bill .
> entails
>      John rdf:type _:1 .
>      _:1 rdf:type daml:Restriction .
>      _:1 rdf:onProperty child .
>      _:1 rdf:hasClass :_1 .


Jeremy

Received on Tuesday, 23 April 2002 05:50:27 UTC