One aspect of the Ontology Application Framework is architecture, which is related to enterprise infrastructure. There are several others that seem somewhat distinct, but are also closely related.
For example:
OntologyRole: answers the question: how is the ontology used in an application. An OntologyRole role can also be a TechnologyOrTechnique, e.g. to drive user interface forms.
Purpose: the reason for building the ontology. It could be related to the intended OntologyRole or intended Benefit.
Benefit: A desirable outcome. For OAF we are specifically interested in benefits that arise from the application of a particular technology, technique, or approach. Benefits may also derive from other benefits. For example, reduced maintenance effort is a benefit that contributes to reduced costs. There is a distinction between an intended benefit, and an actual benefit.
TechnologyOrTechnique: A way of accomplishing something, can include specific techniques as well as broader technologies.
None of this is cut and dried.
A technology or technique can be tightly linked with the role of the ontology, and/or the architecture. Technologies and techniques can directly lead to benefits.
Purpose is often conflated with benefit. The purpose is to have a particular benefit, but the purpose might be expressed as a particular way the ontology will be used, or it could be expressed as a benefit, or both.
The ontology role is often tightly tied up with an architecture.
An ontology may play a particular role, and do so according to spec, but there may be no benefit at the end of the day.
We are working to tease out these distinctions. In fact, I am building an OAF ontology in owl (some of the definitions above are pasted from the ontology comments).
There are several reasons for doing this:
to help clarify my thinking
to effectively communicate the framework.
to act as a basis for populating a database of ontology applications.
(rhetorical) exercise for the reader: classify the above reasons into one or more of:
ontology purpose
ontology role
intended purpose
intended benefit
architecture
actual benefit
technology or technique or approach
Michael
On Tue, Mar 1, 2011 at 8:12 AM, Jack Ring <jring7@xxxxxxxxx> wrote:
I suggest that an ontology is a key aspect of the enterprise infrastructure. If architecture is "The arrangement of function and feature that maximizes an objective" then infrastructure are the functions and features that are factored out because they support all the others. Generally, infrastructure provides for commonality of location/dimension, support, access, access control, and services. Ontology enables human knowledge exchange and choice making. An EA Framework is one facet of an enterprise ontology, presuming, of course, that an ontology can refer to 'itself.'
On Mar 1, 2011, at 8:26 AM, Pavithra wrote:
Hi Arun,
I believe it is possible to incorporate Ontology as an artifact or
work product to an exiting Enterprise Architecture framework and road map..
I call it Semantic Enterprise Architecture. The assessment or the
checklist to find out the readiness would be another artifact or work product
in the road map as well.. We had some presentations on Semantic
Enterprise Architecture tools in the past sessions in this forum.
OAF can be refined to include more specific information about Ontology. Or renamed if the other people agree.
At present, some organizations have a centralized Data Dictionary or
terminology and descriptions, but there is no consistent understanding of what comprises
”Ontology" for the organization.
From: Arun <arun@xxxxxxxxxxxx> Subject: Re: [ontology-summit] [Ontology Application Framework] Revised Strawman Proposal To: "Ontology Summit 2011 discussion" <ontology-summit@xxxxxxxxxxxxxxxx>
Date: Tuesday, March 1, 2011, 8:28 AM
Hi,
The Ontology Application Framework (OAF) reminds of the Technology
Readiness Level (NASA's TRL's) that one could use with another tool,
like an Analytic Hierarchical Process (AHP) to identify an ontology
dependency and development strategy for the larger enterprise: for
example, knowing what you have, what you don't have, and therefore,
what you need to have, would a kind of "inventory" mechanism that a
document along the lines of this one might provide. As an industry
developer with clients in the public and private sector spaces, I
tend to do this similar kind of road-map work almost
semi-automatically for any new job because I always need some kind
of inventory that serves the purpose of seeing the client road map
and what the barriers to success might be.
While the OAF document uses words like "value metrics" it does not
indicate what methodology is used whereby qualitative and often
subject judgments are input and objective numerical evaluations as
outputs (aka value metrics) are used. My preference is AHP and
other portfolio valuation methods.
The OAF might be the seed for someone to take it further and a
create a kind of Zachman *style* framework or model which becomes a
tool for rapid assessment in strategic road map development, and
therefore, critical and quantitative budgeting, for the renovation
of legacy enterprises and/or legacy with new technology integration
paths that are productivity and cost optimal.
I don't like the acronym "OAF" since it sounds like the dictionary
word "oaf" ( according to Merriam-Webster, a big clumsy slow witted
person). Even though my point seems trite, some critical managers
might find that acronym disconcerting. And we need all the help we
can get.
Perhaps a name along the lines of Road-mapping Ontology Model (ROM)
which corresponds also with a popular acronym for Rough Order of
Magnitude might be useful.
Or perhaps I am just missing the point entirely?
Thanks,
Arun Majumdar
On 2/28/11 8:51 AM, Wisnosky, Dennis E OSD DCMO wrote:
And, its purpose?
Dennis E. Wisnosky Department of Defense Business Mission Area Chief Architect and Chief Technical Officer 703-607-3440 C630-240-6910
-- WARNING: THIS EMAIL IS COVERED BY THE ELECTRONIC COMMUNICATIONS PRIVACY ACT, 18 U.S.C. § 2510-2521 AND IS LEGALLY PRIVILEGED. THE INFORMATION CONTAINED IN THIS MESSAGE AND THE ATTACHMENT, IF ANY, IS EXEMPT FROM DISCLOSURE UNDER APPLICABLE LAW.