| Applauding Ali's points and adding --- Commercial and Industrial: Business leaders prefer no big (risky) leaps. If we can show a smooth, minimum breakage path from data base schema to taxonomy to concept maps to localized ontologies to formal enterprise ontology they are more likely to enter the Awareness, Appreciation and Acceptance flow. Hot spots are a) the nomenclature gaps between product development (as designed), manufacturing (tools, jigs and fixtures an as built) and marketing (as legally promised). b) the corporate Policy and Instruction manual (about as ambiguous as your IRS instructions) especially vs. c) the content of the business rules embedded in the IT systems. c) organizational development initiatives which are successful or not depending on the adequacy and coherence of Mission&Vision, Strategy, Intent, Goals, Plans, Commitments, Competencies, Energy and Automation, Teambuilding, Collaboration, Tenacity, Achievement, Recognition, and Co-celebration.
Customers will be Product Managers, Innovation Officers, Chief Knowledge Officers, not IT department.
Before we dive into details of how to make specific cases, I suggest it would be beneficial to take a finer stock of the problem space.
As Todd notes here, On Thu, Dec 16, 2010 at 9:44 AM, Todd J Schneider <todd.schneider@xxxxxxxxxxxx> wrote:
Having the "foot in the doors" many of the other benefits
of using ontologies (and their risks) can be shown. But first,
you need to get someone to listen.
Thoughts?
It is important to identify who the potential audiences are. The case for an ontology needs to be made and is different for a CEO, CTO, engineer, programmer and whoever else requires convincing in an organization or culture.
The approaches noted by Todd, Deborah and Steve W. presume a particular use / technical component of an ontology (OWL, databases or...).
[TS] There are multiple ways to answer each of these variants, but
it would be more effective if all the possible answers used
a common theme (i.e., the sales pitch). As evidenced by the
current uses of 'ontologies', the aspect of data models seems
optimal as the entree for starting an engagement with sceptics.
Before we do that, it is important as well to identify the different uses of formal ontologies in organizations. This certainly extends beyond using ontologies in database environments. Indeed, in one of the decks Bradley shared here:
Slide 6 identifies some application types for an ontological approach in an organization. Not all of these are suited for OWL or require mentions of the RDMS world. To the projects identified there, one could add several more to do with software development, model verification, systems to retain the knowledge of employees who are retiring and more that I'm sure others on this list can contribute.
Moreover, each of these projects might have parts of a case which are common to others, but some which are different. For example, an ontology that must be "reasoned on" or accessed in real time, vs one that is used for off-line verification or even to guide the design of some system will have very different cases to be made.
Building on what Steve and Nicola started with the domain identification here:
Before we skipping into the details of particular projects, or perhaps alongside the development of technology specific cases, we would benefit from collecting and then synthesizing the different responses people give to:
1. Who is the audience?
CEO, CTO, Project Manager, SysAdmin, IT Manager, Programmers, etc.
Note: a CEO, CTO, VP of X, or Project Manager might hold the purse strings and/or a yes/no veto for a project started; while the implementers, other stakeholders and programmers are the culture. At the very least, two very different cases need to be made here for a successful ontology project: cultural / technical vs business / technical.
2. How can one use an ontology in an organization / culture? (Bradley, I hope you don't mind that I've reproduced your bullets here):
- Semantic integration of various data bases
- Knowledge Exploration
- Semantic annotation
- Automatic document tagging
- Auto-summarization of a document
- Business intelligence mash-ups
- Decision making support
- Common metadata vocabulary for self annotation of documents
- Software development framework / guidelines
- Model verification
- Knowledge retention resource
3. Are there any major themes or patterns through the above answers? - Ontology implementations with real-time vs off-line requirements.
- Ontologies with decidability concerns.
- Ontologies with binary or other quality requirements (i.e. you can't make mistakes when designing planes, you can tolerate mistakes in designing social sites)
I seeded answers to these questions with a high-level synthesis of the previous discussions, but please feel free to adjust. I didn't add this to the wiki because I'm not sure where it should go, if at all - again, feel free to add to the appropriate wiki page+section if useful.
Best, Ali
--
_________________________________________________________________
Msg Archives: http://ontolog.cim3.net/forum/ontology-summit/
Subscribe/Config: http://ontolog.cim3.net/mailman/listinfo/ontology-summit/
Unsubscribe: mailto:ontology-summit-leave@xxxxxxxxxxxxxxxx
Community Files: http://ontolog.cim3.net/file/work/OntologySummit2011/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011
Community Portal: http://ontolog.cim3.net/wiki/
|