Skip to content
Create an account for full access.

Concept of the service

Ontology is a small closely related set of concepts (usually types of some subject area) and relationships between them. Around the Service, which is executed by some Enabling System (let's use terms in CamelCase, meaning each word starts with a capital letter, to highlight terms for types of ontology), the following types of objects can be identified (this is a meta-meta-model):

  • Service as a type of Work (not a practice/activity/labor) performed by a Service Provider (service, server, this is the Enabling System) over the Blank for the future Ready System (although the service may not provide full readiness).
  • during the Service Passage,
  • consisting of individual Sessions,
  • Participants of which are Blanks and interacting with them through the Interface to the Blank Service Providers.

Further on, of course, one needs to consider a multitude of various situations to which this ontology can be somehow adapted. For instance, the service passage may not be with a single blank but with a batch of blanks, if it's a training course, then students::blank also interact with each other in a flow::batch. System levels can also change, so we carefully observe what the Blank and Ready System are like.

Here are a few examples of reasoning using the service ontology:

  • Grinding is an operation::service of the grinding provider, which manufactures a grind in the blank (the blank of the future ready system as a carrier of the grind, the super system of the grind - meaning the Ready System is one level higher, and the target system of the grinding operation will be the grind) during the grinding operation::service. The blank participates in the grinding session, as well as the grinding provider (connecting to the blank via the interface). Whether the blank will be renamed to the detail::Ready System depends on how the execution of the grinding operation and the creation of the grind::functional part of the Ready System will be the final work/service here (roughly speaking, the "caterpillar" is renamed to the "cocoon" only if the metamorphosis is complete). Further consideration can be done on what the grinding provider is: a grinding machine, a grinding machine and the people servicing it ("equipment and the people assigned to it") or people and the grinding machine assigned to them (it's the same thing, but if it's "machine and its people", it's easier to discuss automation, removing people, and if it's "people and their machine", it's easier to discuss who to contact if the machine is not working).
  • Training Course is a service of the course provider that imparts mastery to the student::blank (here too the student is the super system-carrier for the future master::Ready System, the target carrier for the mastery course) during Course Passage/"course sequence", consisting of class sessions. The student in 4D participates (participation, specialization part_of) in the flow, meaning a set of classes, as do the course provider (connecting to the student via the interface) and other students (if there are no other students, meaning the sessions are not group sessions, then the concept of "flow" is not used, they talk about a "set of classes"). Whether the agent playing the role of the student will be later renamed to the master::Ready System - it also depends on whether this is the final course in some series. In the flow, the agents playing the roles of students::"master blanks" interact not only with the teacher (or the computer assigned to the teacher - if automation is planned and eventually people will be removed), but also with each other.
  • Game is a game provider service that stimulates dopamine production in the player during Game Passage, consisting of Game Sessions. The player participates in the game passage by participating in sessions, as does the game provider through the interface to the player (and in group games, participants can interact with both the provider and each other). The player does not become a Ready System after the game (although their state changes! They may get tired, rest, or get upset from losing) and certainly does not become a Ready System after a game session (there is no equivalent of renaming a "caterpillar" into a "butterfly" with possible intermediate states, because there is no radical change, not even a not very pronounced one like transforming the "student" into the "master").
  • Treatment Course is a treatment provider service that creates a healthy part of the patient's organism (blank for the future healthy person, carrier of the healthy part) during the course, consisting of treatment procedure sessions.
  • Improvement Project is a development provider service that, during the improvement project, makes some adjustments/changes in mastery without altering the ontology of that mastery (for example, corrections are made to the settings of the grinding machine, and the machine operators undergo training to not have to look at the instructions every time but do everything "by memory". In this situation, no new concepts and relationships emerge, the grinding ontology remains unchanged).
  • Development Project is a development provider office service, which develops new mastery (enhances existing mastery, meaning adds a feature, "modernizes", does something with the current mastery ontology) in NewCapability::Ready System during the development project through a series of development steps, consisting of training courses, leadership events, projects preparing tools/equipment (these are specializations of Development Steps::sessions).

So, the service ontology seems to be the same for the most varied situations, but there will always be nuances, so not only the terminology will change, but also the types of objects in the ontology will change.