All, (01)
Yes, this approach works. Essentially this distills down to an enterprise
faceted taxonomy. This is what we at the World Bank envisioned about 10 years
ago, began developing about 7 years ago and are now in the process of deploying. (02)
Each facet in the enterprise taxonomy then has its own particular type of
taxonomy (could be one of five distinct types of taxonomies) that support the
behavior of that facet. For us Business Function and Business Process are
hierarchical associations. But they are definitely orthogonal to organizational
unit and topic. For example, the enterprise business function taxonomy is a
five level hierarchy which has its own business rules, semantics and syntax
rules. In our case the business rules describe at a high level how economic
development work is done. At the second level it begins to describe the World
Bank's business activities in support of development. At the third level, it
describes specific cross-organizational business processes. Fourth level is
task and fifth level is subtask. Each level in the hierarchy is implemented as
a distinct data class, which means that across the organization it is then
possible for different business applications to consume a data class with or
without its linked higher level or lower level classes. So, our e-Services
structure can consume/promote level 2 of the structure and down, our Case
Management System can come levels 3/4/5. We can link to financial and
accounting systems at various levels in the structure. And, different
applications can select only the values from a data class that pertain. (03)
Another important point that leads to clarity in semantics issues - is that the
hierarchical business function taxonomy is NOT THE SAME thing as a business
language. The labels of the business function taxonomy (hierarchy) are
DIFFERENT from the actual business vocabulary which is associated with each
class in the overall hierarchy. This language is at the concept level -- this
is several decades of research ABOVE the dictionary level. Organizations
already know what their business language is - it simply has to be formalized
and the best way to formalize it is to associate it with the business function
structure. We're already about 50% of the way there on this task. Business
language is initially a flat taxonomy (list), and a network taxonomy when you
add relationships among the concepts. Relationships are also data structures
that have meaning - from primitive to sophisticated. (04)
Another reason to take the approach that this model supports is that business
processes and business languages change rapidly. If you have only a hierarchy,
and if that hierarchy isn't linked to a faceted structure, and you aren't
linking either a flat or a networked taxonomy to the hierarchy -- you're model
is too rigid to handle this level of change. What we have learned is that
putting the time into understanding the 'information architecture' up front,
makes it possible for you to elegantly evolve your overall ontology. In fact,
I am convinced after these ten years of learning/experiment/developing, that
this information architecture DEFINES our ontology. (05)
I think the information architecture and the application-level purpose help to
resolve some of the contextualization challenges -- which I don't believe will
ever be resolved at an 'all world' level. We can, though (as we have begun to
do), look across comparable development organization structures to find
commonality first within the business function taxonomy, and then within the
business languages. I think it is definitely possible to build crosswalks at
many levels. But you must first be able to say where you are in your ontology
and where you want to go in someone else's ontology. (06)
We have also elaborated our organizational taxonomy (going back and doing the
tracings over 60 years) and this turns out to be a hierarchical taxonomy (with
some dead ends) but also supplemented by ring taxonomies (meaning equivalent
mappings). We also have defined the develop topic taxonomy (which is a
hierarchy), topical vocabularies (network taxonomies + ring taxonomies). The
topic taxonomy linked to the enterprise topic vocabulary helps to resolve a
large number of the ambiguity issues. (07)
Another thing we have learned is that if you have this kind of baseline
information architecture, you can then go cross-language and still maintain
meaning. (08)
This point of this long message (my apologies), is that Roy is on the right
track. Each organization needs to first define its entities, and the facets
that are important to those entities. The question for every organization is
where do you need to start. We began this work by doing a cross-organizational
inventory of the kinds of 'information assets' we have/create/use. We decided
that our content included not only formal and informal structured and
unstructured information, but people, communities, services, and raw knowledge.
We have also found that the different kinds of technologies play different roles
in developing parts of the ontology. No one tool does it all. (09)
I hope this makes sense -- sorry for the long ramblings. (010)
Best regards,
Denise Bedford, Ph.d.
Senior Information Officer
World Bank
Washington DC (011)
"Gary
Berg-Cross"
<gary.berg-cros To
s@xxxxxxxx> <ontac-forum@xxxxxxxxxxxxxx>
Sent by: cc
ontac-forum-bou
nces@xxxxxxxxxx Subject
.net [ontac-forum] Enterprise Model categories
and ontology (012)
10/19/2005
05:25 PM (013)
Please respond
to
ONTAC-WG
General
Discussion
<ontac-forum@co
lab.cim3.net> (014)
I'm a few days behind on the messages, but Roy mentioned building an ontology
for a" purposeful endeavor, i.e., an "enterprise", to ask and answer questions
in a manner that would be understood by all others within the enterprise and/or
its external environment." This is kindred to my earlier suggestion that an
ontology as a model needs to have a purpose to focus the effort and I have a few
observations on the topic (015)
Rou provided some definitions for things like Enterprise = a purposeful endeavor
= a mission (regardless of number of participants, budget, physical dispersal,
etc. (016)
and a set of basic questions usually showed up using their natural name (time,
space, etc.) in forms and reports, or were more typically re-labeled as shown in
the 7 categories below.
1. Location
2. Organization
3. Organization Unit
4. Function
5. Process
6. Resource
7. Requirement (017)
He then proposed that the seven sets of basic question categories form the root
classes of his generalized ontology. (018)
I think it relevant to mention the experience with Enterprise Ontologies such as
TOVE going back a dozen years or so. Mike Gunninger participated in the frist
meeting so he might have much more to say, but a simple observation is that
Enterprise Ontologies have developed quite a bit more specfics including the
important relations between makor areas and enterprise elements.
The following, for example, is a list of the terms defined in the Enterprise
Ontology developed by the AI Applications Institute at the University of
Edinburgh with partners: IBM, Lloyd's Register, Logica UK Limited, and Unilever.
It includes a Strategy area and Time, which was also modeled in TOVE. (019)
The central concept of the Strategy section is Purpose. Purpose captures the
idea either of something which a PLAN can HELP ACHIEVE or that an ORGANISATION
UNIT can be responsible for. (020)
Activi|Activity Specification, Execute, Executed Activity Specification,
ty |T-Begin, T-End, Pre-Conditions, Effect, Doer, Sub-Activity, Authority,
|Activity Owner, Event, Plan, Sub-Plan, Planning, Process Specification,
|Capability, Skill, Resource, Resource Allocation, Resource Substitute.
------+-----------------------------------------------------------------------
Organi|Person, Machine, Corporation, Partnership, Partner, Legal Entity,
zation|Organisational Unit, Manage, Delegate, Management Link, Legal
|Ownership, Non-Legal Ownership, Ownership, Owner, Asset, Stakeholder,
|Employment Contract, Share, Share Holder.
------+-----------------------------------------------------------------------
Strate|Purpose, Hold Purpose, Intended Purpose, Strategic Purpose, Objective,
gy |vision, Mission, Goal, Help Achieve, Strategy, Strategic Planning,
|Strategic Action, Decision, Assumption, Critical Assumption,
|Non-Critical Assumption, Influence Factor, Critical Influence Factor,
|Non-Critical Influence Factor, Critical Success Factor, Risk.
------+-----------------------------------------------------------------------
Market|Sale, Potential Sale, For Sale, Sale Offer, Vendor, Actual Customer,
ing |Potential Customer, Customer, Reseller, Product, Asking Price, Sale
|Price, Market, Segmentation Variable, Market Segment, Market Research,
|Brand Image, Feature, Need, Market Need, Promotion, Competitor.
------+-----------------------------------------------------------------------
Time |Time Line, Time Interval, Time Point. (021)
The point is that we should build on prior work and also go beyond simple
categories to models with structured relations. As Eric mention some of these
topics has been previously discussed in the SUO forum. Some of it is older than
that. Lattice hierarchies were mentioned several times and Roy mentioned some
thimgs such as a set of relations that seemd to me to not being the state of the
art of thinking about these things. (022)
Below is the hierarchy lattice of ontologies from a 1994 KIF library. Each
ontology defined a set of formal terms ande an ontology at one level includes
those ontologies that it are indented under it. This just illustrates that some
of these issues have been discussed before and we should make sure we aren't
wasting time by starting at immature points. (023)
Kif-Sets
Kif-Extensions
Frame-Ontology
Jat-Generic
Job-Assignment-Task
Basic-Matrix-Algebra
Tensor-Quantities
3d-Tensor-Quantities
Simple-Geometry
Mechanical-Components
Mace-Domain
Abstract-Algebra
Physical-Quantities
Standard-Dimensions
Vt-Design
Vt-Domain
Vt-Example
Unary-Scalar-Functions
Mace-Domain
Cml
Thermal-System
Dme-Cml
Thermal-System
Standard-Units
Simple-Geometry ...
Scalar-Quantities
Vt-Design ...
Unary-Scalar-Functions ...
Tensor-Quantities ...
Quantity-Spaces
Simple-Geometry ...
Parametric-Constraints
Components-With-Constraints
Vt-Design ...
Mace-Domain
Component-Assemblies
Mechanical-Components ...
Components-With-Constraints ...
Dme-Cml ...
Bibliographic-Data
Slot-Constraint-Sugar
Bibliographic-Data
Kif-Meta
Parametric-Constraints ...
Kif-Relations
Frame-Ontology ...
Kif-Extensions ...
Kif-Numbers
Kif-Extensions ...
Kif-Lists
Kif-Extensions ...
Kif-Meta ...
Kif-Relations ...
User-Theory (024)
Gary Berg-Cross
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (025)
_________________________________________________________________
Message Archives: http://colab.cim3.net/forum/ontac-forum/
To Post: mailto:ontac-forum@xxxxxxxxxxxxxx
Subscribe/Unsubscribe/Config:
http://colab.cim3.net/mailman/listinfo/ontac-forum/
Shared Files: http://colab.cim3.net/file/work/SICoP/ontac/
Community Wiki:
http://colab.cim3.net/cgi-bin/wiki.pl?SICoP/OntologyTaxonomyCoordinatingWG (026)
|