|
+1
This grounding is essential.
Observing the differences in people's sense of ordering and inclination to read into this, I'd suggest we do well to start with a basic picture of (some of the major) potenial relationships between the track topics, e.g.:
* use case characterstics (including larger system requirements and constraints) influence ontology requirements;
* ontology requirements influence applicable dimensions of evaluation,
* applicable dimensions of evaluation influence methods of evaluation,
* available methods of evaluation and their particular affordances influence lifecyle design to support use case requirements
...
and so on, making sure to note the influences in mutiple directions. The resulting picture should be as neutral as possible to the angle of approach, i.e., whether one tends to start thinking about this as a systems engineer, an ontologist, an evaluator, or a manager.
I think something like a concept map might start us out well, to get these points out there, shared, and less likely to cause confusion during discussion of individual topics.
Maybe some collaborative speed-mapping at, or between, pre-launches, might be useful.
Best,
Amanda
On Dec 12, 2012 4:39 AM, "Matthew West" < dr.matthew.west@xxxxxxxxx> wrote:
Dear Todd,
I agree with what I think is the basic point you are making here: We need to make sure that evaluation is grounded in meeting requirements.
So if we think certain evaluation criteria are important, like say reusability, we need to identify a requirement such as minimising cost across multiple applications that would give rise the that criteria being important. Sometimes of course that criterion might not apply.
Regards
Matthew West
Information Junction Tel: +44 1489 880185
Mobile: +44 750 3385279
Skype: dr.matthew.west matthew.west@xxxxxxxxxxxxxxxxxxxxxxxxx
http://www.informationjunction.co.uk/
http://www.matthew-west.org.uk/
This email originates from Information Junction Ltd. Registered in England and Wales No. 6632177.
Registered office: 2 Brookside, Meadow Way, Letchworth Garden City, Hertfordshire, SG6 3JE.
Fabian,
I understand the fuzziness problem with defining or distinguishing
tracks for the ontology summit. However, I'd like to keep the focus
(or implicit relationships) of all the tracks on the use of the ontologies,
why they're being created.
Regarding the requirements track, I would suggest it goes from 'here are
the system requirements', 'what are the derived requirements specific to
the needed ontologies' (assuming the system is not primarily focused on
delivering just ontologies), then 'what evaluation criteria, techniques,
or tools are needed to meet (all) the requirements'.
Todd
 Fabian Neuhaus ---12/11/2012 06:31:34 PM---Todd, This is a recurring issue of the Ontology Summit: the topic cannot be broken down into neatly
From: Fabian Neuhaus <fneuhaus@xxxxxxxx>
To: Ontology Summit 2013 discussion <ontology-summit@xxxxxxxxxxxxxxxx>
Date: 12/11/2012 06:31 PM
Subject: Re: [ontology-summit] Potential Tracks for Ontology Summit 2013
Sent by: ontology-summit-bounces@xxxxxxxxxxxxxxxx
Todd,
This is a recurring issue of the Ontology Summit: the topic cannot be broken down into neatly disjoint subproblems. However, in the past that has not turned out not to be a problem as long as the people who run the different tracks work together. The main purpose of these tracks is to give some structure to the discussions and focus the attention on a given aspect of the topic of the Summit. As long as they address identifiably different questions, it does not matter whether the boundaries are fuzzy. And I think this is the case here -- at least in my interpretation of Michael's email -- because the tracks address different questions:
The Dimension-track answers: What kind of activities are performed under the label "Ontology Evaluation"?
The Application Framework-track answers: Giving that my ontology performs function X in my application, which kind of ontology evaluation techniques are relevant to me?
The Requirements-track answers: Now that I know what kinds of evaluation techniques are relevant to me, how do I capture the specific requirements of my application in a way that supports these evaluation techniques?
Best
Fabian
On Dec 11, 2012, at 5:55 PM, Todd J Schneider wrote:
Michael,
Items 1,2, and 4 of your suggested tracks are, or should be,
intimately related. In the context of systems development the
requirements (hence uses) are the driver.
Todd
<graycol.gif>Michael Gruninger ---12/11/2012 12:59:52 PM---Hello everyone, in preparation for Thursday's Pre-launch of Ontology Summit 2013,
From: Michael Gruninger <gruninger@xxxxxxxxxxxxxxx>
To: Ontology Summit 2013 <ontology-summit@xxxxxxxxxxxxxxxx>
Date: 12/11/2012 12:59 PM
Subject: [ontology-summit] Potential Tracks for Ontology Summit 2013
Sent by: ontology-summit-bounces@xxxxxxxxxxxxxxxx
Hello everyone,
in preparation for Thursday's Pre-launch of Ontology Summit 2013,
here are some proposals for potential tracks.
One objective of the session will be to decide on the tracks and
specific topics that will be addressed within the tracks.
Please note that this list of potential tracks is meant to start the
discussion -- if you have other ideas for tracks, please join us
on Thursday's call!
1. Dimensions of Ontology Evaluation
- addresses notions of verification, validation, quality, ranking, ...
2. Evaluation and the Ontology Application Framework
- looks at the problem of ontology evaluation from the perspective of
the applications that use the ontologies. This Framework was one of the
outcomes of Ontology Summit 2011
(http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2011_ApplicationFramework_Synthesis)
3. Best Practices in Ontological Analysis
- focuses on the ontology evaluation based on the ontology itself, such
as logical criteria (consistency, completeness, modularity) and
ontological analysis techniques (e.g. OntoClean).
4. Requirements for Ontologies
- how do we specify the requirements against which we evaluate ontologies?
5. Environments for Developing and Evaluating Ontologies
- what are best practices for evaluation that we can adapt from software
engineering,
particularly with distributed open-source software development?
----
Michael Gruninger and Matthew West
co-chairs of Ontology Summit 2013
_________________________________________________________________
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/
<ATT00001..c>
_________________________________________________________________
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/
_________________________________________________________________
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/ (01)
|