Dear Matthew,
Thank you for your suggestions, I definitely will use them in next version of this text.
Sure, our «ISO 15926 Reference Data Engineering Methodology, version 3.0» is not sole methodology in ISO 15926 domain. There is JORD Mapping Methodology -- https://www.posccaesar.org/attachment/wiki/FiatechJord/JORD-ISO15926-Mapping-Methodology-V2.doc (I think that you will name it as «methodology» while I will name it as «practice»), there is compliance evaluation specification v2 https://www.posccaesar.org/attachment/wiki/FiatechJord/JORDComplianceSpecification.doc and checklist v8 https://www.posccaesar.org/attachment/wiki/FiatechJord/ComplianceChecklistv8.2.xls for it, and we have many other development practices that was developed by ISO 15926 community members.
Your suggestions (e.g. ontology commitments) is fragmentary described in Parts of Standard (e.g. Part 2 of ISO 15926 describes 4D extentionalism, not miss with existentionalism – Google not distinguish them!), and in other literature about different related topics (see «ISO 15926 self-education methodology», pun intended, at http://levenchuk.com/2012/10/01/iso-15926-self-education-sequence/). But one of the problem in ISO 15926 was absence of ontology-related project life cycle description in terms of it practices.
MW: Yes. That self education list is an excellent resource.
Ailev2: Creation of this list show evidence of absence of good learning materials: too much overlapping texts, too few exercises, too long learning time. This list is a workproduct that provide framework for evaluation of ontology usage entry threshold (“what time is needed for master in usage of this particular ontology for this particular methodology of it usage”) and also helps to determine current competency level for ontology learner (“he is already knows Part 2 but have no actual mapping tools knowledge yet and no template knowledge”).
I found that people first need knowledge in overall process (methodology aka method aka development process aka development life cycle set of practices), from artifact-of-interest (reference data that is close to ontology) conceive to development to use to modernization to retirement.
MW: Do you mean a process model for the things you are managing the lifecycle of, or the lifecycle of the ontology about the thing? Both are important, but if you are talking about the former, then I certainly agree. When I first got involved with engineering standards for the process industries in PISTEP, the first thing we did was to develop a high level process model.
http://homepages.rya-online.net/matthew-west/pistep/Documents/Ppeam.pdf
Is that the sort of thing you mean?
ailev2: no, I mean not a) process of “process plant” that captured in P&ID diagram, not b) plant/system engineering life cycle process (sequence of stages that filled with systems engineering practices) but c) «ontology process» that is «ontology development life cycle process» (this “artifact process” is a common word to refer to development part of software/system full life cycle. E.g. situational method engineering standard OMG SPEM 2.0 is «Software Process Engineering Metamodel», on base of “software process” that need to be engineered (i.e. we need an artifact that model “software process” and have and engineering endeavor to obtain such a model compliant to prescribed metamodel). There are many terms that refer to life cycle (set of stages) filled with practice (life cycle processes – requirement elicitation and analysis, architecturing, coding, etc. ) execution in software engineering domain: method = methodology = software process = life cycle model = development process. These all are almost synonyms. Sure there are ontological nuances (several of this terms refer to period of time of set of works, several to work patterns (classes of work), several to actual work instances, several mean not full life cycle but only project life cycle, etc.). But most of people even not think about it: “software process is about some set of practices that somehow executes distributed in time of software project to produce software system” and use all mentioned as almost synonyms.
My point here is replicate this way of [method/software process/life cycle model] description to ontology artifact development method. I suggest to have best standard of software process description (software development method description, software methodology description, software life cycle model, software development practices – this is all almost synonyms with few nuances in meaning) that now is OMG Essence and tweak it to fit ontology development. I consider that programming, ontologizing and modeling is the same kind of activity in principle. Thus it should be productive to have an “approach” (“approach” is a reference to a borrowing concepts that developed in one domain and applying to another domain. E.g. “system approach” refer to concepts that developed in biology and applied elsewhere). I take situational method engineering as a set of concepts and apply it to ontology engineering domain.
Yes, it is difficult to speak about several levels of meta here: method of method description that applied to our ontology development method :-)
Then I repeat with clarification: «I found that people first need knowledge in overall ISO 15926 reference data engineering process (methodology aka method aka development process aka development life cycle set of practices), from artifact-of-interest (ISO 15926 reference data that is close to ontology) conceive to development by enterprise data modelers to use in system data federation projects to modernization to retirement».
After this overall activity spaces and related entity types understanding they are ready to listen about “details of ontology-related work” (that you call “methodology” here) that is practices: added detailed description of work products and related activities (actions with work products), related notations, etc.. Sure, what is «methodology» is viewpoint-dependent (people tend to specialize at certain life cycle stages practices, managers like to omit any details about work products and emphasize activities, etc.) and therefore subject to discussion. Thus I prefer start with some kind of situational method engineering standard (that define method/practice/development life cycle ontology) and not create ontics with one or two terms from scratch. My previous choice was ISO 24744, my current choice is OMG Essence. E.g. change “software system” to “ontology artifact” and try describe health of ontology project in terms of state of this abstract entities (this is picture from Essence standard that establish small ontology for development process -- http://semat.org/wp-content/uploads/2012/02/2012-11-01.pdf):
This picture can also ask for us to discuss more clear separation of intrinsic and extrinsic aspects of ontology in development process (not only intrinsic and extrinsic aspects of verification/validation/evaluation practices of this overall process). It seems to me that my example of ISO 15926 reference data engineering methodology is more extrinsic by nature and your comments are more intrinsic.
MW: Yes. Both are important of course. However, the way I would approach ontology development is very much to identify the processes that are of interest and then the things that are needed to support those things. You then need the lifecycle processes to support those things, which may in turn throw up more things needed to support those processes, which in turn need lifecycle processes etc. until you no longer identify new things of interest. There is also a basic process architecture for an enterprise that starts with its core processes, which you can derive from its mission statement, and ends with a supply chain process for acquiring what they do not do themselves. In between you have the parts of the lifecycle processes that they do perform that support the core processes. A good test for processes is whether they actually support (directly or through other processes) the core processes of the enterprise.
ailev2: exactly! Actually we in TechInvestLab have 2 different projects now: PraxOS (that dealing with enterprise engineering and trying to establish some kind of model-based or even model-driven enterprise engineering set of practices) and .15926 that is about ontology development. These are interdependent. High-level enterprise modeling (aka enterprise arcthitecture) and low-level enterprise modeling (models that reside in enterprise information systems like CAD/CAM/PLM/ERP/CRM/EAM etc.) is heavily dependent of coping with describing of all this models as a whole (i.e. we need some kind of a megamodel -- term from AtlanMOD group that refer to “model that describe how a complete and distributed model of a system composed from a smaller separate models of that system parts and models of system aspects”) and determining what is missed in modeling: what models (of processes, of artifacts, of other models, etc.) we still need to thoroughly describe enterprise at needed level of details.
Sure, we insist in the same “what change sequences aka enterprise processes we have in enterprise” approach that you depicted.
But in this specific “ISO 15926 reference data development methodology” we have a very narrow scope: we start when some other development show us need for specific data transfer. Then we start our specific ontology development lifecycle. It is very easy include in our specific methodology something “foreign” to domain-of-interest. We call it “domain chauvinism” because you can grab all the activities of all the enterprise from every domain and this can be justified (ontology modelers will be taking over enterprise architecture, enterprise architecture taking over operation managers, operation managers taking over strategic managers etc.). Every methodology should have non-chauvinistic scope to deal with its own domain, its own cognitive framework. Therefore we have “actual data transfer and actual data sets” precondition for start execution of our ISO 15926 reference data development methodology. No datasets to federate – no reference data methodology usage. Yes, this is debatable, there can be zillions of methodologies (set of practices and guides about moments of these practice usage) that composed from the same practices.
E.g. we can suggests that JORD RDL should have completely another reference data development methodology (they can start with reference data filings that have origin in enterprise reference data development projects. E.g. first work is happen at enterprise level and compliant to our methodology and then enterprise ontology “yellow belt” modeling team execute practice of our methodology “submit reference data that of general value to higher level RDL” and at JORD RDL level “black belt” modeling team start methodology of reference data development that essentially “refining and verifying of usability of submitted reference data on all system life cycle stages, not only on life cycle stages that was verified at enterprise level”. Both methodologies can have similar practices, both are about “ISO 15926 data development”, but this is completely different methodologies.
I am more inclined to have a presentation on track C (development methodology) than track B (examples of evaluation). May be we can settle this somehow.
MW: We would be delighted to have you of course. Where are you with talking to Track B about that (this is your choice of course).
ailev2: I wrote a letter about this to track B (you was in addressee list) 2013:01:21, but no answer yet. Sure, in that letter I suggested to Track B alternative speakers from ISO 15926 community.
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.
Dear Anatoly,
That is an extremely useful document.
«ISO 15926 Reference Data Engineering Methodology, version 3.0» (http://techinvestlab.ru/files/RefDataEngenEnglish/RefDataEngen_ver_3_English.doc)
I’m not sure I would call it a methodology, but it is certainly an outline of the process to implement ISO 15926 for cross industry integration, and brings out the key issues that need to be addressed. I would expect that a methodology would define how you do the various processes described, most of which should be in the ISO 15926 standards (if they aren’t already).
So for anyone who wishes to understand how engineers approach applying ontology to their industry, this is recommended reading. You may find quite a few unfamiliar terms, but Google should provide answers for all of these. If not ask Anatoly or myself.
Some of the things I would expect to see in a complete methodology for ontology development are:
- The specification of the ontological commitments to be applied (usually in the form of an upper ontology) that determines the ontological paradigm (e.g. 3D/4D) – For ISO 15926 this is largely in Part 2.
- The use of relations that transcend the ontological paradigm, e.g. classification, specialization, set theory, powerset, whole-part, topology. Again for ISO 15926 this is mostly in Part 2.
- How the domain specific terms and rules are identified, integrated into the whole, and used. You described that in outline.
- How ontological templates/patterns are developed and used to achieve consistency and allow the use of lower skilled staff to develop the ontology. Again you described that in outline.
- Arbitrary rules such as naming conventions needed to achieve cohesion and consistency amongst a large and distributed development team.
- How instances are used to validate that all the intended models (model theory sense) can in fact be supported.
Notice that because some of these are related to the ontological paradigm, and some are arbitrary, it is relatively easy to create good methodologies that conflict, so I think it is particularly important to identify methodological elements that are paradigm specific or arbitrary, since there is not much point talking about right and wrong when comparing different methodologies when looking at these elements.
It would be good if you can present this paper as part of Track C, but I know you are already presenting on one of the other tracks, so we may need to give others a chance.
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.
By the way we at TechInvestLab had an attempt to use discipline of situational method engineering for description of ontology engineering methodology. Our «ISO 15926 Reference Data Engineering Methodology, version 3.0» (http://techinvestlab.ru/files/RefDataEngenEnglish/RefDataEngen_ver_3_English.doc) is about one year old and roughly based on ISO 24744:2007 «Software Engineering -- Metamodel for Development Methodologies» (http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=38854). We informally checked that our methodology have all the prescribed by ISO 24744 parts that needed for comprehensive development method description.
We will be glad to get any comments to out attempt of ontology-related (“reference data” is one of many euphemisms for “ontology”) methodology development effort.
We have plans to rewrite current version 3 of our text in a couple of month to have account of ISO 15926 new developments (mainly ISO 15926 ontology patterns usage) in a method content aspect and have a compliance to contemporary situational method engineering standard OMG «Essence-Kernel and Language for Software Engineering Methods» (http://semat.org/wp-content/uploads/2012/02/2012-11-01.pdf, have plans to be approved by OMG in February 2013) in a method format aspect.
Best regards,
Anatoly Levenchuk
http://ru.linkedin.com/in/ailev/
Dear Matthew,
Thank you for making a good step away from the “sacred” but fairly useless often quoted definition of ontology.
See further in line below as [[Sjir2: ….]
I welcome your reaction as well as reactions from other colleagues.
Regards
Dear Sjir,
Dear Colleagues,
This is the opening post for Track C: Building Ontologies to Meet Evaluation Criteria.
When you make posts on this track please us the {quality-methodology} label in the subject line as I have above.
Background
There are two approaches to assuring the quality of an ontology: [[Sjir: Ontology is currently an homonym; please make first a series of clear definitions (enriched with many examples) such that the homonym problem is solved.]],
MW: Well I’m not sure there is a generally agreed definitions of what an ontology is [[Sjir2: indeed, I agree with you and I believe this forum should admit that clearly, and start work to get to a series of definitions that can be assigned to the widely varying kinds of “ontologies” mentioned in this forum.]], but we are not talking about the philosophical study of what exists. [[Sjir2: I agree.]] My definition for the purposes of this summit is:
A formal (i.e. computer processable) representation of (some of) the things that exists and (some of) the rules that govern them.
[[Sjir2: Another proposal: A complete and truely conceptual (in the sense of ISO TR9007) ontology is a formal (i.e. computer processable) representation of
a. the kinds of things considered within scope of a certain ontology,
b. the kinds of facts about instances of these kinds of kinds and
c. all the associated integrity rules about the fact populations and fact population transitions.
d. There is always a human understandable representation (in a CNL), that is extended with a set of all relevant concept definitions.]]
Examples can be as diverse as Cyc, a database schema, and Master Data.
1. Measure the quality of the result against the requirements that it should meet and fix the defects. [[Sjir: I suggest to take the three principles (Helsinki, 100 % and Conceptual) of ISO TR9007 into account.]]
MW: I’m sorry, I don’t follow you there. Could you elaborate please?
[[Sjir2: ISO TR9007 (TR stands for Technical Report, often a predecessor of a standard) was an effort by ISO that started in 1978 and was finished in 1987. It includes a validatable definition of a conceptual schema (The description of the possible states of affairs of the universe of discourse including the classifications, rules, laws, etc., of the universe of discourse. (Page I-4) ) and the following three principles:
The Helsinki Principle
Any meaningful exchange of utterances depends upon the prior existence of an agreed set of semantic and syntactic rules. The recipients of the utterances must only use these rules to interpret the received utterances, if it is to mean the same as that which was meant by the utterer. ISO TC97/SC5/WG3- Helsinki 1978 (Page 0-2)
Conceptualization Principle
A conceptual schema should only include conceptually relevant aspects, both static and dynamic, of the universe of discourse, thus excluding all aspects of (external and internal) data representation, physical data representation and access as well as all aspects of a particular external user representation such as message format, data structures, etc. (page I-9)
100 Percent Principle
All relevant general static and dynamic aspects, i.e. all rules, laws, etc., of the universe of discourse should be described in the conceptual schema. The information system cannot be held responsible for not meeting those described elsewhere, including in particular those in application programs. (page I-8)
2. Use a process or methodology to ensure the quality of the resultant ontology. [[Sjir: I stongly agree with this.]]
That is, Proactive versus Reactive.
The advantage of using a methodology are that you get it (or at least more of it) right first time, thus avoiding the cost of rework to fix the defects. [[Sjir: I stongly agree with this.]]
- Do such methodologies exist for ontologies? [[Sjir: that depends on what you mean by ontology. Informally yes, but that is outside the “ontology”” community.]]
MW: I believe there are also some within the “ontology” community, as well as the broader data modelling/relational database community. [[Sjir2: please let me know which ones.]]
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.
- How mature are they?
- Do they take account of different ontology roles, lifecycles? [[Sjir: yes, lifecycles have tob a taken into account if you want it become mainstream.]]
- Do they take account of the different usages of ontologies
- As applications
- As integrating ontologies between applications?
We hope to investigate the state of the art in ontology development methodologies in respect of how they contribute to ontology quality, including key achievements and gaps that currently exist.
Achievements: what's there?
Gaps: what's not there?
Our objectives include:
1. Examine the explicit and implicit methodologies that are known to exist.
2. Understand the role that upper ontologies play in ontology development methodologies.
3. Understand the role of ontological patterns in ontology development methodologies.
4. Identify how to apply the intrinsic and extrinsic aspects of ontology evaluation identified by the other tracks, within the applicable development methodologies.
5. Identifying how to frame the applicable ontology development methodologies within the frameworks of established quality assurance regimes (such as ISO 9000 and CMMI) for industrial applications.
Do you think there are some other objectives we should set ourselves? What is your experience in these areas?
As well as the discussion here, we have two virtual sessions on 7 Feb and March where invited speakers will present on some of the above.
Regards
Matthew West and Mike Bennett
Track C Co-Champions
_________________________________________________________________
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/