I was mentioned tree times in the “life cycle table” :-)
Think this is because life cycle is the central topic in systems engineering and languages of situational method engineering often call languages of life cycle description. Therefore I mentioned “life cycle” more often than others.
Here are my preliminary remarks about “folk” life cycle terminology that captured in multiple methodology description standards like ISO 15288, ISO 24744, etc.:
1. There are multiple life cycle concepts. Most often this “life cycle” (that is nor life neither cycle) homonym refer to
a. Period of time from conception to retirement of a system-of-interest.
b. Process (sequence of activities) that happens with participation of a system-of-interest.
c. Kind of life cycle activities/practices pattern spread to (often referred as “life cycle model”, sometimes “software process”) the sequence of life cycle stages.
d. Multiple other concepts (e.g. “project life cycle” that is part of the full life cycle that fit to project time frame, or “development life cycle” that is part of the full life cycle within only development stages but not operations and retirements, etc.)
2. Life cycle usually have 2 dimensional pictures (e.g. “hump diagram”): horizontal time axis is about stages (phases in military standards), vertical is about activities (like requirement engineering, architecture design, implementation, verification&validation etc.). In “waterfall lifecycle model” activities/practices and stages have the same names, but there are multiple other life cycle models (spiral, unified process, scrum, etc.) with different stages and activities/practices names.
3. Most contemporary ideas about life cycle is in draft of OMG Essence standard (there are state sequences of ALPHAs, and synchronization patterns of these states in time frames (stages) gives different life cycle models. Practices are drive this ALPHAs from states to states (see slides 18, 33, 34, 35 with examples of different life cycle models here: http://www.slideshare.net/ailev/semat-overview-v3). Main idea that you should account not only sequence of system states, but other (opportunity, stakeholders, requirements, work, team, way of work) states too. That is “ontology life cycle” is not definable, because you can define only «ontology state sequence» and provide much more descriptions to catch specific “life cycle model” for particular ontology development style.
4. There are 2 types of events in life cycles: milestones (checks of overall project progress) and gates (decisions “go-no go” about funding of next stage). There are principle of “gated development” when we have evaluation of intermediate states of development. Therefore we have “evaluation” of some kind in the next relations to life cycles (recursions in system hierarchy and iterations are ignored for simplification):
a. Evaluation activity (usually validation and verification) – is about practices used
b. Evaluation stage (time period that devoted mainly for evaluation activity)
c. Evaluation of stage results for a gate decision “go-no go”
d. Trade-off deliberations during stages (e.g. evaluation of preferred architecture among three candidate architectures that was developed)
5. In ISO 15926 (that is formally “life cycle data integration” standard) “life cycle data” refer to plant life cycle (usually process plant that have life cycle from stages of conception, architectural design, design, construction, commissioning, operation and maintenance, retirement). “Life cycle data” is data that appearing and using in any part of this life cycle. ISO 15926 is 4D ontology that try to present this plant life cycle data in 6th normal form (because of normalization that perform with account of time domain, life cycle is all about time).
6. Therefore most of mentions in my presentation was about plant life cycle, not reference data life cycle! But you missed reference data life cycle activities/stages (we have it 1D, like in waterfall life cycle model, activities=stages) that was present in presentation:
1. Project dataset identification (this is ontology for federation purposes. First you need to find samples of what you will be transfer between information systems).
2. Identification of Data Description Items (you should parse these data sets and find elements there. This is not easy, e.g. you have indirect property with UoM: how many items you have?).
3. Characterization of Data Description Items (this is core ontology development activity: sequence of «What is X?» questions. I call it “intrinsic ontology methodology” and have an example of two “ontology fragment for Data Description Item” development life cycle diagrams on slide 9 “Patterns (intrinsic aspects)”. Why patterns? Because today in ISO 15926 community we have data/ontology patterns as most high level of ontology representation. Nevertheless, most other “ontology methodologies” refer to this activity/step).
4. Mapping (we should define transformation of raw data of source and target data set to and from ontology format. In .15926 Editor we have special ISO 15926 DSL on base of full general multi-paradigm programming language Python for defining of these transformations aka “mappings”). Mappings is based on ontology (aka reference data) developed on previous stage. Therefore we have 2 artifacts: ontology and mappings. Ontology goes to reference data library, mappings go to information system adaptor software.
5. Project data transfer (actually run project data with mappings/adaptors developed in previous stage). Ontology is not using here, only mappings.
6. Verification of transfer results (this is actual verification: e.g. you take 3D plant model in one CAD system that use their specific geometry format, have transferred in another CAD system with another geometry format, and then see your plant model not similar to original. Where is error? It can be in mappings, but equally it can be in reference data).
7. Actually this is not a full life cycle of ISO 15926 ontology data: if this is ontology fragment (microtheory) of general interest it can be submitted to additional evaluation to RDL of higher level (JORD RDL is top level). Main point for this evaluation is prove that this ontology is fit for using during all plant life cycle (e.g. have “TemporalWholePart” relationship: if it have no such relationships, it is suspicious that this ontology fragment was developed by “yellow belt” ontologists (“data modelers”) for usage during data transfers within one stage of plant life cycle (e.g. multiple plant operation information systems), not between stages (e.g. “hand over” of plant data between design and operations information systems). People that have competencies for evaluation on international/full plant life cycle level is called “black belt”. This “competency levels” is important because deal with ontology evaluation and no other ontology community have such practice for qualification levels to evaluation on different level of ontology generality on relation to system life cycle.
Hope that something about these multiple life cycles and multiple evaluations in it became more clear that after my oral presentation :-)
This letter is more suitable for “life cycle” part of tracks synthesis than my original slides.
Best regards,
Anatoly
From: ontology-summit-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-summit-bounces@xxxxxxxxxxxxxxxx] On Behalf Of terry.longstreth
Sent: Sunday, February 24, 2013 8:00 AM
To: Ontology Summit 2013 discussion
Subject: [ontology-summit] Fwd: Re: [ontology-summit-org] OntologySummit2013: Ontology Lifecycle - Explicit Description?
While I was preparing the table below, Todd and Leo started a dialogue on the summit-org list on the same topic, so I've included their exchange after the Table.
I hope to be able to do little more research and propose a reasonable synthesis lifecycle. I probably won't make it into any of the live panel sessions, but we can discuss it on this list.
Terry
This table is the result of my review of the presentations from the first four track panels. I collected all references to Lifecycle (or in one case, simply 'cycle'). I didn't review the 'mid-term' presentations from this week (22 Feb), and because I was pressed for time, I didn't look at any of the session chairs' intro charts
My purpose was to illustrate that there are many perspectives on Lifecycle. I think it's clear that we don't have a clear consensus on the meaning of Lifecycle expressed in the Summit title.
Terry |
Day | Track | Presenter | Lifecycle Label | Phases | NOTES |
24 Jan | B | Schneider | No | | |
| | Polzer | Ontology Life Cycle Phase Dimensions | (1)The need for, and scope of, an ontology have been developed
(2)Some portion of the formal representation of the ontology has been developed
(3)All of the planned formal representation is complete
(4)The ontology is populated with instance data
(5)Reasoners have used the ontology to achieve real-world results
(6)The ontology is in operational use
(7)The ontology is evolving based on feedback from operational use | |
| | Balboni | Black Box Testing Paradigm | (1)Unit Test
(2)Integration
(3)Functional
(4)System
(5)Acceptance
(5)BETA | |
| | Katsumi | Lifecycle to support the development of expressive Ontologies | Design
Requirements
Verification
Tuning
Application | |
31 Jan | A | Poveda | No | | |
| | Tartir | No | | |
| | Duque-Ramos | No | | |
7 Feb | C | Smith | No | | |
| | Partridge | No | | |
| | Levenchuk (1) | Life Cycle Data Pyramid | Data Model 201
Base Templates ~ 2000
Base Data ~ 200 thousands items
Specialized Data Standard: ~ millions
Specialized Data Non-standard (Proprietary): ~ tens of millions
Project Data ~ billions | |
| | Levenchuk (2) | ISO 15926 Equipment Life-Cycle | Stage 1 – Standardization and Supplier's Catalog
Stage 2 – Typical Design
Stage 3 – Particular Plant Design
Stage 4 – Plant Procurement
Stage 5 – Plant Operations | |
| | Levenchuk (3) | Mapping Methodology: Place in the Life Cycle | Process Design
Plant Design and Detailed Engineering
Procurement and Construction
Operations and Maintenance | |
| | Bennett | No | | |
14 Feb | D | Denny | Ontology Development Phases | Exploration Phase
Management Phase -
Design Phase
Build Phase
Validation Phase
Integration & Use Phase
Maintenance Phase | Each Phase described in one or more pages. |
| | Gruninger | No | | |
| | Holm | No | | |
| | Matthews | Ontology and Architecture Evaluation Cycle | •Before check-in, locally
– Validation: Automated, syntax and inherent checks
• Within the hour, from source control (CruiseControl)
– Validation
• Nightly build and index
– Validation
– Search Quality: Automated, black box, TREC methodology
– Unit tests: Automated, glass box, semantic, regression and functional
• Fortnightly push to production
– Validation, search quality, unit tests
• Monthly QA cycle | |
-------- Original Message --------
Todd,
You are right that we have not in general explicitly referred to the ontology lifecycle. But comments in the chat sessions continue to raise this issue, along with some bullets in previous presentations. The short answer is intrinsic, extrinsic, and in-between aspects of evaluation are required at every step of the lifecycle, but they will be different based on the stage of the lifecycle. E.g., if we assume that the ontology lifecycle is similar to but extends the typical software/system lifecycle, then we have at least the usual way-stations or processes of the latter lifecycle, i.e., approximately:
- Rationale (goals, objectives, at least initial, but subject to refinement)
- Analysis (generally requirements, but also what potential resources meet the requirements, and so it loops into Design, Implementation, etc.)
- Design (also Architecture: see below)
- Implementation (potentially complex)
- Deployment (potentially complex, since may involve many applications, some of which call each other)
- Maintenance (potentially complex)
There may be many cycles in the above, i.e., within each major process, but also loops between one process and others. The graph structure may vary (topology if you wish), depending on the implicit meta-model, i.e., linear/waterfall, spiral, etc.
Each of these processes have "testing" near the end of its process instance, which we can think of as a validation/verification of the results of the process, which can therefore lead to a refinement/correction. This is standard for software engineering/system. Initial Design may have Architecture as a sub-process, which itself repeats, loops.
Of course the complexity of the above is also affected by the size of the effort.
Also, Track C is looking at process improvement, so the above is probably most rooted in that track (I'll talk a bit about this and ontology architecture in the next Track C session, as I'm sure others will).
Thanks,
Leo
>-----Original Message-----
>From: ontology-summit-org-bounces@xxxxxxxxxxxxxxxx [mailto:ontology-
>summit-org-bounces@xxxxxxxxxxxxxxxx] On Behalf Of TSchneider
>Sent: Saturday, February 23, 2013 1:21 PM
>To: ontology-summit-org@xxxxxxxxxxxxxxxx
>Subject: [ontology-summit-org] OntologySummit2013: Ontology Lifecycle -
>Explicit Description?
>
>Though this year's summit subject is about the 'ontology lifecycle'
>I don't recall any explicit description thereof.
>
>If I missed it, could someone send me a link to where is was described
>among the sessions?
>
>Thank you.
>
>Todd
>
>___________________________________________________________
>______
>To Post: mailto:ontology-summit-org@xxxxxxxxxxxxxxxx
>Msg Archives: http://interop.cim3.net/forum/ontology-summit-org/
>Community Files: http://interop.cim3.net/file/work/ontology-summit-
>org/OntologySummit2013/
>Community Wiki: http://ontolog.cim3.net/cgi-
>bin/wiki.pl?OntologySummit2013
_________________________________________________________________
To Post: mailto:ontology-summit-org@xxxxxxxxxxxxxxxx
Msg Archives: http://interop.cim3.net/forum/ontology-summit-org/
Community Files: http://interop.cim3.net/file/work/ontology-summit-org/OntologySummit2013/
Community Wiki: http://ontolog.cim3.net/cgi-bin/wiki.pl?OntologySummit2013