RE: SEM: circular primitive

I think we are identifying a point of difference.
The DAML+OIL model theory, (unlike the axiomatic semantics),
is based on the triples *in the graph*, the syntax.
The approach I was illustrating thought about the triples
as *in the model* (even if not explicitly in the graph).
(Which is what the DAML+OIL axiomatic semantics seems to
suggest).

In particular, the interesting consequences may follow
if (a) I have not made a mistake and (b) we take the semantics
to be constraints within the model theoretic interpretation
rather than a direct mapping from the syntax.

Jeremy

> -----Original Message-----
> From: Peter F. Patel-Schneider [mailto:pfps@research.bell-labs.com]
> Sent: 23 April 2002 11:32
> To: jjc@hplb.hpl.hp.com
> Cc: connolly@w3.org; jonathan@openhealth.org; www-webont-wg@w3.org
> Subject: RE: SEM: circular primitive 
> 
> 
> I have annotated Jeremy's example.  
> 
> 
> J: So, here is my attempt to capture the semantics of child
> J: in DAML+OIL (as I read it).
> J: Frankly, I have no idea whether this is intended to be
> J: permissable under the current D+O spec. If it is then
> J: it seems a ludicrously cryptic way of saying it. But perhaps
> J: the constraint is complicated.
> J: 
> J: Note I use classes as instances here.
> J: 
> J: Note I think the following is sufficiently disgusting that
> J: I would be quite happy to have it as illegal; but I don't
> J: think Jonathan will be able to describe the notion
> J: of inherited disease without something like it. (He can of 
> J: course describe individual inherited diseases quite well 
> J: enough).
> 
> J: # Let's not use child but parent.
> J: # parent has the advantage that in general
> J: # it's mincardinality is 1 not 0.
> 
> J: parent daml:inverseOf child .
> 
> J: InheritableClass rdfs:subClassOf daml:Class .
> 
> J: parent rdfs:domain _:ParentDomain .
> 
> _:ParentDomain is a class whose instances can have parents.
> Let's consider one such instance, _:John
> 
> _:John rdf:type _:ParentDomain .
> 
> J: _:ParentDomain rdfs:subClassOf _:WithInheritableClass .
> 
> Now _:John is an instance of _:WithInheritableClass
> 
> J: _:WithInheritableClass rdf:type daml:Restriction .
> J: _:WithInheritableClass daml:onProperty rdf:type .
> J: _:WithInheritableClass daml:hasClass InheritableClass .
> 
> _:WithInheritableClass is a restriction, and consists of those individuals
> whose types contain an instance of InheritableClass.
> 
> In particular, _:John has a type that is an InheritableClass, lets call
> this type _:JohnsInheritableType
> 
> J: InheritableClass rdfs:subClassOf daml:Restriction .
> 
> As _:JohnsInheritableType is an InheritableClass it also is a daml:Restriction
> 
> J: InheritableClass rdfs:subClassOf _:par .
> J: _:par rdf:type daml:Restriction .
> J: _:par daml:onProperty daml:onProperty .
> J: _:par daml:hasValue parent .
> 
> Now _:par is the class that consists of objects that have a daml:onProperty
> relationship to parent.  However, this is *all* that it is, for *two*
> reasons.  First, this is not sufficient to make a full DAML+OIL
> restriction.  Second, even if is was, this would not be in the RDF *graph*,
> and the RDF graph is all that counts in the DAML+OIL model theory.
> 
> J: # Saying the same in English is
> J: # Within the class InheritableClass the
> J: # property daml:onProperty has a local constraint
> J: # restricting it to be present and with the value
> J: # parent.
> 
> OK.
> 
> J: # Similarly we want to say that the minCardinality 
> J: # is 1.
> J: 
> J: InheritableClass rdfs:subClassOf _:min .
> J: _:min rdf:type daml:Restriction .
> J: _:min daml:onProperty daml:minCardinality .
> J: _:min daml:hasValue "1" .
> 
> As above.
> 
> Now Inheritable class has both parts required for minimum cardinality
> restrictions, but this is insufficient to make any difference, because they
> are not in the RDF *graph*.
> 
> J: # Now we want to restrict the class of the 
> J: # parent property, so we introduce
> J: # toClass.
> J: 
> J: InheritableClass rdfs:subClassOf _:to .
> J: _:to rdf:type daml:Restriction .
> J: _:to daml:onProperty daml:toClass .
> J: _:to daml:cardinality "1" .
> J: 
> J: # The above forces every InheritableClass
> J: # to have a daml:toClass property.
> 
> OK.
> 
> This says that there is exactly one daml:toClass relationship.
> 
> J: # Now we need to force that daml:toClass 
> J: # property to locally be a subPropertyOf 
> J: # identity.
> J: 
> J: # Well, this too is possible (at least in
> J: # the cardinality = 1 case)
> J: 
> J: # Let's introduce a superProperty as a technical
> J: # device.
> J: 
> J: daml:toClass rdfs:subPropertyOf _:superProp .
> J: daml:sameClassAs rdfs:subPropertyOf _:superProp .
> 
> In the DAML+OIL model theory this does not have the meaning that one might
> think with respect to restrictions.
> 
> J: # We now restrict the cardinality of both
> J: # the superProp and daml:sameClassAs to 1
> J: # on InheritableClass.
> J: 
> J: InheritableClass rdfs:subClassOf _:sup .
> J: _:sup rdf:type daml:Restriction .
> J: _:sup daml:onProperty _:superProp .
> J: _:sup daml:cardinality "1" .
> J: 
> J: InheritableClass rdfs:subClassOf _:same .
> J: _:same rdf:type daml:Restriction .
> J: _:same daml:onProperty daml:sameClassAs .
> J: _:same daml:cardinality "1" .
> 
> So an instance of InheritableClass 
> - has a daml:onProperty relationship to parent
> - has a daml:minCardinality relationship to "1"
> - has a exactly one _:superProp relationship
>   and thus at most one daml:toClass relationship
>   and thus at most one daml:sameClassAs relationship
> - has exactly one daml:sameClassAs relationship
> So if it has a daml:toClass relationship to some object, then it also has a
> daml:sameClassAs relationship to that same object.
> 
> However, this does not provide any interesting consequences, as all these
> relationships do not have to be in the RDF *graph* and that is all that can
> trigger restriction consequences in the DAML+OIL model theory.
> 
> peter
> 
>

Received on Tuesday, 23 April 2002 08:12:44 UTC