As a complete novice at this, I have come to the naive
conclusion that ontologies need to reflect some use case
in order to make any sense.
Aha, this is surely true, in my opinion. The reason I am
looking for a deep structure that maps to the surface models
for different uses is entirely dependent on the use cases for
the deep structure, as opposed for those for the surface
models. The deep structure use case is described below. *
My system analyst background says that my way of looking
at wine is going to be a lot different if I am building a
cooking site than it would if I was designing a business
system for the LCBO (Liquor Control Board of Ontario -
reputed to be the world's largest purchaser of wine).
I would think that if my searches are similar to "Give me
a list of wines that go with baked white fish." , I am
going to have a much different view of wines than the
product manager at the LCBO who want to know "Where can I
get more wines that are similar to vintner X's 2009
Premier Cru and can be purchased in quantities in excess
of 3000 bottles?"
Both queries produce a list of white wines (at least I
expect it would) but the gyrations to get each list are
going to be different and I would expect that underlying
ontologies to support the search would be structured quite
Can one actually construct a "wine ontology" that will be
equally meaningful in both contexts? And equally
convenient to build and maintain?
*As I believe and understand several others to believe, one
wants to specify a generic, way underspecified wine ontology
that needs to be extended in different ways to suit the needs
of particular domains of endeavor, such as the two excellently
different ones you introduce. With, among its goals, the
ability to related the different domains to each others.
I look forward to see how this evolves.
I would be delighted to find that my misgivings are misplaced and
that there is a way to define something that is both true and useful
in a wide range of use cases.
Tue, May 28, 2013 20:10, William Frank wrote:
> For example, chardonnay is NOT a type of wine,
contrary to the OWL
> tutorial. Chardonnay is a type of grape, and a
wine may be classified
> according the grapes used to make it, as well as
in myrid other ways.
If wines my be classified according to the types of
grapes used to make
them, why do you object to these "classes" of wines
being called "types"
Perhaps what I am saying and what you say about
acyclic directed graphs are close. I also suspect I
am missing something.
I find It much more flexible and requiring less
baggage to treat the huge variety of classification
schemes (schemes such as color, region, etc.)
according to which something (such as Wine) can be
classified, and all the classifiers in each scheme
(red, white, burgundy, chardonnay), as themselves
part of the model, and their definitions, at the same
level as the wines themselves. Instead of chardonnay
being a 'type' of wine, if instead we define the wine
grape classification scheme and the classifier
chardonnay, as for all x:wine charadonnay(x) iff (the
grapes from which x were made were at least 50%
chardonnay grapes). Then, I would want to say, this
wine **is classified as a* that classifer, Both the
classifier and the thing classified existing at the
same logical level, and in the *is classified as a*
being the logical relation between them.
At the same time, I have found that it is useful to
construct a single, quite shallow natural type
hierarchy, easy for bilogical obects like grapes, and
not so hard for some things like wine, where we can
define what it means to be a wine, (manufacture
method), natural wines, fortified wines, perhaps as
the two first nodes. I heard here not long ago that
figuring out what was the right core hierachy for
minerals was not so obvious to all, but many of the
other descritors, such as hardness, I would treat
differently. For things like financial instruments,
there is a very shallow hierachy based on the nature
of the obligation and rights involved, while all the
virtually infinite varieties of financial instruments
are better distinquished by the parts they are
assembled from, and the features of those parts. I
have found the classifications of them ineffective if
done with multiple types (it becomes almost like a
fine wire mesh), rather than with simple definitions
of what it means, for instance, to be a sushi bond or
a PIK bond. This idea of natural types I do not know
how to easily argue for, though I have seen such
arguments that convinced me. Me, I only find it
have often criticized the wine tutorial, but i do not
find this to be one
of its problems.
> These are not different 'types" of wine, using
the bilogical analogy for
Formal ontology has long since moved past taxonomy
trees. It is
much more useful to use directed acyclic graphs.
> Wine would have only ONE subtype hierachy, based
> what is essential about wine being wine. (How it
One valid subtype hierarchy of types of wine is based
on the type of
grape. Another (single level) hierarchy of wine type
is by color. A
third is regional. A regional division of wine types
by vineyard might
be useful at some level of business, but a further
division by vineyard
and grape variety provides a useful disjoint set of
types of wine. This
hierarchy of types can be taken one step further -- by
Of course, if one wishes to use the type concept in
this way, this is right, so I am seeing that my
criticism of the wine tutorial is perhaps misplaced.
Perhaps I simply am not happy with the way the authors
of OWL want to use OWL. Perhaps I am arguing more
against official UML semantics, and OWL has nothing to
do with it. For in UML, it seems that they have
striated the world into so many levels each of which
requires a different model, when in fact it is much
simpler to consider the ways we classify things to be
If you could help me get to the bottom of this, I
would be most grateful.