Megan, This meshes nicely with my presentation on the dimensionality of ontology assessment context. Certainly assessment context and scope is an important component of ontology requirements. I also want to emphasize that for ontologies, unless they have a very specific and narrow use, it’s probably better to talk about “ranges” of requirement attribute values rather than specific “point” requirements. “Point” requirements (e.g., a single project or system) can be viewed as a special case of requirement attribute value ranges, with some required attributes having only a single acceptable value (no more, no less), or a value limit (no more than or no less than). More generally, the required attribute value should be within some acceptable range for the intended ontology application context range/scope. Having said that, I would like to draw your attention to the fact that requirements entail “requirees”. And these are often institutional in nature, albeit usually represented by specifically designated role players. And they have scope in institutional and operational/academic domain space. Certainly for some ontology evaluation contexts, this forum can serve as the institution defining requirements for some ontologies of interest, but outside the immediate evaluation context setting of this forum, some other institutional and domain context will have to define its own context and scope within which the ontology requirements will be defined. This forum can offer up a list of possible ontology requirement attribute categories, attributes, and attribute value ranges to choose from, as well as rules/criteria/principles for selecting additional ontology requirement attribute sets and value ranges (mostly in the area of extensional attributes) that might be domain-specific. We should also encourage the explicit identification of the institutional context and scope of the source of any ontology requirements and develop means/conventions for maintaining the association between any ontology requirements and their institutional source and their intended/applicable evaluation context ranges. Hans From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Megan Katsumi
Sent: Thursday, March 21, 2013 8:19 AM
To: ontology-summit@xxxxxxxxxxxxxxxx
Subject: [ontology-summit] The Importance of Understanding Ontology Requirements Hi All,
On behalf of myself and Michael Gruninger, I'd like to share our thoughts on the importance of requirements to this year's summit, for your discussion and review.
We believe that the focus should really be on the requirements. Discussions about ontology development and evaluation all hinge on a common understanding of ontology requirements. How can we say whether one particular development methodology is better/more appropriate than another if we don't have a common understanding of the sort of requirements they are using?
In our methodology, we specify ontology requirements as competency questions and metatheoretic definitions of intended models. This allows us to more directly translate the requirements into properties of the ontology's axioms, such as consistency, entailment, definable interpretations. Throughout the summit we have seen a variety of other perspectives on ontology requirements, for example quality or business-oriented requirements.
Analogous to methodologies in software engineering, we can also consider the distinction between functional and nonfunctional requirements for ontologies. We consider functional requirements of an ontology to be the semantic requirements that we have discussed earlier, that is, properties of the ontology's axioms and models.
Nonfunctional requirements would encompass properties such as modularity, readability, tractability of reasoning. The idea is that two logically equivalent ontologies satisfy the same set of functional requirements.
If there is a requirement that is satisfied by one ontology O1 but not by another ontology O2, even though
O1 and O2 are logically equivalent, then that requirement is nonfunctional.
There have also been some discussions in Track B about the relationship between ontologies and the systems that use ontologies. The relevant question might be how software requirements lead to ontology requirements. In many cases, what some people consider to be extrinsic factors in ontology evaluation are perhaps referring to the ways in which software requirements are shaping the ontology requirements.
We think that one key result of this year's summit should be a set (framework?) of agreed-upon ontology requirements:
- what are the different kinds of requirements?
- how are they defined?
- what purpose do they serve?
- how can they be verified?
- how can they be validated?
It is our position that clear answers to these questions should be a priority as they will provide a solid foundation for continued work on development and evaluation methodologies. We look forward to your feedback on this. Regards,
Megan Katsumi |
_________________________________________________________________
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)
|