Applying Multi-Level Modeling to Data Integration in Product Line Engineering Damir Nešić Mattias Nyberg ITM/MMK/MDA ITM/MMK/MDA Royal Institute of Technology Royal Institute of Technology Brinellvägen 83, Stockholm, Sweden Brinellvägen 83, Stockholm, Sweden damirn@kth.se matny@kth.se Abstract—Developing systems according to the Product Line ficulties. The goal of PLE is simultaneous development of a Engineering (PLE) paradigm is a process in which different multitude of different product configurations. In other words, types of engineering artifacts are created with the aim of reusing an additional challenge is to access and manage the data that them in different configurations of the same system. Ensuring that different system configurations satisfy various functional allows contextualizing the analysis operations with respect to and non-functional properties is ensured by analyzing different possible product configurations. Similarly to the artifacts data, artifacts but because they are maintained by different tools, it is common that the data describing the applicability of an sometimes even manually, achieving and especially automating artifact to a particular product configuration is scattered across such analyses is a challenging task. Overcoming this issue can be the lifecycle in different forms [4], [16]. achieved through data integration of existing data which implies creating an information model that specifies how will the existing Enabling access to the data necessary for designing dif- data fragments be related, captures relevant domain constraints, ferent analyses can be achieved through data integration [9] and most importantly captures the fact that some data objects are techniques that can be used to extract and integrate existing classes in one tool and instances in another. This paper reports artifacts data from individual tools without modifying the on the experiences from applying the Multi-Level conceptual existing tool landscape or enterprise processes. Next to the Theory (MLT), to the problem of information modeling for data integration in the PLE context. Being a Multi-Level Modeling, traditional approaches for data integration [9], [12] suported powertype-based framework, MLT allows separation of the class by technologies like relational databases [13] and ER or UML and instance facet of modeled entities while keeping them explicit. information models [13], the idea of Linked Data (LD) [5] Some of the MLT modeling constructs are particularly useful for has in recent years been applied to the problem of semantic capturing the refinement levels of the modeled artifacts and for data integration on Internet, but also in different engineering succinctly capturing constraints like disjointess or completeness among them. The paper also reports certain aspects of the studied domains, primarily through OSLC standards [25]. case that could not be expressed using MLT. The studied case As in any data integration scenario, the integrated data must comes from a real data-integration project from the heavy vehicle conform to an information model that in the case of LD manufacturer, Scania CV AB. can be created using RDFS or OWL languages [24]. There Index Terms—multi-level modeling, information modeling, are two main aspects of these languages that make their use product line engineering, linked data in an enterprise context difficult. Firstly, both languages are I. I NTRODUCTION based on the Open-World Assumption (OWA) [6] which may lead to inconclusive results of data analysis. Secondly, in data Development and evolution of safety-critical Software- integration scenarios, some entities are simultaneously both Intensive Systems (SIS) is a process involving various engi- classes and objects [18] and this is not expressible in OWL neering disciplines that produce engineering artifacts across while RDFS can express this fact but without any constraints the complete SIS lifecycle, e.g. software, hardware, various that prevent creation of inconsistent or contradictory informa- models, and documents. Performing different analyses across tion models. As an alternative to RDFS and OWL, but also the lifecyle is essential for sucesfull SIS development and to traditional MOF-compliant modeling frameworks that face deployment, e.g. is versioning or tracing data consistent, or the same issue with entities being both classes and instance, more importantly, does SIS conform to prescribed safety or work in [17] has investigated the applicability of the Multi- reliability standards. Automating such analyses is often a Level Modeling (MLM) paradigm [2], [15] for information daunting task [21] because individual artifacts are isolated in modeling in the PLE context. More specifically, the Multi- individual tools that use own principles and technologies for Level conceptual Theory (MLT) [8] was used to interpret PLE- artifact management. specific concepts inside MLT framework in order to support Development of highly configurable SIS, also known as modeling of different artifacts and their configuration data with Product Line Engineering (PLE) [19], brings additional dif- an emphasis on semantically rich and correct models. This work was funded by the ITEA 14014 ASSUME project with the The present paper reports on the experiences from applying support from Scania CV AB. the framework presented in [17] on the case of information- model creation for LD-based data integration in the real are known as presence conditions [20] and they are exempli- industrial PLE context from the heavy vehicle manufacturer, fied in the middle part of Figure 1. The presence conditions Scania CV AB. This report contributes to the field of MLM in are arbitrarily complex propositional formulas over the set of two ways: firstly, the considered case comes from a real, large- features in the variability model. Individual products can be scale data-integration project for safety-critical SIS develop- derived in the so-called application phase of PLE by using the ment, thus contributing to the limited knowledge about MLM product configurator, that based on the selection of features, paradigm applicability in the industrial setting; secondly, the composes appropriate artifacts into individual products. information model is intended for data integration in a PLE In Scania CV AB, there are several tens of different types context based on LD principles which a is novel application of artifacts and they are maintained either manually, in hand- for MLM approaches. written documents, or in multiple in-house and third-party The rest of the paper is organized as follows. Section II tools. The number of features is around ten thousand while presents relevant PLE and LD concepts followed by a brief the number of presence conditions is in the order of millions description of the MLT framework. Section III presents the and they are maintained together with the artifacts in individual details of the created information model and Section III-B tools. presents its use in the data integration process. Section IV discuses the benefits and shortcomings of the applied modeling B. Linked Data framework and is followed by Section V that surveys related Linked Data refers to the set of principles for structuring and work. Finally, Section VI concludes the paper. publishing data on Internet. The principles can be summarized as: each real life entity, digital or physical, is identified by an II. BACKGROUND Uniform Resource Identifier (URI) and is called a resource; This section introduces the PLE and LD concepts followed the result of any operation over resources is always presented by a brief explanation of the MLT framework and PLE in Resource Description Framework [24] (RDF) format; re- concepts described in [17]. sources should have links, also URIs, to other resources. The A. Product Line Engineering main technologies used for publishing LD are the aforemen- tioned RDF data model, its data modeling extension RDFS Figure 1 exemplifies the overall idea of PLE. The main Schema [24], and accompanying ontology language called Web goal of PLE is to engineer artifacts that realize or describe Ontology Language [24] (OWL). Additional standardized LD a product in a way such that these artifacts can be reused technologies exist [24]. in several different product configurations. Capturing artifact Publishing LD is a process in which the data from existing reuse is achieved by representing different product config- sources is assigned with URIs so that each data fragment, urations in terms of configuration options, also known as can be serialized as RDF according to an LD schema [23]. features [19]. For example, an individual truck configuration An LD schema is an information model of the published could be described as having features: engine, brakes, cab etc. data that is usually expressed in RDFS or OWL language The features and their mutual dependencies are captured in which define constructs that can be used for LD information a variability model [19], in the case of features known as modeling. Unlike in traditional data integration where a high the feature diagram [3], that captures all possible product level modeling language describes the overall data integration configurations in terms of features. This phase of PLE is schema, in LD ”the data schema is represented with the known as domain engineering. Left part of Figure 1 shows a data itself” [23], i.e. RDFS and OWL are syntactically the fragment from a feature diagram. An example of a dependency same as the RDF data model. The RDFS language defines could be, if the feature strong engine is selected than the the concepts of a class, relation specialization, grouping of feature small brakes cannot be selected. resources into containers, and some frequently used string- valued attributes. Interestingly, although not stated explicitly, RDFS is underpinned by the concept of an unlimited num- ber of abstraction levels, similar to MLM approaches. The OWL language defines a richer vocabulary with concepts like class disjointness, relation cardinality, inverse relations and others, but it does not support MLM concepts and its RDF serialization is cumbersome. Furthermore, both RDFS and OWL assume the open-world assumption [6] (OWA), i.e. any Fig. 1. Basic idea behind the Product Line Engineering development paradigm information that is not stated is not false. This can lead to inconclusive analysis operations of the RDF data which is not Once the variability model is established, features can be desirable in an enterprise. mapped to one or more artifacts, i.e. to specific versions of There are several benefits from using LD in an enterprise: engineering artifacts. For example, if a product configuration use of robust, generic web-based principles for data exchange has a strong engine, then a particular engine control sofware and querying, the possibility to reuse already published LD, must be used. The mappings between the features and artifacts and incremental data integration because adding new entities to the information model does not falsify the previous one. The MLT framework differentiates between three primary The basic idea of LD-based data integration implemented in concepts. These are types that correspond to UML classes, Scania, is shown in Figure 2. individuals that correspond to UML objects, and attributes that correspond to UML associations. Types are semantically interpreted as sets and they are organized into an arbitrary number of abstraction levels where each level is represented by an order type. Each type declared in an MLT model is a specialization of an order type and an instance of the immediately higher order type or some type specializing the higher order type. In MLT, order types are called IndividualOT, representing types whose direct instances are individuals that cannot be instantiated further, FirstOT whose direct instances Fig. 2. Illustration of data integration in Scania CV AB based on LD are types specializing the IndividualOT, SecondOT whose principles direct instances are specializing the FirstOT and so on. MLT is a powertype-based MLM framework, i.e. unlike in deep Figure 2 illustrates that artifacts from existing tools are instantiation [15], the type-facet and the instance-facet of a published in RDF format and stored in a central database type is explicitly modeled on two adjacent abstraction levels. that can then be used for designing cross-tool artifact anal- Attributes are used to represent properties of types and yses. Grey interfaces represent adapters that implement LD instances of types. Semantically, attributes represent binary principles and publish artifacts data from existing tools in relations; either between a type and a data-type, e.g. string, RDF format. Currently, data integration in Scania is limited to or between two types declared in the model. This distinction three tools: software versioning tool, product data management is reflected in the visualization of the MLT models where in tool and the requirement specification tool. Once stored in the the former case, attributes are visualized similar to attributes central database, the data can be accessed through a purpose- in UML class diagrams while in the later case the attributes build LD-based application, i.e. LD tool 1. The evolution are visualized as associations between types. The attributes of the presented data integration approach is to also enable relating two types declared in the model are referred to as consuming LD by existing tools, like exemplified on the case relations and MLT separates them into basic and structural of Tool 4. relations. Structural relations are predefined and they relate Designing adapters requires an information model that two types whether any arbitrary basic relation relates instances structures the relevant types of data objects from existing tools of types and must be declared by the modeler. into a LD representation, potentially enriched by relations Work in [17], interprets and disambiguates basic relations and attributes that do not exist in source tools. Since the between different artifacts that are product-configuration spe- information model represent the interface between data models cific (PCS) and that inherently occur in the application phase in existing tools and RDF data model, the information model of PLE. Each PCS relation is the consequence of previously must treat two issues. Firstly, in all considered cases, the mentioned presence conditions that specify sets of product existing tools were not OWA-based while RDF is. Conse- configurations in which a particular artifact can be used. quently, all the constraints that implicitly exist in non-OWA Furthermore, the approach discusses the structuring of versions frameworks, e.g. object disjointness or completeness, must be and variants of different types of artifacts and their relations to explicitly captured and published in LD. Secondly, and more product configurations and corresponding presence conditions. importantly, data objects which are instances in one tool can The main result of the work is the transformation of presence be classes in another tool, also noted in [18], and the fact that conditions, that are usually just syntactical annotation, into certain data objects exhibit this dual nature must be captured. first-class citizens with well-defined semantics. This allows Since both RDFS and OWL languages do not provide publishing presence conditions as non-string RDF data that support for expressing the class-instance nature of certain can be analyzed using standard LD technologies. data objects, i.e. they are not based on MLM principles, and they assume OWA-based modeling, a different information III. I NFORMATION M ODELING U SING MLT modeling framework was needed in order to leverage the The model in Figure 3 captures the details about require- benefits of LD for enterprise data-integration. ments and Electronic Control Units (ECUs), i.e. embedded computers that control vehicle behavior. The complete model C. Multi Level Theory for Data Integration in PLE is significantly larger and it includes more artifact types but This section briefly introduces the Multi-Level conceptual the excerpt in Figure 3 captures all relevant model aspects. Theory (MLT) concepts togeter with interpretations of PLE Because the information model is used for LD- concepts that were introduced in [17]. Detailed explanations based data integration, the attributes of types and of relevant concepts are presented in the next section on the relations between types are reused from various LD example of the information model created using the MLT vocabularies. The notation prefix:name represents a framework. shorthand for vocabularyURI/name. For example, Fig. 3. MLT information model for LD-based data integration dcterms:description attribute is a shorthand for the tioned types in order to enrich the RDF data with traceability full URI http://purl.org/dc/terms/description links. where the attribute description is defined. The prefix scania Instances of type ProductGroup represent product con- indicates a vocabulary that contains Scania-specific definitions. figurations defined by different presence conditions for the pur- An underscored attribute is an attribute of the entity labeled pose of describing product configurations in which particular by it while a non-underscored attribute is an attribute of artifacts can be used. Unlike in Section II-A, where presence instances of the type that is labeled by it. Figure 3 omits the conditions were propositional formulas, in the information values of attributes common to all entities, i.e. rdfs:label, model presence conditions are represented by types defined dcterms:description, and dcterms:created. by these propositional formulas and these types are instances The rdf:type relation is the RDF equivalent of the in- of the type ProductGroup. For example, type EMS1 v1 stance of relation. It should be noted that all types specializing Product Group has instances that are individual product type FirstOT are instances of the type SecondOT but the configurations, each containing an individual part that is an rdf:type relations are omitted in order to reduce clutter. instance of typeEMS1 v1. In other words, each instance of the type EMS1 v1 Product Group can be represented by a A. Different Aspects of the Information Model set of features that entail the truthfulness of the presence condi- The information model in Figure 3 captures several different tion of the type EMS1 v1. The relation dcterms:hasPart types of information. The three types in the top part of Figure 3 between type ProductGroup and Version and Variant represent the MLT order types which structure the model into indicates that any type that is an instance of types Version abstraction levels. Because all entities in the model are either or Variant must be related to a particular product group direct or indirect, through specialization relations, instances that defines the artifacts inclusion into particular product of these three types, they model the common attributes of all configurations. In the complete model, even the instances of entities in the information model. Direct instances of the types the type ScaniaItem can be related to an instance of the on the IndividualOT abstraction level are the real world type ProductGroup and the relation between them can be individuals, e.g. :ems1 v1 and :truck. different, e.g. testedBy in the case of test cases. The information model in Figure 3 also contains some 2) Use of MLT-specific constructs: In Figure 3, types example RDF data that illustrates the relations between the specializing the order type IndivudalOT capture the infor- resources published by LD adapters and types in the MLT mation that each instance of the type Requirement specifies model. All entities with a dashed border are examples of RDF one or more instances of the type Truck and that each data. Two main aspects captured by the information model are instance of the type Truck has one or more parts which the PLE aspect that describes all artifacts and their properties are instances of type ECU. Furthermore, a particular type of from the PLE point of view and the use of MLT constructs requirement is a software requirement and therefore the type for structuring and capturing the constraints over the published SW Req specializes the type Requirement. RDF data. Type ECU is partitioned by the type ECUItem, following 1) The PLE Aspect: Types and relations in the left the so-called type-object pattern recognized in [15]. The part of the information model, i.e. ScaniaConcept, partitions relation, based on the powertype relation, implies ScaniaItem, Variant, Version, and ProductGroup, that all specializations of the type ECU are pairwise dis- classify all the artifacts from individual tools into these five joint and are the only instances of the type ECUItem. For types and also prescribe the mandatory structural and basic example, Scania currently has around 80 different ECUs relations between them. Instances of type ScaniaConcept that are instances of type ECUItem. Type ECUItem spe- represent abstract, stable concepts in the domain whose def- cializes the type ScaniaItem whose meaning was pre- initions change very rarely. Instances of type ScaniaItem viously described. Unlike the type ECU, type SW Req is represent different logical realizations of concepts. Instances disjointly categorized by the type SW Guarantee. The of type Variant represent refinements of instances of disjointCategorization relation implies that all in- type ScaniaItem according to different criteria, e.g. arti- stances of the type SW Guarantee are pairwise disjoint fact generation, new product variant etc. Instances of type specializations of the the type SW Req but not the only ones. ScaniaVersion represent particular engineering artifacts For example, in contract-based requirements specification, that can be used to construct or describe a particular product there are additional requirement types such as SW Assumption configuration. The only structural relation between these types whose instances also specialize the type SW Req. is the isSubordinateTo relation which implies that in- Type ECUItem has an attribute called stances of types related by it must be in the specialization rela- scania:componentCode that is an MLT regularity tion, i.e. when serialized into RDF, specialization corresponds attribute, denoted by placing the attribute in to the rdfs:subClassOf relation. Structuring instances of parenthesis preceded by the letter R. The attribute these four types into specialization hierarchies reflects the pro- scania:componentCode represents a sticker placed on cess of incremental refinement during the engineering of these physical ECUs and it is used to differentiate between instances artifacts. Moreover, relations dcterms:isVersionOf and of the type ECUItem in order to connect proper cabling scania:isVariantOf are prescribed between the men- on the assembly line. According to the MLT framework, a regularity attribute is an attribute such that each attribute value is unique to the instance that assigns it the particular value. In Figure 3, the attribute scania:componentCode is assigned with a value S8 by the type EMS which is the Engine Management System and also an ECU. Any other value of the scania:componentCode attribute must belong to a different specialization of type ECU. As mentioned, the aim of the work in [17] was to interpret PLE concepts within the MLT framework in order to enable capturing complex and semantically well-defined information models in PLE. Given the previously described PLE concepts in the information model, all other types on the FirstOT ab- straction level whose instances will be published as RDF data specialize the introduced PLE concepts and leverage the MLT structural relations in order to define the semantics and capture the constraints over RDF data. Each instance of the type ScaniaConcept is at the top of a specialization hierarchy that captures levels of refinement, in other words levels of vari- ation, of artifacts in the application phase of PLE. The special- ization hierarchies are enforced trough isSubordinateTo relations. For example, type EMS specializes the type ECU. Similarly, type EMS1 specializes type EMS and type EMS1 v1 specializes type EMS1. Furthermore, all types in the Fig. 4. LD adapter construction based on the MLT information model specialization hierarchies are disjoint, and in some cases complete, which is captured through the partitions and disjointCategorization relations. MLM capabilities adapters using traditional programming languages with two- of the MLT framework are essential for expressing different level concepts was possible. Each adapter was responsible for types of information on different abstraction levels. a set of types and their instances, while the types not owned Regarding basic relations, there are only a few between by any existing tool were published by an additional ”virtual” types in Figure 3. Besides the dcterms:hasPart basic adapter. The ”virtual” adapter also created the links between relation which is reused from the Dublin Core Meta Data RDF data created by tool adapters on the RDF level in order to vocabulary, other basic relations like scania:specifies create the MLM model that conforms to the MLT information and scania:isVariantOf are defined for the need of this model. The number of types published by the adapters is particular model. in the order of magnitude of tens of thousands while the number of individuals is far greater. It should be noted that B. Using the Information Model these numbers were reached after several increments of the information model and that initial numbers were much smaller. This section illustrated the usage of the MLT information However, incremental data integration is one of the strengths model for data integration according to LD principles. To that of LD and the incremental approach was beneficial for gradual end, Figure 4 omits most of the details from the model shown adoption and structuring of the domain knowledge. Figure 3 and only shows the model structure. As mentioned earlier, the first version of LD-based data As previously discussed, the types in the information model integration and tool adapters is in place for three tools. represent different engineering artifacts across the product As of now, the primary usage of the integrated data is lifecycle. According to Section II-B and Figure 2, in order for different stakeholders to visualize, navigate, and explore to transform the artifact data into RDF data, it is necessary to relations between different types of artifacts using an in-house implement adapters that will transform the artifact data from developed tool called Search & Browse. Part of the future work the internal tool formats into RDF format. is to define and implement standardized analysis operations In Figure 4, black boxes indicate that a particular tool over the data that target different use cases like consistency maintains instances of the indicated classes. The entities with checking or change impact analysis. Also, in order to automate a dashed border, either types or individuals, are instances of adapter development and data validation, future versions of the types owned by a tool and they are published as RDF data the information model shall be created using a model-driven by tool adapters. The need for an MLM based approach is approach based on the Lyo Toolchain tool [10]. illustrated by types owned by Tool 1 which are instances of types owned by Tool 2. Because MLT forces strict stratification IV. D ISCUSSION of modeled entities into abstraction levels with instantiation, The case introduced in the present paper indicates that i.e. rdf:type, relation between them, the implementation of creating information models for data integration requires the use of an MLM framework because instances from one tool V. R ELATED W ORK can be types in another tool. The particular MLM framework Reports about applications of Multi-Level Modeling ap- that was used in the present paper, the MLT framework, offers proaches on real cases are still rare, particularly in areas other many benefits but there are also some shortcomings. than model-based software development including software architectures and domain-specific languages. Most importantly, MLT defines the partitions, disjoint cat- In [11], standardized IT management frameworks for enter- egorization, and subordination relations which were essential prise infrastructure modeling, evolution and decision making for capturing the item-variant-version pattern. Furthermore, are surveyed and common chanllenges and prospects for regularity attributes are a succinct way to express the con- improvement are identified. Following the survey, multi-level straint that different attribute values lead to the creation of new modeling approach was used to construct a language that types. The fact that MLT is a powertype-based MLM frame- tackles identified challenges. The report in [22] also looks at work means that for each partitions relation, there is an enterprise architecture modeling using a modeling language additional type defined [15] compared to deep instantiation developed during industrial projects. The language Txture uses approaches. However, because each type in the information both multi-level modeling concepts and traditional two-level model represents a data fragment, it is desirable to explicitly modeling concepts and the authors claim that a language with define all of them. Moreover, the separation into two types, enough expressiveness for capturing complex domains must provides a type where instance-facet attributes can be declared support concepts both paradigms. and a type where type-facet attributes can be declared which Work in [1] tackles the problem of mapping domain specific was helpful in explaining the MLM concepts to employees in concepts to concepts from automotive safety standards by Scania. introducing a mapping layer which leads to a multi-level Regarding the practical aspects of using the MLT frame- model. In the absence of an adequate MLM framework for the work, the absence of tool support was the biggest challenge. presented problem, the paper introduces the DeepML language Although a MLT-UML profile was suggested in [7], it was not that combines constructs from several MLM frameworks. The implemented and MLT models had to be created and debugged approach in [14] is motivated by the problem of interop- manually. A part of the future work with the Lyo toolchain is erability between information systems, a similar problem to about extending its graphical modeling tool based on results the one discussed in the present paper. The authors propose from [17]. additional disambiguation of instantiation and specialization relations in order to facilitate tool interoperability but they do As a purely powertype MLM approach, MLT does not not apply their approach to a realistic case study. However, the support expressing some information. There are two exam- introduced extensions are formally captured and then evaluated ples where deep instantiation and dual-deep instantiation against a set of criteria such as modularity, level stratification are needed. First example concerns the componentCode and etc. regularity attribute. As mentioned earlier, componentCode VI. C ONCLUSIONS is a sticker on physical individuals which are instances of version artifacts, e.g. EMS1 v1, and therefore it should be Constant increase of product complexity in PLE devel- considered as the attribute of individuals. However, because opment of SIS requires seamless access to well-structured types like EMS1 v1 are added by the adapters, i.e. they are artifacts data with the purpose of making decisions or ensuring not present in the information model, the componentCode different properties of developed SIS. One way to enable such attribute must be modeled as an attribute of instances of the operations is data integration of existing artifacts data into a ECUItem type on the FirstOT level. If MLT framework unified representation. This paper has reported on the expe- had supported deep instantiation, the componentCode attribute riences from applying an MLM framework, specifically the could be modeled as an attribute of type ECUItem with MLT framework, for the creation of an information model for potency=2 and then all specializations of the type EMS would LD-based data integration used in a real industrial case from inherit that attribute thus yielding the desired result. the heavy vehicle manufacturer, Scania CV. MLM capabilities of MLT enabled capturing several aspects of the considered The second example concerns the use case for dual-deep data while the relations partitioning, disjoint categorization instantiation. For example, individual ems1 v1 could have and subordination have enabled expressing constraints and an attribute scania:assembledBy whose value is of type structuring published LD with well-defined semantics. Being a ScaniaEmployee. Simultaneously, any type on any abstrac- powertype-based MLM approach, MLT forces clear separation tion level has an attribute dcterms:created whose value of modeled entities into abstraction levels which has facil- should also be of type ScaniaEmployee. In this scenario, itated adapter implementation using traditional programming two different attributes on two different abstraction levels are languages. Although MLT provides formal definitions of all of related to the same type which is basic idea of dual-deep its constructs, the lack of tool support prevented using them instantiation. Currently, the information model does not treat in an automated fashion. As an integration technology, LD this issue in any way because the type ScaniaEmployee is has proven useful primarily in two aspects. Firstly, the ability not modeled. to reuse definitions of attributes like creator, description, or hasPart relation were a significant time-saver. Secondly, the possibility to incrementally integrate data allowed gradual adoption and structuring of domain knowledge. Future work is targeted towards providing tool support for model-driven LD adapter generation based on information models created using MLT framework. R EFERENCES [1] Al-Hilank, S., Jung, M., Kips, D., Husemann, D., Philippsen, M.: Using multi level-modeling techniques for managing mapping information. In: MULTI@MoDELS (2014) [2] Atkinson, C., Kühne, T.: Reducing accidental complexity in domain models. Software & Systems Modeling (2008) [3] Batory, D.: Feature models, grammars, and propositional formulas. In: SPLC ’05 (2005) [4] Berger, T., Rublack, R., Nair, D., Atlee, J.M., Becker, M., Czarnecki, K., Wasowski, A.: A survey of variability modeling in industrial practice. In: VaMoS ’13 (2013) [5] Bizer, C., Heat, T., Berners-Lee, T.: Linked Data: The Story so Far. IGI Global (2011) [6] Brachman, R., Levesque, H.: Knowledge Representation and Reasoning. Morgan Kaufmann Publishers Inc. (2004) [7] Carvalho, V.A., Almeida, J.P.A., Guizzardi, G.: Using a well-founded multi-level theory to support the analysis and representation of the powertype pattern in conceptual modeling. In: CAISE ’16 (2016) [8] Carvalho, V.A., Almeida, J.P.A.: Toward a well-founded theory for multi-level conceptual modeling. Software & Systems Modeling (2016) [9] Doan, A., Halevy, A., Ives, Z.: Principles of Data Integration. Morgan Kaufmann Publishers Inc., San Francisco, CA, USA, 1st edn. (2012) [10] El-Khoury, J., Gurdur, D., Nyberg, M.: A model-driven engineering approach to software tool interoperability based on linked data (2016) [11] Frank, U.: Designing models and systems to support IT management: A case for multilevel modeling. In: MULTI@MoDELS (2016) [12] Halevy, A., Rajaraman, A., Ordille, J.: Data integration: The teenage years. VLDB ’06 (2006) [13] Halpin, T., Morgan, T.: Information Modeling and Relational Databases. Morgan Kaufmann Publishers Inc. (2008) [14] Jordan, A., Mayer, W., Stumptner, M.: Multilevel modelling for inter- operability. In: MULTI@MoDELS (2014) [15] Lara, J.D., Guerra, E., Cuadrado, J.S.: When and how to use multilevel modelling. ACM Transactions on Software Engineering Methodology (2014) [16] Nešić, D., Nyberg, M.: Multi-view modeling and automated analysis of product line variability in systems engineering. In: SPLC ’16 (2016) [17] Nešić, D., Nyberg, M.: Modeling product-line legacy assets using multi- level theory. In: REVE@SPLC ’17. To appear. (2017) [18] Neumayr, B., Jeusfeld, M.A., Schrefl, M., Schütz, C.: Dual Deep Instantiation and Its ConceptBase Implementation (2014) [19] Pohl, K., Böckle, G., van der Linden, F.J.: Software Product Line Engineering. Foundations, Principles, and Techniques. Springer-Verlag Berlin Heidelberg (2005) [20] v. Rhein, A., Grebhahn, A., Apel, S., Siegmund, N., Beyer, D., Berger, T.: Presence-condition simplification in highly configurable systems. ICSE ’37 (2015) [21] Sudarsan, R., Fenves, S., Sriram, R., Wang, F.: A product information modeling framework for product lifecycle management. Computer- Aided Design (2005) [22] Trojer, T., Farwick, M., Haeusler, M.: Modeling techniques for en- terprise architecture documentation: experiences from practice. In: MULTI@MoDELS (2014) [23] W3C Consortium: Best practices for publishing linked data (2017), https://www.w3.org/TR/ld-bp [24] W3C Consortium: Semantic web (2017), https://www.w3.org/standards/semanticweb [25] OASIS consortium: Open services for lifecycle colaboration (2017), http://open-services.net