Dear Hans, Actually it is relatively straightforward to make an ontology flexible and extensible if you have decided that that is part of the requirement, and it is about context rather than scope. Here I mean by scope what the ontology actually covers explicitly, and by context the range of extensions that are possible with what is in scope remaining unchanged. The key things that you need to do to achieve this are to avoid including constraints that are only true in the current scope, and to make sure that change over time is accommodated. 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. From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of Hans Polzer
Sent: 18 December 2012 23:51
To: 'Pavithra'; 'Ontology Summit 2013 discussion'
Subject: Re: [ontology-summit] Scope of ontology: Issues: Pavritha, The problem with requirements is that their scope is usually implicit, and rarely “explored” at the system/enterprise boundary because of the dreaded “scope creep” you mention, and that most project sponsors and program managers seek to avoid. This also leads to most major interoperability problems because other programs/systems/ontologies in the environment don’t share those requirements – they are considered “out of scope”. The trick to minimizing the potential negative consequences of overly narrow requirements scope is to widen the scope “aperture” at the outset of requirements analysis, and only narrow it after enough design consequences are explored to determine which dimensions of scope creep are affordable and likely to be cost-effective, and which should be left explicitly out of scope. It’s important to do this in partnership with the sponsors and representative stakeholders so that they can make an informed decision about requirements scope and its potential consequences, and it is equally important to document scope decisions explicitly so that participants continue to be aware of what those decisions were throughout the lifecycle of whatever artifact is being developed. The NCOIC SCOPE model is designed as a tool to facilitate this process for systems/enterprises that want to work with other systems in the environment to help achieve their objectives. Hans Hans Hello everyone,
Pardon me if I am interrupting. First of all what are Requirements ? How does it apply to Ontology and its application?
We define Ontology as the structure and behavior of a thing that exists naturally or man made.
If you have to define the requirements for Ontology for a bird, you have observer what it is, ( description like it has wings, beak, feather etc) and its behavior.
But if you have to define the Ontology of a plane, you have formal requirement specification to build a plane and operate a plane by inventor or formal authorized body.
I think requirements of defining Ontology ( description of structure and behavior) is what is used in developing specification for languages like OWL..
Again, is that what we call or agree on as Ontology requirements ??
In Software engineering/ system development, your stake holders and users define what the system should consists of and what it should do, and the rules associated with it, and processes to follow. The word "Ontology" is used in a abstract / conceptual way. In Software Engineering / Systems have well defined boundary of what the system should do, and there is a concept of scope creep to manage requirements and releases.
And there is a phase called Requirements Analysis do so as part of the life cycle. Here is link to wikipedia for description
http://en.wikipedia.org/wiki/Requirements_analysis
My two cents about requirements.. hope that helps,
Pavithra No, it is rarely “the” application, but application is always in mind, I think, when you develop an ontology. What, after all, are requirements? Requirements for what? Represent ontology classes, relations, properties (axioms) to a certain level of granularity? What is the targeted level of granularity and why? Personally I think you always have an application (applications) in mind when you develop ontologies. Reuse of an ontology occurs when you have another application(s) in mind. The application may be very general or very specific: provide a superstructure for mid-level and domain ontologies for semantic interoperability (of systems), enable semantic search by characterizing concepts to be used for conceptual “term” expansion or content-tagging, provide a basis for enterprise engineering, provide semantic integration for these 5 databases. To me, those are applications, albeit some are generic applications. No doubt, these ontologies have specific uses and intents. And these lead to requirements (although they might be unstated). But these requirements are not dependent on the requirements of a specific application. This is why I don't agree that their development "has to fit with the development of *the* application". On Dec 18, 2012, at 2:13 PM, Obrst, Leo J. wrote: Perhaps we can weaken it a bit, to a specific use or uses? I would still say that the Gene Ontology, DOLCE, BFO, etc., have specific uses and intents, even if the use/intent is something like “act as a foundational ontology linking 3D with 4D perspectives”, or “act as an upper domain ontology for Anatomy”, or “provide an ontology of quality spaces and tropes”, etc. I would not like to quite water it down to that of any artifact. I think the following is too strong. Ontology development is always dependent on application requirements, and so development of the ontology has to fit in with the development of the application.
This is certainly true for many ontologies. But there are examples (like the Gene Ontology, Foundational Model of Anatomy) which are not being developed for a specific application. On Dec 18, 2012, at 10:36 AM, Obrst, Leo J. wrote: Ontology development is always dependent on application requirements, and so development of the ontology has to fit in with the development of the application. Across the full lifecycle. In many cases, viewed abstractly, a very successful, sound ontology can be part of a failed application. In which case, failure can taint the ontology too, or worse, the prospects and value of ontological engineering/science. That is why, in our discussions, we have talked so much about “ontology and application lifecycle”. For example, developing an ontology may require also developing or promoting a vocabulary, even multiple vocabularies, that map to the ontology. These enable user communities to use their words and phrases, their presentations, while also ensuring the representation provided by the ontology. Vocabularies can include user interfaces (forms, graphics), but also data schemas, both relational and XML-based. So it seems to many of us that ontology evaluation has to address also application use and intent. An issue that I don't see clearly in the correspondence is: How does ontology development fits into the larger life cycle of information system development? Answering requires some statement on the scope of ontologies and how they relate to other knowledge and information models. * What are the different paradigms for roles for an ontology in information or knowledge systems? As a terminology to be carried by the information model? As part of the the information model? As a means of validating the information model? Reconciling multiple information models? Other? In each case is it one model or several? If several, how are the interfaces defined? Maintained? * How does this integration into use affect the life cycle? Can we avoid too close a coupling between the ontology development and other developments so that one does not become a drag on the other. In particular how to front loading development with the work on ontology development that the applications never get built. This has been a major issue in the Health Informatics area, with enormous effort going into developing resources such as SNOMED CT and the NCI Thesaurus with much less attention to how they will be used (not to mention the related front-loaded efforts in other areas of information modelling, e.g. both HL7-v3 ). Are these issues the Summit should address? (Or have I just not looked int the right place or interpreted the comments correctly) Professor of Medical Informatics School of Computer Science TEL +44 (0) 161 275 6149/6188
_________________________________________________________________
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)
|