- From: Jeremy Carroll <jjc@hplb.hpl.hp.com>
- Date: Tue, 23 Apr 2002 10:20:10 +0100
- To: "Dan Connolly" <connolly@w3.org>, "Jonathan Borden" <jonathan@openhealth.org>
- Cc: "Peter F. Patel-Schneider" <pfps@research.bell-labs.com>, <www-webont-wg@w3.org>
> > 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