Re: SUO: Re: W3C approves RDF and OWL as recommendations
Philippe,
Sorry if I misunderstood, but it's still unclear to me what you're
suggesting. If
(subclass Parent Animal)
(roleTypeDomain Parent 1 Animal) (roleTypeDomain Parent 2 Animal)
are equivalent to the following 6 formulas:
(subclass Parent Animal) (instance parent binaryRelation)
(domain parent 1 Animal) (domain parent 2 Animal)
(=> (parent ?A1 ?A2) (Parent ?A2))
(=> (Parent ?A2) (exists ((?A1 Animal)) (parent ?A1 ?A2)))
is this a general case, so that you intend to define some general semantic
transformation for every class to spawn a new relation? If so, what's the
mechanism? Is it some sort of procedural macro? If not, what's the
general case rules that should apply? Does the user see the generated
axioms when browsing a knowledge base? Sorry if I'm still not clear on this.
Adam
At 03:59 PM 2/17/2004 +1000, Philippe Martin wrote:
>Danny, Adam,
>
>I did NOT suggest that categories like the relation type parent (with
>a lowercase 'p') and the concept type Parent (with an uppercase 'P')
>could be "combined" and I explicitely said that they were exclusive:
> > these two categories are exclusive (e.g. in the SUMO, parent
> > would be abstract while Parent would be physical)
>
>Danny wrote:
> > What's to stop you saying the same thing in RDF?
> > parent rdf:type rdf:Property .
> > parent rdfs:subClass Animal .
>
>In RDF/OWL, classes are exclusive with properties, thus what you
>suggest is inconsistent with the definitions. The fact that your
>Notation 3 parser did not detect this inconsistency means that it
>is not RDF/OWL compliant.
>More intuitively, I do not see how something could be both
>categorized as abstract and physical. That does not mean that I
>reject new categorization schemes, but this is not what I introduced.
>
>Thus, I did NOT suggest that the relation type parent
>(with a lowercase 'p') could be a subtype of Animal.
>
>What I have suggested is a shortcut to avoid the users having to
>(i) declare both the relation type and the concept type (i.e.
> duplicate role types from the concept type hierarchy into the
> relation type hierarchy),
>(ii) write definitions to connect them.
>This was a way to answer the knowledge sharing/retrieval problems
>pointed out by Asha while still using the "set-theoretic approach"
>(Asha's expression) and the usual ontological distinctions.
>Thus, for KIF, I suggested that a relation type roleTypeDomain
>could be defined in such a way that the following 3 formulas
> (subclass Parent Animal)
> (roleTypeDomain Parent 1 Animal) (roleTypeDomain Parent 2 Animal)
>are equivalent to the following 6 formulas:
> (subclass Parent Animal) (instance parent binaryRelation)
> (domain parent 1 Animal) (domain parent 2 Animal)
> (=> (parent ?A1 ?A2) (Parent ?A2))
> (=> (Parent ?A2) (exists ((?A1 Animal)) (parent ?A1 ?A2)))
>
>Danny wrote:
> > "an increase of the complexity..." - an increase from which baseline?
>
>1) For the users, "complexity" just meant "complication": double
> declarations + definitions
>2) For the inference engines, I was thinking about the additional work
> that the handling of double declarations plus the definitions would
> implies (if the users do not forget to enter them and if the language
> supports the entering of such definitions; do you think OWL can?);
> conversely, if the semantics of primitives such as roleTypeDomain is
> hard-coded in the inference engine, they can be handled more
> efficiently than their underlying rules.
>
>
>Danny wrote:
> > I'd also note that there's the assumption here that both Parent and
> > parentOf would both be needed. If only the class (or relation)
> > were needed, then surely there is a net *reduction* in complexity
> > from the combined notion.
>
>Ok, you acknowledged that I was not suggesting a "combined notion"
>and you introduced that idea. I will not comment on that idea on
>ontological grounds since this is not my goal: my goal is to store
>distinctions into a same ontology and interlink them in a correct
>way in order to help their automatic or manual comparison and hence
>their retrieval or understanding, and the checking of their uses.
>
>
>Philippe