One more thought I meant to include in my earlier email is that of tying ontology assessment and ontology life-cycle to that of Model Based Engineering, not just “Big Data” and software or system architectures and related life-cycle models. Ultimately, ontologies are models and all models have (usually implicit) ontologies. A key obstacle to realizing the vision of model based engineering (MBE) is that it entails relating models of different types, detail/specificity, and, and development life-cycle phase relevance to each other. Typically, stakeholders with different perspectives and domain vocabularies are involved in developing the various models that need to be related/coupled to each other. Formal/explicit ontologies offer the potential for improving this state of affairs, both in making each engineering model/artifact more understandable and “mappable” to related/dependent models, and in developing “integrating” ontologies that formally define mappings between different model types across life-cycle phases. Citing the relevance of ontologies to MBE would also help bridge the divide between the “information” communities and the “engineering” communities.
Hans
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Polzer
Sent: Friday, December 07, 2012 6:49 PM
To: 'Ontology Summit 2013 discussion'
Subject: Re: [ontology-summit] Ontology Summit 2013
I always find scope discussions interesting, for obvious reasons. If the focus is on assessment, then explicitly defining the assessment context and the scope of that context and the assessment will be key. Architecture paradigms and methodologies such as TOGAF, specifically and EA, generically, usually contain semi-explicit scope assumptions, such as “enterprise-wide”, but unfortunately rely on the intuition of the practitioner as to what constitutes “enterprise-wide” scope. That, in turn, is usually driven by the practitioner’s local frame of reference, namely the specific enterprise that the practitioner is employed by or engaged by. The scope of the particular enterprise itself is rarely questioned or defined explicitly, except in some cases of “enterprise re-engineering”.
In addition to being clear about the scope of the assessment context, or, more precisely, the range of assessment contexts for which ontologies might be assessed, one should also be aware that the assessment context is distinct from, although related to, the application or operational context in which the ontology (or architecture or method) might be used. If interested, I can forward a strawman set of assessment context dimensions as a starting point for consideration. It was developed for a critique of the DoD Net-Centric Principles, which had a similar problem of not being clear about the assessment context ranges in which they were intended to be applied (or not, as the case may be).
Hans
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Amanda Vizedom
Sent: Friday, December 07, 2012 3:39 PM
To: Ontology Summit 2013 discussion
Subject: Re: [ontology-summit] Ontology Summit 2013
Not directly, I'd suggest. More precisely:
-- I agree with Steve's comments regarding the need to keep the focus *clearly* on evaluation, in order to have a sufficiently defined scope. The need for a clear and steady filter angle of approach for summit topics and sessions is a consistent summit risk-point.
-- To the extent that TOGAF/EA does come in an call for special attention, I suggest that it needs to happen organically, via the attention to evaluation.
-- That said, there are a number of ways it might happen organically. For one thing, depending on the use case, the suitability of an ontology often involves the match/mismatch between its provenance and its provenance requirements. Both of these can intersect importantly with the architecture. For another, ontology requirements for a use case have many points of contact with the architecture. Finally, gathering and analyzing requirements, a step without which meaningful/predictive ontology evaluation cannot be done, is (notoriously) more often skipped than conducted, even in many cases in which some type of ontology evaluation is attempted.
- So, architecture and evaluation clearly have implications for each other. It is surely going to come up in a number of ways. But calling out TOGAF, or other aspects of EA practice, IMHO should be done only as directly motivated by the evaluation focus as described, and with care to keep that focus central. Same with SWE and KA methodologies and frameworks, I'm thinking...
On Fri, Dec 7, 2012 at 3:05 PM, Todd J Schneider <todd.schneider@xxxxxxxxxxxx> wrote:
John, Amanda, Michael,
Should consideration be given to injecting TOGAF
into the summit structure?
Todd
John F Sowa ---12/07/2012 11:29:06 AM---On 12/6/2012 11:47 PM, Michael Gruninger wrote: > "Ontology Evaluation Across the Ontology Lifecycle
From: John F Sowa <sowa@xxxxxxxxxxx>
To: ontology-summit@xxxxxxxxxxxxxxxx
Date: 12/07/2012 11:29 AM
Subject: Re: [ontology-summit] Ontology Summit 2013
Sent by: ontology-summit-bounces@xxxxxxxxxxxxxxxx
On 12/6/2012 11:47 PM, Michael Gruninger wrote:
> "Ontology Evaluation Across the Ontology Lifecycle"
That's an important topic. But the lifecycle of an ontology is
co-extensive with the lifecycle of any application or system that
uses or is based on that ontology.
This morning, I sent replies to two email lists that most people
on this list subscribe to.
1. To Nancy W. on IAOA, I made the point that you can't separate
the ontology of a system from its architecture or design.
2. To Rich C. on Ontolog Forum: "Imagine an IT department that had
one group doing the architecture, a second group doing the design,
a third group doing the ontology, and a fourth group doing the
implementation."
Amanda responded,
> Sadly, John, some of us don't have to imagine this; we can remember it!
I would relate that point to evaluation: a critical issue in a good
ontology is its accuracy in reflecting the design and/or architecture
of the system.
There are aspects and modules that could be distinguished. For
example, the complete ontology of a system might combine multiple
modules or microtheories. But the complete ontology of a system
and its complete architecture must be closely coordinated.
Any evaluation of an ontology must address these issues.
John
_________________________________________________________________
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/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/
_________________________________________________________________
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/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013
Community Portal: http://ontolog.cim3.net/wiki/