I agree that multiple hypernyms are a good choice when there is no
naturally distinguished hypernym. In general, if there are N unary
predicates p1, ..., pN applicable to X, the ontology standard should
permit us to express, without a priori bias, all of the following
(where "/\" is ordinary conjunction and "^" is hypernym `intersection'):
No hypernym: p1(X) /\ p2(X) /\ ... /\ pH(X) /\ pH+1(X) /\ ... /\ pN(X)
One hypernym: p2(X:p1) /\ ... /\ pH(X:p1) /\ pH+1(X:p1) /\ ... /\ pN(X:p1)
1<H<N hypernyms: pH+1(X:p1^p2^...^pH) /\ ... /\ pN(X:p1^p2^...^pH)
Only hypernyms: true(X:p1^p2^...^pH^pH+1^...^pN) or X:p1^p2^...^pH^pH+1^...^pN
Of course, we have to clarify the semantics of hypernym `intersection':
It might correspond to set intersection on the predicate extensions or
to a less obvious inheritance strategy. While we may consider the
extensional semantics of the four above possibilities to be the same,
we should be able to cope with the remaining difference of, say,
black-instrument(X) /\ stringed-instrument(X) /\ percussion-instrument(X)
and (the more natural)
black-instrument(X:stringed-instrument^percussion-instrument)
where we selected stringed-instrument and percussion-instrument to be
`sortal' predicates and black-instrument to be a `non-sortal' predicate.
As mentioned by John Sowa, a hypernym hierarchy should also be permitted
for non-unary predicates. And the above remarks should apply to it, too.
In "ONTOFILE: Ontological Modelling of Local and URL File Systems",
to be presented at the "Eighth European-Japanese Conference on
Information Modelling and Knowledge Bases", 26-29 May 1998 in Finland,
I felt the need for this flexibility for a real-world application.
Abstract:
The conceptual-modelling language ONTOFILE is introduced to cope with
the ontological complexity of file systems. On the basis of a
functionally extended logic, files are described by exterior and
interior ontologies for the respective structuring of their manifest
and underlying features. The declarative representation of manifest
file attributes and relations as well as underlying file entities and
properties is discussed with an information-systems example. Exterior
ONTOFILE attributes and relations can be parameterized; single-valued
and multiple-valued attributes are modelled by deterministic and
non-deterministic functions, respectively. Interior entites and
properties are modelled by subsumption hierarchies; property-to-entity
applications return the files in which they hold. These descriptions
can be employed at the same time, like in fact retrieval, as a
knowledge base summarizing the content of files and, like in document
retrieval, as an index for the names of files containing detailed
information. Besides retrieval, ONTOFILE hierarchies permit two kinds
of inference, inheritance and expansion. This modelling approach is
applied consistently to local file systems and to URL-addressed WWW
pages.
URL of full paper: http://www.dfki.uni-kl.de/~boley/filekb.ps
BTW, I'm a little unclear about which contributions make it to me
via onto-std@ksl.stanford.edu (the thread's context suggests that I
have missed the ones by Pat Hayes and John McCarthy).
Greetings, Harold Boley.