SUO: RE: Re: W3C approves RDF and OWL as recommendations
> I do not think that Asha's main point (if I understood it) has been
> answered. Given the additional precisions in http://www.eis.com.cy/
> I think that Asha is referring to the fact that each "role-related
> notions" such as "parent" (not the parenting process) may be represented
> by a relation type (e.g. parent) and/or a concept type (e.g. Parent),
> and that these two categories are exclusive (e.g. in the SUMO, parent
> would be abstract while Parent would be physical), thus leading to
> (i) an increase of the complexity of knowledge entering/management (since
> the notions have to be represented twice and then connected by definitions
> to permit inference engines to compare the representations using the
> relation types with the representations using the concept types), and/or
> (ii) a decrease in knowledge sharing/retrieval possibilities (this is
> actually the most likely outcome).
I accept the point about this being a complication, but am curious about
your description here: "an increase of the complexity..." - an increase from
which baseline? 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.
> As a partial solution, in Ontoseek and WebKB-2, certain role-representing
> concept types may be used in relation nodes, as in the following example
> in CGLF: [Person:Tom]->(Parent)->[Person:Mary]. In WebKB-2, the
> constraints
> are that Parent is a subtype of pm#thing_that_can_be_seen_as_a_relation
> and that Mary has been declared as instance of Parent. In Ontoseek, if I
> remember correctly, I think that Mary may simply be instance of Person
> if Parent has been declared has a role type and is a direct subtype of
> Person. Assuming that no relation type name parent exists in the ontology,
> to export the above representation into KIF, such a relation type should
> be generated and in its signature, the destination type should be Parent
> or Person. Then, the KIF representation could be: (parent Tom Mary).
>
> An extension of this approach that I will probably implement in the
> medium-term is to permit a signature to be associated to a concept type,
> e.g. specifying that if Parent is used as a relation, it must connect an
> instance of Animal to another instance of Animal. E.g. in the FT notation:
> Parent (Animal,Animal) < Animal;
> could be converted into the following in KIF+SUMO:
> (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)))
>
> Such a shortcut can also be used in KIF, e.g. by defining the relation
> roleTypeDomain in such a way that the following 3 formulas are equivalent
> to the 6 previous ones:
> (subclass Parent Animal)
> (roleTypeDomain Parent 1 Animal) (roleTypeDomain Parent 2 Animal)
> Yes, that would involve string manipulation but KIF can do that.
>
> A relation such as roleTypeDomain cannot be "defined" in RDF+OWL but it
> could be added as a primitive to OWL.
What's to stop you saying the same thing in RDF?
parent rdf:type rdf:Property .
parent rdfs:subClass Animal .
parent rdfs:domain Animal .
parent rdfs:range Animal .
You then can use parent as a class:
mother_bear rdf:type parent
i.e. mother_bear is an instance of parent
or property
mother_bear parent baby_bear
=>
mother_bear rdf:type Animal
baby_bear rdf:type Animal
That would address one of the points
> raised by Asha. However, in my opinion, that would not be sufficient for
> RDF+OWL to be an adequate language for knowledge representation and
> sharing since
> (i) there are still many important constructs (related to contexts,
> sets, and numerical quantifiers) that can only be represented in
> (very) ad-hoc ways or not at all (e.g. see the 2nd half of
> http://www.webkb.org/doc/model/comparisons.html
> i.e. starting from the section "contextualization"), and as John Sowa
> pointed out, it is not the role of a "knowledge sharing" language to
> reduce the expressivity, it is up to each inference engine to select the
> (parts of the) representations that it can use, and warn about the fact
> that it ignored some information (or advertize its capabilities, as in
> the OKBC protocol),
> (ii) the model and the adopted conventions are low-level (i.e. they
> lead users to represent the same thing in many different ways, many of
> which are uncomparable or very hard to compare automatically), prevent
> very important checks (e.g. subsumption link cycles are allowed because
> the used subtype links are not "proper subtype" links), and make the
> conversion/presentation of the RDF representations into high-level
> languages and controlled Englishs quite awkward,
> (iii) its XML syntax makes the detection of errors difficult (this
> syntax is not supposed to be seen but in practice it is, if only by
> researchers and those who develop RDF-related tools).
The analysis in the comparisons paper looks very useful (only skimmed so
far - need to read again & digest), though I'm not sure how useful it is in
the argument that OWL isn't good enough to be the 'official' Web Ontology
Language. The lack of direct support for fundamental web constructs such as
URIs and XML namespaces in the other languages compared would surely rule
them out for the job as well.
Cheers,
Danny.