Sure, Hans, which means you need to consider not just today’s requirements (du jour), but how your ontology decisions will bind you badly if you don’t think
about problem issues of the future that the development managers haven’t yet considered. We don’t develop ontologies with a requirements check-list: yeah, did this, did that. We know how bad ontologies, like bad models and bad programs will affect not just
the current effort, but subsequent efforts. Because you are problem-oriented doesn’t mean that you are a taxi-driver looking at your meter.
I view the ontology lifecycle and the software lifecycle longer, and force managers to consider issues beyond their horizon or to build in measures in the ontology
which accommodate those requirements that you know will come, should you achieve initial success. Yes, the larger business model drives this too, so today’s application is today’s application in a larger process model. We consider extensibility and reusability
with every effort we do.
Thanks,
Leo
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx]
On Behalf Of Hans Polzer
Sent: Tuesday, December 18, 2012 6:19 PM
To: 'Ontology Summit 2013 discussion'
Subject: Re: [ontology-summit] Scope of ontology: Issues:
Leo,
But the challenge is how wide to broaden the scope of an ontology beyond that of the immediate application. If the ontology developed for an application is
too narrowly scoped, it risks having to be redone when the application environment evolves, even in ways that could have been anticipated. This is the same challenge faced by those who want to develop “reusable” software or software services that are flexible
enough to support uses and users other than those who are currently demanding such services (i.e., those specifying the application requirements). A key issue here is that requirements specifiers/sponsors rarely look at requirements from a dynamic, evolutionary
perspective. And, of course, there has to be a business model supporting a broader scope for software/services and ontologies than the immediate application at hand. Otherwise it makes perfect sense to build an ontology just for the immediate requirements
and no more, even if that risks major rework at some later date. Having said that, I believe taking a more dynamic, evolutionary perspective on requirements even in such narrow situations allows one to explore and uncover areas where the ontology could usefully
broaden its scope without incurring significant additional development and test costs. Put differently, if you start out with a broader perspective, but then focus on implementing a narrower scope the end result will typically be better than if you use the
reverse sequence.
Hans
Hans
Todd,
Nearly every ontology development project I have been involved in since 1995 has been for specific uses and applications. Yes, you may bring in DOLCE, BFO,
SUMO, Cyc, etc., and existing mid-level or domain ontologies, but it is always to address a problem, which means an application or multiple applications. We are tightly wedded to application, not just research, and even if it is research, it is focused on
an application problem.
Thanks,
Leo
And, yes I've seen RFP's asking for ontologies or their development
for specific uses, but this is still rare.
Todd
|