Linked Enterprises: deriving a hypermodel from ArchiMate (May 2022)
Dr Nicolas Figay, HDR
Let's prepare and build the continuous operational Interoperability supporting end to end digital collaboration
Introduction: ArchiMate
ArchiMate is an enterprise modeling language specified by the Open Group, and defined as a common simple language for supporting communication between different kinds of architects and stakeholders. It aims at aligning technical architecture, architecture of applications and and business organization architecture with the motivation of the enterprise, through a continuous implementations and migrations.
The descriptions of architecture are aligned with ISO 42010 (Systems and software engineering — Architecture description): a model with a set of views defining according a set of viewpoints, with associated concerns, stakeholders and subset of modeling constructs to be reflected in the views.
ArchiMate also considers aspects (active, passive and behavioral elements) and layers (strategy, business, application, technology, physical, implementation&migration). Aspects and layers constitute each a partitioning of the 74 ArchiMate modeling constructs, including Entities (ArchiMate elements) and Relations. This partitioning is reflected by the Open Exchange Format for ArchiMate (also provided by the Open Group), and relying on a set of 3 XML schemas formalized with the XML Schema Definition (XSD) language: one for models, one for diagrams (views) and one for viewpoints.
In addition to the Open Group Specifications and documentations provided by the tools implementing the language, I've been publishing several LinkedIn articles and research articles exploring the different features , advanced usage and sometimes limitations of ArchiMate: PLM interoperability: the potential of ArchiMate viewpoints, Project management and ArchiMate viewpoints, Dealing with continuously changing environment by using ArchiMate?, When ArchiMate meets UML: how to conciliate Enterprise Architects and Software Application Designers, When Enterprise Architecture and MBSE meet in an Agile Context (part 1)?, When Enterprise Architecture and MBSE meet in an Agile Context (part 2)?, PLM Interoperability: when ArchiMate meets ISA-95 manufacturing standard, When ArchiMate meets Cloud, When ArchiMate 3.0 meets Production and A neutral PDM model to reuse by Enterprise Architects in ArchiMate?
ArchiMate could even, if addressing some of its limitations, be used for collaboration within a network of enterprises working around a manufactured product (cf. Advanced usage of ArchiMate for Dynamic Manufacturing Living Lab or in order to support Enterprise Navigation Systems (cf Enterprise Architecture: from Drawing to Enterprise Navigation Systems with ArchiMate).
Possible advanced usage if addressing some limitations
However, according to the assessment of the interoperability of the ArchiMate digital business ecosystem (cf. ArchiMate and Interoperability: what are the potential issues you could have?) based on the schemas of the Open Format (cf. What do we learn from exchange format schemas study?), it occurs that opening ArchiMate to the Semantic Web for linking distributed Enterprise Architecture description in heterogeneous environment should provide an important business value.
Opening ArchiMate to the Semantic Web should provide an important business value.
This article explores fist the required efforts for deriving an ontology using the Ontology Web Language (OWL2) in order to take the full advantage of the associated technologies, but also with the System Modeling Language (SysML), in order to take advantage of modular representation of complex composite systems.
It opens some perspectives on the idea of having to provide multiple representations relying on different languages of the enterprise models in ArchiMate, what is called an hypermodel.Defining hypermodels should allow to define Digital Threads for you enterprise assets and capabilities, despite the heterogeneity of the technologies and software products realizing your applications.
The ArchiMate entities, relations and associated constraints
ArchiMate version 3.1 comes with 62 modeling entity types and 11 kind of relations types.
For each kind of relation, ArchiMate specifications define if each kind of element can be related or not with another kind of model element. For implementing an ArchiMate modeling tool, it lead to consider a table of allowed triples (mc1, r, mc2) with mc1 and mc2 modeling constructs (entities or relations), but not both mc1 and mc2 being a relation), and r a relation.
Such a table is available in Archi (ArchiMate relationships) like illustrated by the following figure. It is based on the ArchiMate 3.1 specifications, which also described allowed relations with other relations as ends.
Considering only relations between elements, the potential number of triples to consider is equal to 62*62*11=42284. The number of allowed triples is equal to the number of letters in the previous table. the number of not allowed triples is the difference.
Formalizing ArchiMate with OWL
Very often, the simple way to proceed is the following: ArchiMate modeling construct are formalized as an OWL class and an ArchiMate relation will be formalized as an OWL Object Property. At this stage, it takes only few minutes formalizing ArchiMate in OWL as illustrated by the two following screen captures.
Let's note that categorization of relationships used in ArchiMate 5.5 were used in the previous picture (Dynamic, Structural, Dependency on Other relationships)
Some can consider that formalizing ArchiMate in OWL will take only few minutes
The things are more complicated as soon as willing to capture what are the allowed relationships. For an object property, OWL allows to define for each relation a domain and a range. Domain defines a class or a union of classes for which individuals belonging to the domain can be the starting element of a link typed according to the considered relation. It is the same for the range for individuals at the ending side of the link.
But what about capturing the numerous constraints related to relationships?
A first approach we can think about is the following one:
Unfortunately, this mechanism is not precise enough for capturing the allowed triples and those which are forbidden. E.g. if considering the composition relation (c), Resource and Capability are both in the domain and in the range of this relation. But a Resource can't be composed of a Capability (no c in the intersecting case) and Capability can't be composed of a Resource (no c in the intersecting case). In OWL, having both Resource and Capability in the domain and in the range of the composition relationship allows a resource and a capability to be linked with links typed as composition. It demonstrates that this approach is not the appropriate one for enforcing allowed and forbidden links defined by ArchiMate.
Defining domain and range for each kind of ArchiMate relationship represented as OWL object property is not suited
A first way I found for capturing such constraints was the following: for each ArchiMate relationship r, let's create a set of object properties, one per ArchiMate modeling construct mc belonging to the domain or the relation (i.e. having the relation appearing in the line): r_from_mc, r_from_mc being a sub-property of r. The range is then captured only for r_from_mc, using the same mechanism than the first proposed approach. Having each ArchiMate modeling construct belonging to the domain of each relationships should result in creation of 62*11=682 object properties. In fact, all the modeling constructs don't belong to all domains of the 11 relationships, there will be less object properties to create. In addition, the most generic ArchiMate relationship, the "association" relationship, belongs to all the cases of the table. It means that all ArchiMate modeling constructs belongs to the domain and to the range of this relationship, and that we can use the first approach, an "association" object property with domain and range being the union of all the ArchiMate modeling constructs.
An alternative consists in replacing lines by columns and to consider sub-properties r_to_mc. It leads to the same number of sub-properties to be created.
We can see that considering the constraints for allowed relationships implies quite more work than just capturing all the modeling constructs and the relationships.
Creation of a number of complementary OWL sub-properties is a way which requires some work
It is possible reducing the number of sub-properties to create by creating classes having the same range for a number of properties. E.g. for "access" relationship, a class "accessor_type1" can be created for a set of classes which have the same range for the access relationship. A single relationship can then be created for this set, with as domain "accessor_type1", as soon as all the classes of the set are defined as sub-class of "accessor_type1". The cardinality of the set being n, n relationships are then replaced by a single relationship. Let's call it "factorization of equal range" for the article.
It is illustrated with the following figure and by the figure of the article.
When using a reasoner, all the Access_Relation links can be inferred from the more specialized links Access_Relation_from_typedSetOf . This is illustrated in the following figure, showing the result of a DL query on individuals linked with specialized Access_Relation_from_typedSetClass. It provides the list of Business Events accessing (Access_Relation) some Business Objects. In our example, such a relation is inferred from explicit access relation of type2 which is more specialized.
When a given relation exists for a whole line or a whole column respectively, then the concerned class formalizing the modeling construct can be put on the domain or on the range of the relation respectively, without any creation of complementary relation.
When factorizing, a situation allows reducing even more the work to be performed: it is the case when the domain and the range are the same. E.g. it occurs with the "Trigger" relation. It is then possible using a class which is the union of a set of classes, and to use this class for the domain and for the source as well.
Note: it also simplifies the expression of equivalent OCL rules when defining ArchiMate over UML/SysML2.
In addition, if really willing to create an ontology, some more is required:
All this must be done by the ArchiMate community, with the support of ontology designers:
A lot more is required for producing an ArchiMate ontology
Such an exercise should probably result in providing a more consistent version of the ArchiMate language in terms of Descriptive Logic. It also allows identifying some weaknesses or errors on the specifications or implementations. E.g. I identified that the Technology Event is not on the same class of accessors (i.e. the range is not the same) than the other Events (Business, Application...).
What can motivate this? Going further, it seems accurate considering that something that can "access" something else is something active. So should we consider that modeling constructs being in the domain of the "access" relation should be only active modeling constructs? Then, going through the specification (ArchiMate 3.1), we find that effectively "The access relationship models the ability of behavior and active structure elements to observe or act upon passive structure elements." So not only active but behavioral modeling elements should be able accessing passive elements.?If the case, the allowed relationships defined in the Archi table should be changed. At this stage, I was not able to check in detail if what is in the table matches with the specification. It is also mentioned in the documentation of this version of Archi that some more work is needed for relationships).
A last potential issue I identified is the support since ArchiMate 3 for creation of a relationship having as end one other relationship (see previous figure), which should correspond in OWL to a typed link being able to link another typed link. Initially, I thought it can't be supported by OWL, except may be using punning. The punning concept is illustrated by the two following figures, with Assessment being at the same time an OWL Class (with two instances) and an instance of the ArchiMateModelingEntity OWL Class. The same URI is used, so it is the same thing which is at the same time an OWL Individual and an OWL Class. Unfortunately, the Ontograph visualization plugin of Protégé is not able drawing the typed links between assessment_001 and assessment_02, which is only indicated as an object property assertion in the second figure, named "AssociatedTo". "AssociatedTo is in fact the type of the link between these two individuals, and is also formalized as an OWL Object property and an individual typed as ArchiMateModelingRelation, two things with the same URI which constitute a second illustration of punning.
But in OWL, a link is not represented by a thing but is represented by a pointer from a thing referencing another thing. It is illustrated in the next figure by the RDF/XML representation of the Association link between assessment_001 and assessment_002, for which not dedicated URI exists. So the link can't be subject to punning.
As a consequence, it means that OWL2, even with punning, will not be able to easily capture ArchiMate models using this new capability consisting in being able to create an association with as end one other association.
As an alternative, some specialists who read the first version of this article suggested defining each ArchiMate relation as an OWL class with two object properties: source and target. It should lead to something as illustrated in the following picture: creation of an individual for each link (e.g. accessLink001) and relation of type SourceRelationshipForAccess and TargetRelationshipForAccess to instances of model elements for which an Access relation is to be created. It's quite not simple to interpret, as what is expected is to have an arc formalizing the oriented relation "Accesses" from facility001 to contract001.
Obtaining such an arc can be achieved defining also an object property for the relation. Punning is not suited, as it prevents usage of reasoning: Access is first considered as a class, never as an object property. So the object property to be created must have another IRI. For illustration I choose AccessR, labelled Accesses. Then it is possible, by defining an OWL chain, to state that AccessR is the combination of the inverse for the source link and of the target link. It is illustrated in the following picture.
So relations are represented each as an OWL class and two OWL object properties, one being the inverse of the other.
Then, launching the reasoning engine, the relation of type AccessR between facility001 and contract001 is inferred automatically, as shown in the following figure with the result of a DL query.
Unfortunately, such inferred link is not displayed by the OntoGraph Protégé plugin, except if making inferred element explicit by exporting them.
However such an approach is promising, due to inferencing capabilities based on OWL 2 chained properties and don't need to use a complementary rule language, e.g. SWRL. The appropriate method is to be validated, with the appropriate level of maturity, i.e. shared practices and available tools.
In addition, selecting this strategy doesn't prevent to study what will be the required work for capturing all the constraints in the ArchiMate relation table.
At least, 11 OWL classes are to be created, plus associated 22 ObjectProperties for defining targets and sources, the inverse nature of these properties and the domain. Considering the 11 previously corresponding object properties defining relations, the appropriate chain is to be declared for allowing inferencing as described in the previous figure. Also, for each declaration in the ArchiMate relation table, a restriction of the form:
(inverse_of_SourceRelationshipForRelation some ObjectTypeSource) and (TargetRelationshipForRelation some ObjectTypeTarget )
with Relation one of the 11 ArchiMate relations, ObjectTypeSource being the object concerned by a row and ObjectTypeTarget being the object concerned by the target. The previously described factorization should allow reducing the size of the restriction to produce. E.g. concerning how it will look like:
((inverse_of_SourceRelationshipForAccess some Accessor_Type1) and (TargetRelationshipForAccess some (Equipment or Location))) or ((inverse_of_SourceRelationshipForAccess some Accessor_Type2) and (TargetRelationshipForAccess some Location))
The most effective factorization should be produced, relying on the rules defined in the ArchiMate specifications, which provides a taxonomy (hierarchy) for the modeling concepts of the language.
What was produced concerning domain and range definition is not required relying only inferencing for reification. But asserting links between the individuals, the instance of the OWL classes for relations will not be automatically created, so the defined restrictions will not applicable (In OWL, using inference engines only created links, not individuals!).
It is also to be mentioned that testing and experimentation is needed in order to avoid mistakes in rule writing, or behavior of the used reasoning engine. As a consequence, it is needed to be able to generate test data set automatically, as creation by hand is very long. The different tests to be performed and the accurate test data sets are to be carefully defined. E.g. I generated automatically 3 instances of each ArchiMate entity type: A, B and C. Then I generated automatically for each kind of relation a link between A and A, A and B, and B and C. This data set aims at experimenting and checking what's going on with reflexivity and transitivity according the kind of rules and constraints defined with the ArchiMate ontology. The following figure illustrates what can then be visualized in Protégé with OntoGraph.
领英推荐
The required resources for defining and producing tests and test data sets is not to be underestimated, for the quality of the produced ontology.
Coming back to ArchiMate, the capability consisting in being able to create an association with as end one other association is very useful e.g. for indicating what flows between two model elements (e.g. a data object between two nodes). Such missing capability was a weakness of the previous version of ArchiMate. However, one issue is that anything can be associated, without indicating explicitly the nature of what can be associated. E.g. when considering flows, it is also possible to associate to a flow relationship instance of an actor or of any behavior when following the ArchiMate 3 specifications.
How do you interpret the following?
In UML2, it is possible to define an arc defining a flow, and to associate a conveyedInformation to this arc which point on an object (mechanism used in the article "Equivalent IDEF0 and SysML models"). It makes explicit that what is associated to the flow is a conveyed information.
The exercise is suited for producing a more consistent specification of the language from a semantic point of view.
Going further introducing the not formalized knowledge provided by the specification
For specifications such as ArchiMate, it often occurs that information are written in a human language, but not formalized in the language. It is particularly true for all what is "around" the language, such as the context of usage and some categorization defined which are not primitive of the language. E.g. the views and viewpoints, associated stakeholders and concerns, their level of granularity and the purpose.
One interest of OWL is that it can not only allow provide an alternative representation of the language, but it can also capture much more a formal way.
It is also possible capturing definitions or to formalize some rules, making the produced "ArchiMate in OWL" quite more useful and useable.
The following figure shows introduction of categorizations defined by ArchiMate specifications, but not on the language.
The following figure shows formalization of concepts related to viewpoints and how it is applied to ArchiMate.
The following figure shows capture of concepts related to extensions by profiling.
Finally, the approach adopted here also illustrate the potential of data integration through semantic technologies, which is an alternative to profiling (I must admit I prefer this approach and I will develop it in a future article).
Optimizing the number of rules to produce for capturing constraints
An alternative for creation of some abstract classes for reducing the number of constraints consists in defining OWL constraints as logic expressions for valid and not valid relations.
Describing relation constraints as matrixes, we can make emerge homogeneous blocks and express a constraint for each. It can be done arranging lines or columns. It allows expressing constraints an optimized way, eventually using the abstract classes defined in the specifications of the language when it appears it makes sense (e.g. layers, aspects, etc.)
Here is an illustration for the Access relation.
The constraint created from such a matrix looks like the following (here for assignment):
It can be created similarly for Not_allowed_Assignment. So without constraining the data, it is possible identifying relations which are not aligned with the language constraints. One advantage: it is possible to relax or to extend the constraints for specific usage, in order for validating enterprise models in specific usage context. This will be subject to future articles and research papers.
The goal is to implement a tool chain for exploring potential of such a derived ontology.
Going further with composite modelling and extended hyper models for Interoperability
Performing the same exercise with UML2 or SysML will lead to the same amount of work. But we can take advantage of the work done with OWL in order saving some time, i.e. by reusing performed "factorization of same range", and deriving constraints in OCL form those created and validated with OWL2 constraints. It allows reducing number of OCL rules to create in order capturing the constraints of the ArchiMate relations table. The following figure illustrates the derivation of ArchiMate in SysML, for the entities (as SysML Blocks which are specialization of UML2) and relations as Relation Classes.
It is completed by a snapshot of the OCL rules created for accessors of type 1. A single OCL rule was created for each factorization (this will be the subject of future articles and papers for ArchiMate over SysML/UML).
In the previous definition of the relations, an abstract SysML Block (or UML2 Class) was created for both the source and the target. Then they were defined as generalizing the concrete Blocks which can be a source or a target for the considered relation.
However, it is not sufficient for constraining the rules defined in the ArchiMate Relations table. Some constraints are to be added, which can controlled with constraints checker provided by UML/SysML modeling platforms.
Finally, extending the user interfaces in order avoiding creation of non allowed relationships should be the next step, but it requires some programing and good knowledge of the specific modeling tool used. One drawback of such constrained user interface is that it is not flexible if we want to relax some of them.
Trying to model with ArchiMate over SysML/UML2 allows to think about what should be the changes to consider in order to provide a more consistent version of the ArchiMate language, not in terms of Descriptive Logic, but in terms of composite modeling (the awful term for this is "mereotopology", i.e. combination of whole-parts concern and topology).
Once done, ArchiMate will be useable both for composite modeling and for semantic interoperability. What could be done is illustrated by the following figure, describing (ArchiMate) collaboration between two (ArchiMate) applications, one being a Product Data Management (ArchiMate) application for a pre-design phase in an industrial program (named MIDIPIL), the second being the Product Data Management (ArchiMate) Application for the design phase in an industrial program (named PRIME). You also have the representation of a (ArchiMate) Business Function View, with (ArchiMate) actors and (ArchiMate) functions. (ArchiMate) aggregations and associations are also capture in these views. Unlike traditional ArchiMate modeling tools, you can produce composite representations of an organization, and adopt a modular approach for producing the Enterprise Architecture models. This definitively responds to actual needs within the enterprise. ArchiMate modeling capabilities are extended without changing ArchiMate, relying on UML2 and SysML modeling capabilities.
Waiting for such approach to be adopted and supported by modeling products, we can already do a lot with the Archi tool and modeling platforms providing ArchiMate UML profiles, which take into consideration in the modeling interface the constraints defined by the ArchiMate language specifications. The tool prevents creating any relationship between model elements when it is not allowed. For this, it relies on an EMF (Eclipse Modeling Framework) meta-model.
Waiting for consistent alternative representations, let's rely on Archi and ArchiMate plugins based on UML profiles
Most of them are implement the Open Format Exchange (OFE) format defined by the Open Group, based on a set of schemas defining with the XML Schema Definition language. It constitutes another way to define ArchiMate models, dedicated to exchange of models between modeling applications.
A particular focus was put on consistency when producing the set of ArchiMate realizations in OWL2 and UML2/SysML, aligned with legacy ones (Archi, OFE). It is a way avoiding creation of technological silos. The adopted approach was created for addressing PLM interoperability through a concept call "extended hyper model for interoperability". You can learn more on it through my research publications referenced on my linkedIn profile.
Providing new visualization capabilities
Considering the visualization capabilities available with Protégé 3 (Jambalaya), and the limited capability with Protégé 4 or 5 which are not taking into account what is inferred (Ontograph), I consider that some more advanced visualization capabilities are required for supporting the study of the ArchiMate language specifications.
I initiated it on top of vis.js, with as a first target creation of something which is Ontograph similar, but with the ability to display inferences as well. It could be used for providing enterprise interactive cartography from aggregated and linked data. You can follow it though a set of posts reflecting the progress and the different performed experimentation, e.g. combined visualization of model elements, views and viewpoints.
One important issue with such graph visualization is that it provides flat representation, which is not well suited when willing to represent modular systems of systems with different levels of granularity. This have been addressed relying on interactive compound graphs, relying on libraries supporting compound graph visualization, on top of data organized according to a graph metamodel, suited for graph analytics and application of algorithms based on graph and network theories. It led to the development of a prototype, aiming at be used as a proof of value and a proof of concept, ArchiMateCG. From a visual point of view, compound graphs can be automatically drawn from data and arranged according to automated layouts, combined with interactions allowing to collapse and extend nodes of the compound graph quite easily. The images below are capture of ArchiMateCG screens, illustrating the kind of graph visualization which can be performed.
Dealing with Interoperability and linked enterprise architecture models
Considering the open exchange format for ArchiMate provided by the Open Group and implemented by many modeling tools and enterprise architecture repositories (cf. the status concerning the interoperability maturity level of the ArchiMate digital eBusiness community at ArchiMate and Interoperability: what are the potential issues you could have?) , we could be willing to translate these models in OWL in order to be then able to link these models and to extend platforms supporting usage of ArchiMate models.
We can also managed consistency of multiple representations of an enterprise model in ArchiMate on top of multiple platforms based on semantic web technologies, model driven architecture or emerging knowledge graph technologies (e.g. grakn.ai, Neo4j, etc.) Such landscape is explored in the article The emerging landscape for distributed knowledge, ontology, semantic web, knowledge base and graph based technologies and standards.
Willing to address these cases impacts the way to derive an ontology in OWL from ArchiMate, with many different valuable usage of capabilities associated to OWL solutions, in particular the reasoning engines. E.g. the previous figure shows how to define consistent ArchiMate models on top of OWL or Grakn.ai, choosing and validating the different semantic mapping options between these languages.
Dealing with Interoperability and aggregation of composite enterprise architecture models
A Proposed approach was discussed in a dedicated research article of future research papers proposing and validating an innovative way to deal with interoperability based on hyper models for interoperability, previously studied for PLM interoperability. The following image shows that is was possible to define an ArchiMate modeling platform on top of a compound graph libraries, making the model suited for applying algorithms based on graph and network theories: research of the shortest path between architecture model elements, clustering, automated colorization of graphs, etc.
It has also been the topic of several posts and articles, with as tag #archimatecg. Let's follow
About polyglot hypermodels for interoperability
The initial idea was developed in my thesis in 2009. The idea was to be able to used a full model driven chain in order to design and generate interoperable applications, on top of interconnected application servers, Enterprise Service Bus and Enterprise Horizontal portal. For this, one issue was the usage of heterogenous languages all along the development chain. How then to avoid data loss and ensure semantic preservation despite several translation/transformation of the initial conceptual model to design and implementation model, and then in code executed in operational execution environments?
The approach was initially considering ontologies in OWL, schemas defined with EXPRESS or with XML Schema and Computer Independant Model formalized with UML. At this time, compositions, aggregations and containments were not considered, even if it was identified as an issue if willing to build and prepare an actual interoperability. The research work undertaken the following years aimed at addressing such a limitation, and led to several research articles. It was supported by prototyping and experimentation, which are reflected in this article. The following figure is a recent representation of what could be mad, if considering visual modeling.
The tool chain previously described will be extended as following and even more, including compound graph plaforms.
My position evolved, leading to consider that :
So the idea consists in considering the consistent formalizations of ArchiMate relying on different languages, giving the ground for developing digital continuity and consistency for distributed enterprise data across the various platforms hosting and processing them for various purposes and relying on various technical capabilities: classifying and checking the logic consistency with OWL, producing modular representations of complex organisation with UM2 or SysML, solving problems relying on network and graph theories with emerging graph related solutions, exchanging and sharing models with XML/XMLSchema or EXPRESS/P21, to feed knowledge database relying on various technologies, etc.
Each branch of the hypermodel is dedicate to a specific ground, i.e. an versioned software product deployed and used within the enterprise, if possible relying on an open standard. We can establish a Digital Thread in order to links critical information about the enterprise and its transformation. It will result in productivity gains, improved response to enterprise needs with sustainable feedback loops for innovation. It can also be a valuable contribution for the support of digital twins and digital threads.
Some new ideas to be developed, which I will share through posts, articles and research papers
Let's follow. Don't hesitate to react, and if you think they bring value, let's share and like them ;)
References
The OWL file used for this article is available on GitHub at : https://github.com/nfigay/archimate.owl
Don't hesitate to contact me if you want to contribute.
Providing Business with analytic Edge
1 年Wonderful article! Your vis.js representations (esp that 4rd one) look exactly like the sort of thing I used to use the venerable Axon Idea Generator for. I am a big fan of those tools that let you work fluidly in Graph representation and text representation (triples). Some recent work was with LeanIX and DOT. I really miss the flexibility of Axon but it's getting tough to sustain using it. You have me enthused to revisit Archimate, and this hypermodel sounds like a good point of departure.
Technical lead | Public sector | Modeling fan
3 年Very interesting topic and a big effort on it. Thanks for sharing. IMHO I think that in order to achieve better interoperability, what you need is transformation tools. In this case I would recomend to use bidirectional (when possible) reactive (a plus for real-time) graph transformations tools like VIATRA2. Then have a single source of truth, that you can synchronise on-demand, from/to EMF repositories like CDO (or some neo4j solution). This repo schema can be generated using xsd2ecore for Archimate or OWL. And use EmF genmodel to parse or generate XML. You can even parse and generate excels in VIATRA2 using libraries like Apache POI. Then use a single language for you queries, VIATRA2, to simplify, or maybe use the repo query languaje (check neo4j in that case) Need more formats? OData? JSON-LD?... ( I pretty hate JSoN based stuff because its reinventing the wheel yo get the same func as XML)
Principal information architect & diagnostician at Ripose Pty Limited
7 年Dr Dr Nicolas Figay Thanks for this article. The question I ask is: why do people still use this? It is not that there are no other alternatives - perhaps the alternatives that others have looked at and have tried also failed to meet expectations. Is it perhaps no one is looking at the right alternative? Do they know what the better alternative is capable of? Better still do they actually know what they 'need', rather than what they 'want' in a modelling toolset? Regards
As indicated by comments from Irene and Steve, you don't really seem to understand OWL very well (in that domain and range are not constraints, and that for the sort of constraint you do want then Restrictions are the obvious mechanism). I just wanted to add that you do not need the punning approach you describe if you create OWL classes (instead of ObjectProperties) for each type of relationship (you can have a ArchimateRelationship superclass) together with ObjectProperties "source" and "target". You can additionally use OWL property chains to allow direct linkage between the source and target of a relationship (inverse of "source" followed by "target").
Ingénieur IT hétérodoxe & Devops curieux
7 年Thanks for this article which also illustrates that a technique / theory of (meta) modeling may not be suitable to meet some specific modeling goal. Also, in my opinion, any attempt to "translate" a metamodel from one paradigm (structural modeling with EMF) to the other (DL in owl) is doomed to fail. For example, behavioural aspects of the modeling elements (EOperations on EClass) - that are not treated here - are another big challenge. Some of those issues are dealt with by the OMG #SMIF initiative. At @Openflexo, we are building a federation engine to provide another way to have models interoperate. It would enable you to work in the same "engineering space" with both a EMF compliant Archimate model and any OWL ontology/ies, or additional EMF model.... and even non traditional modeling tools such as your favorite office suite.