SUO: RE: Re: W3C approves RDF and OWL as recommendations
> 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)
In your earlier post, you suggested that such an exclusive representation
would lead to "...an increase of the complexity..." and "...a decrease in
knowledge sharing/retrieval possibilities...". I took this to suggest that
were advantages in not using an exclusive representation. My apologies if I
misinterpreted this.
> 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.
Which definitions is it inconsistent with? According to the MT, an
RDFS-valid statement is :
rdf:Property rdf:type rdfs:Class .
Under normal circumstances instances of properties have only one purpose, to
act as predicates. But I see nothing that forbids their use as regular
classes. The OWL DL sub-language does cleanly separate properties and
classes (using owl:Class rather than rdfs:Class so a statement like that
above is avoided), but within OWL Full I don't believe there is any
inconsistency in the statements I provided. I don't think the use of a
property as a class in this way is a good approach, but that doesn't detract
from its logical consistency.
> 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.
I'm not sure how that is relevant in this case - whether the terms denote
abstractions or physical entities is orthogonal to the language and its
rules.
> Thus, I did NOT suggest that the relation type parent
> (with a lowercase 'p') could be a subtype of Animal.
But you did suggest the example "e.g. specifying that if Parent is used as a
relation, it must connect an
instance of Animal to another instance of Animal.". Which is turning it
around, saying Parent (which is a subclass of Animal) would be used as a
relation. Change the case (but not the semantics) of the RDF and you have
the same thing.
> 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.
Ok, then I'll suggest that the use of parent as a class as well as a
relation in RDF is also a shortcut. Perhaps not the same shortcut, probably
not a good shortcut.
> 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)))
Though RDF treats the class/instance and relation constructs differently, I
believe the end result is the same.
> Danny wrote:
> > "an increase of the complexity..." - an increase from which baseline?
>
> 1) For the users, "complexity" just meant "complication": double
> declarations + definitions
Ok.
> 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.
Hmm, I'm not sure about this - if you're wanting the construct to behave as
a relation (and follow appropriate rules) under some circumstances, and
behave as a class (or instance of a class) under others, then there are two
sets of behaviour to take into account. I would be interested in seeing how
roleTypeDomain might simplify things.
> 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.
Ok, I can see there may be value in linking across the ontology, so that the
relationship between terms like Parent (class) and parent (relation) can be
expressed. The "combined notion" I presented in RDF isn't really
satisfactory for that purpose. I think my response got us talking at
cross-purpose somewhat, so sorry about that... But I was responding to the
implication that the lack of direct support in RDF/OWL for the interlinking
meant it wasn't suitable for use as a web ontology language. If an
additional primitive needs to be added to other languages to provide this
support anyway, this argument against RDF/OWL isn't very strong.
Cheers,
Danny.