3. DISPERSIÓN DE LOS CONTAMINANTES
3.5 Conclusiones del tercer capítulo
The conceptualisation of the ontology for the Product domain as has been described in this section is presented in Figure 3-5 using a UML class diagram. Classes that have ellipses within them represent concepts where the full extent of possibilities have not been conceptualised. This is because it is not necessary to represent all of the possibilities within the scope of this research and also because these concepts have already been well described in existing literature (see Lohse (Lohse, 2006) and Matthew and Rao (Mathew and Rao,
74
2010) for extensions on the Liaison class, and Lanz (Lanz, 2010) and Fenves et al. (Fenves
et al., 2008) for more general product ontologies). It is important to design the ontology in way that allows extension through clear superclass definitions and by providing examples of sister class concepts. Figure 3-5 further illustrates what exists within the bounds of the Product domain ontology and how it interfaces with the broader PPR model that is presented in Figure 3-2. The reader may note that there is no link between
QuantitativeFeature and the Skill model as is implied in Figure 3-4. This connection would in fact be managed through queries or rules which would navigate either from Assembly or
ProductComponent (which are connected to the Skill model) to the relevant value. This is elaborated on in the following chapter through case studies.
Figure 3-5 Product Domain Ontology
Product Domain
ProductFamily ProductVariant hasProductVariant 1..1 1..* Assembly 1..* hasAssembly 1..* ProductComponent 1..* 1..* Liaison hasProductComponentQuantity : integer hasProductComponentID : string contains 1..* hasLiaisonQuantity : integer hasLiaison 1..* 1..* 1..* ComponentFeature hasFeature 1..* 1..* QuantitativeFeature QualitativeFeature ScrewFitLiaison ConcentricLiaison KinematicLiaison ...Liaison hasMass : integer hasXDim : integer hasYDim : integer has... : integer Material Colour ... SkillContext hasSkillContext hasSkillContext Process isRealisedByProcess Product Operation hasOpNo : integer 1..* 1..* hasOperation75
Process Domain
In this section the topology and hierarchy of the Process Domain ontology as well as its connection to the other PPR domains and Skill model is presented. Lohse describes the purpose of the Process Domain ontology eloquently in Lohse (Lohse, 2006) as:
“…the translation of the spatial topological requirements of the product into temporally ordered capability requirements for the assembly system configuration process”
Essentially, this means to transform the Product Domain’s undirected graph into a directed one. In Chapter 2, some automated methodologies for achieving this are presented. The role of the Process Domain ontology is not to automate this process however, it is to store the knowledge generated as an output of this reasoning process (be it automated or manual) and link it to the other domains with a view to inferring new knowledge or ensuring consistency between requirements and capabilities. In Figure 3-3 the liaisons that exist between product components have been given numerical names. The numerical values represent unique identification numbers (IDs) which the Process Domain transforms into first a high level sequence and then a more granular description of the activities required to achieve a given liaison.
It is clear that there is a need to define the concepts for the hierarchy in the Process Domain ontology, however in contrast to the unsubstantiated claim of Lohse (Lohse, 2006), there remains (to this day) a lack of convergence on the levels, terms, and even the activities/responsibilities of this domain. Table 3-2 presents an overview of some works that have presented an ontology within the Process Domain. This list does not claim be entirely exhaustive or comprehensive review of Process Domain terminology, largely because search terms are unable to reveal hierarchies that may well use similar concepts through different words. Although not directly relevant, the terminology used in the Microsoft project manager software – Microsoft Project, is also referenced. This is because an analysis of existing process representations highlighted that project management tools such as Gantt charts were a specific type of representation that used their own semantics (Knutilla et al., 1998). However, to the author’s knowledge, consideration of the semantics used beyond the domain of manufacturing have not been considered to derive Process Domain ontologies in manufacturing in previous works.
76
Table 3-2 Summary of Process Domain hierarchies presented in the literature
Author Hierarchy (high to low) Lohse (Lohse,
2006)
Activity, Process, Task, Operation, Action
Lanz (Lanz, 2010) Activity, Process, Task, Operation, Action, Sub-action Lastra (Lastra,
2004)
Manufacturing Process, Assembly Task, Assembly Process, Assembly Operation
Demoly et al.
(Demoly et al., 2010)
Assembly Operation, Process
Borgo and Leitão (ADACOR) (Borgo and Leitão, 2007)
Process Plan, Operation
Ramis Ferrer et al.
(Ramis Ferrer et al., 2016)
Operation, Process, Task
Process Specification Language (PSL) (Bock and Gruninger, 2005, Grüninger, 2004)
Activity, Subactivity, Primitive
Microsoft Project (Chatfield and Johnson, 2010)
Summary Task, Subtask
The conclusion that can be drawn from Table 3-2 is that while some convergence exists with respect to the words, the hierarchical positions in which they appear are not consistent. This does not appear to be the case in the Product or Resource domains where the semantics remain largely consistent, albeit with differing topologies depending on the stance or perspective of the creator. This may be the case because both of these domains exist physically. On the other hand, the Process Domain is inherently abstract in nature. It is perhaps the domain most aligned with the definition presented by Borst et al. in (Borst et al., 1997) as the need for explicitly specifying what is only a “shared conceptualisation” is most apparent in the Process domain.
To elaborate, there are typically physical artefacts generated by the activities of humans within the Product and Resource domains. As a results, if humans no longer exist these physical artefacts will continue to exist. On the other hand, the activities or processes associated with realising these artefacts exist in the minds of humans. It is a shared reality
77
that is not tangible. This philosophical stance is important to express in this way because it:
i) identifies why there is a lack of consistency for defining processes in a systematic way i.e. the conceptualisation is not truly shared due to differing perspectives, cultures etc. (Note that this is partly true in the other domains but less prevalent)
ii) highlights that any choice of terms in the Process domain is likely not to be adopted more broadly. It is more important to define the relationships between the words chosen within this domain and others to generate a meaning
Based on this rationale, despite the importance of formal semantics in ontologies, the terms chosen to describe the Process Domain are not an instrumental part of the methodology. The important aspects are, as mentioned above, the definitions which are defined through the relationships that exist within this domain and between others.