A Linked Data Extraction Architecture for Engineering Software Tools

Semantic Web 0 (0) 1 1 IOS Press

A Linked Data extraction architecture for engineering software tools

Jad El-khoury a,∗, Andrii Berezovskyi a, Mattias Nyberg b a Department of Machine Design KTH Royal Institute of Technology Stockholm, Sweden b Scania CV AB Södertälje, Sweden

Abstract. New industrial initiatives such as Industrie 4.0 rely on digital end-to-end engineering across the entire product lifecycle, which in turn depends on the ability of the supporting software tools to interoperate. A tool interoperability approach based on Linked Data has the potential to provide such integration, where each software tool can expose its information and services to other tools using the web as a common technology base. In this paper, we report on our negative findings when attempting to use existing Linked Data extraction techniques to expose the structured content managed in engineering tools. Such techniques typically target the storage facility to extract and transform its content, with the assumption that sufficient information is available within the facility to automate the process. Based on a case study with the truck manufacturer Scania CV AB, our study finds that an engineering tool manages its artefacts using business logic that is not necessarily reflected in the storage facility. This renders existing extraction techniques inadequate. Instead we propose an alternative Linked Data extraction architecture that can mitigate the identified shortcomings. While less automated compared to the existing solutions, the proposed architecture is realised as a standalone library that can still facilitate the extraction process.

Keywords: Linked Data, OSLC, Tool Integration, Tool Interoperability, SQL to RDF, Resource Shapes, Relational Databases to Linked Data Transformation

1. Introduction ity to provide “digital end-to-end engineering across the entire value chain of both the product and the asso- Advances in information and communication tech- ciated manufacturing system”. That is, it is necessary nology (ICT), and in particular internet technologies, to provide digital integration throughout the product such as the Internet of Things (IoT) and cloud comput- development and manufacturing processes, as well as ing are enabling factors for new industrial initiatives across the different technical disciplines and organisa- such as Industrie 4.0 [1] and the Industrial Internet [2]. tions involved. In the interconnected manufacturing environment of Given that engineering processes are supported the near future, machinery, storage and production fa- through a number of software tools, this need par- cilities will be able to intelligently and autonomously tially translates to the necessity to integrate these sup- exchange information and trigger actions among each port tools, as well as the product information resid- other. This can lead to more dynamic manufacturing ing within each tool. However, such support tools are and optimised decision-making processes, which will not necessarily designed to work together, since they allow for individual customer requirements to be met, are developed to focus primarily on a specific activity, while maintaining efficiency and productivity. development phase, or discipline within the complete According to the Recommendations for Implement- product life cycle. In general, software tools will most ing the Strategic Initiative INDUSTRIE 4.0 [1, p. 30], likely adopt different interface technologies (if any), one of the important features of this strategy is the abil- making their interoperability difficult. How can digital integration be achieved across soft- *Corresponding author. Email address: [email protected] ware tools that may or may not be designed to work

1570-0844/0-1900/$35.00 c 0 – IOS Press and the authors. All rights reserved 2 / together? A tool interoperability approach based on requirements on a suitable solution, which will be dis- Linked Data could well provide such a solution. With cussed in Section 5. Our proposed extraction architec- Linked Data, each tool can expose its information and ture is then presented in Section 6, with further imple- services using the ubiquitous web as a common tech- mentation and evaluation detailed in Sections 7 and 8 nology base, through which other tools can interoper- respectively. Reflections and analysis of other related ate. solutions are discussed in Section 9. The article is then The very first step to achieve such integration is for concluded in Section 10. each tool to extract and transform its internally managed artefacts into RDF resources. In this paper, we investigate the suitability of existing information extrac- 2. Background tion technologies from the Linked Data domain, when applied in the context of software tools typically used The recommendations for implementing the Indus- in an industrial setting. We here focus on the extraction trie 4.0 strategy identify model-based development of structured engineering information that resides in a (MBD) as the enabling methodology to cover the relational database. Yet, the experiences gained are in- needed digital end-to-end engineering. This makes tended to apply for other data management technolo- sense since MBD is leading the effort of migrating gies. engineering focus from text-based documentation to We report negative findings based on our investi- a digital representation of product data. Besides a gations. We conclude that existing Linked Data ex- model’s ability to facilitate communication between traction technologies are not appropriate to expose in- individuals and teams, the structured information con- formation from engineering tools of the complexity veyed in a model – when made electronically accessi- we studied. As will be detailed in this paper, two ble – can now be processed by IT systems to facilitate fundamental shortcomings are identified in our study. the information flow across processes, disciplines and First, current solutions tend to provide read-only ac- organisations. cess to the extracted information. This is not sufficient, However, the complete adoption of MBD in an in- since end-to-end engineering integration requires read- dustrial context remains somewhat limited. Consider- write access between the tools. Second, extraction so- ing the variety of modelling technologies available, lutions target data storage facilities such as relational considerable effort needs to be invested in integrating databases. However, in software tools, considerable modelling tools that do not necessarily share common logic resides in the application software itself which is technologies (such as a modelling framework, storage not taken into consideration when analysing the tool’s technologies, etc.) As a result, MBD and its benefits storage solely. are typically constrained to a subset of the develop- Nevertheless, the conducted experiments were in- ment life cycle [3]. strumental for us to better understand and define the Besides MBD tools, an equally relevant set of soft- data extraction needs of the industry domain. As a sec- ware tools are those supporting engineering activities, ond contribution of this paper, we here also propose an based on structured digital information. Typical tools alternative Linked Data extraction architecture that can such as issue tracking, computer-aided design (CAD), mitigate the identified shortcomings. While less auto- code analysis, ALM and PLM systems, all rely on in- mated compared to the existing solutions, the proposed formation being stored in some digitally manageable architecture is realised as a stand-alone library that can format such as a relational database, or versioned XML still facilitate the extraction process. files. If well integrated, such tools - together with MBD In the next section, we give further background in- tools - can together contribute to the Industrie 4.0 strat- formation on the tool interoperability problem, and egy of digital end-to-end engineering. how Linked Data can be a promising solution to this One alternative to provide digital integration across problem. In Section 3, we present a case study from the software tools is to impose the same technological truck manufacturer Scania CV AB that illustrates the space on tools throughout the life cycle, leading to the data extraction needs of the industry. The case study is adoption of a more centralised platform (such as PTC also used to evaluate the chosen extraction technique. Integrity [4] or MSR-Backbone [5]). While this may be Section 4 reports on our evaluation experiments based feasible at a smaller scale, such centralised platforms on the D2RQ platform. An analysis of the negative re- cannot scale to handle the complete heterogeneous set sults obtained, lead to the definition of the necessary of software tools normally found in a large organisa- / 3 tion. Centralised platforms may also be less flexible 3. Case Study for changes over time when additional tools need to be introduced. 3.1. Architecture Design - Activities, Artefacts and Instead, a more sustainable integration approach Support Tools would acknowledge the existence of distributed, het- During the architectural design of an embedded sys- erogeneous and independent data sources within the tem, one of the architect’s main responsibilities is to environment. A Linked Data approach to tool interop- capture the product’s desired functionalities as a set erability would promote a distributed architecture, in of system requirements. The requirements need then which each tool autonomously manages its own prod- to be structured so that end-user features can be allo- uct data while providing RESTful services through cated to the available software and hardware, in order which other tools can interoperate. This leads to low to achieve desired system characteristics such as per- coupling between tools, by reducing the need for one formance, reliability and safety. Such work entails the tool to understand the deep data of another. Moreover definition and management of artefacts such as functions, software components, communication channels, - like the web - Linked Data is a technology-agnostic processing units, sensors, actuators, etc. way of sharing information between different sources, To support the architect’s activities at the truck man- which are developed using different technologies, and ufacturer Scania, SESAMMTOOL is a proprietary soft- with their data being managed internally using any ware tool that is used to capture the above-mentioned suitable storage mechanism. artefacts, and structure them across three dimensions: Such an approach to tool interoperability is mani- 1. Functional Structure – Structuring the system re- fested in the OASIS OSLC [6] interoperability stan- quirements into end-user features - called User dard that targets the integration of heterogeneous soft- Functions (UF). A UF can also be seen as a col- ware tools, with a focus on the linking of data from lection of requirements. independent sources. It builds upon the Linked Data 2. Physical Structure – Defining the computer hard- principles, and its accompanying standards, by defin- ware elements such as processing units, physical ing common mechanisms and patterns to access, ma- communication channels, sensors and actuators. nipulate and query resources managed by the different 3. Logic Structure – defining the basic building tools in the toolchain. In particular, OASIS OSLC is blocks of the system software, namely Alloca- tion Elements (AE) and Function Variables (FV). based on the W3C Linked Data Platform (LDP) [7] and The AE and FV elements are the atomic software follows the Representational State Transfer (REST) ar- components that can be allocated to processing chitectural pattern. units and physical communication channels. A For a tool to provide a Linked Data interface, it is UF is broken down into AE and FV elements. necessary to transform its internal product data to RDF These three dimensions make up the system state. representations. Such mapping needs to deal with po- SESAMMTOOL also maintains a fourth - time - di- tential differences between the internal and external mension that keeps track of the change history of ev- data structures, since the vocabulary of the resources ery artefact. This time dimension is not to be con- being exposed is not necessarily the same as the in- fused with that of a traditional version control system. ternal schema used to manage the data. In addition, Instead, the time dimension reflects the state of the the mapping needs to deal with the differences in the product at different releases, giving the architect ex- technologies used by the tool and that of Linked Data. act knowledge over what versions of each artefact are Extraction technologies are available that can facilitate available for any specific product release. The information model in Fig. 1 represents the main artefacts this mapping process, assuming that the internal arte- managed by SESAMMTOOL and their relationships. facts are handled in a structured digital format such as a relation database. This paper analyses the suitability 3.2. Tool Integration with Linked Data of such extractions technologies - and the overall approach behind them - when applied in the context of The information available in SESAMMTOOL is cen- software tools, typically used in an industrial setting. tral to many other activities, beyond those of the ar- 4 /

Fig. 1. The SESAMMTOOL Information Model, showing the main artefacts at each of the three dimensions. chitect. Development activities such as requirements Request, to ensure that architectural changes are mo- management, verification and validation are centred tivated and approved by the appropriate stakeholders. around the artefacts defined in SESAMMTOOL, with To make any changes to an artefact in SESAMMTOOL, stakeholders (such as function owners, and test man- a Change Request needs to be first registered and ap- agers) being consumers of this information, even proved by a Release Coordinator. Change Requests are though they do not necessarily directly modify its managed externally in the Change Management tool – content. As a consequence, other software tools in JIRA. the environment need to integrate with the infor- An integration of the information between SESAMM- mation managed by SESAMMTOOL. For example, TOOL and other support tools is hence necessary. Such MSC-DRAWER is another graphical modelling tool, integration is to some extent already supported in which is used to define the expected sequence of the current development environment, mainly through communication messages that may be sent between an import/export of data across tools. For example, processing units, to satisfy the needs of a specific SESAMMTOOL regularly imports Change Requests User Function. The models defined in MSC-DRAWER then form a basis when constructing integration tests. from JIRA and maintains its own copy of the infor- MSC-DRAWER relies heavily on the artefacts from mation within its internal repository. Similarly, MSC- SESAMMTOOL. DRAWER accesses the SESAMMTOOL information Similarly, SESAMMTOOL is itself dependent on in- when a communication model is created. Both ad-hoc formation in other systems. For example, SESAMM- integrations are developed to satisfy particular needs, TOOL enforces a process whereby architecture activ- and are difficult to maintain, leading to discrepancies ities need to be associated with a particular Change between the tools. / 5

For a more systematic approach to data integration D2RQ is relatively convenient to use to obtain an across these tools, a Linked Data approach is found to initial standard mapping from the relation database to be potentially very suitable at Scania. Linked Data is an RDF graph, where (a) each table is mapped to a an attractive solution for an environment where many RDFS class that is based on the table’s name, and (b) in-house software tools are independently developed each column is mapped to a property based on the col- to support specific stakeholders. umn’s name. The default mapping can be customised As a first step in realising this Linked Data ap- for more advanced mapping rules such as joining prop- proach, SESAMMTOOL needs to expose its artefacts as erties from two different tables into a single RDF Linked Data resources. SESAMMTOOL stores its in- resource. D2RQ can be used to transform the SQL formation in a Microsoft SQL database. The database database into an RDF dump that can then be loaded schema contains just fewer than 100 tables in total. The into a triplestore. Alternatively, the SQL database can software makes extensive use of the Entity Framework be queried in real-time, using SPARQL. In this exper- [8] to perform an object-relational mapping (ORM) to iment, we choose the former alternative. software objects in the application software. After transforming the SESAMMTOOL database Given the rich vocabulary of SESAMMTOOL (as re- with D2RQ, it is soon realised that D2RQ provides flected in the number of tables in the database), the de- unidirectional mapping, where only a read-only RDF velopment effort for an equally rich Linked Data inter- representation of the database content is available. face can be costly. In this work, we investigate the ap- That is, changes to the RDF information are not re- plicability and maturity of using existing Linked Data flected back in the relational database. While read-only extraction technologies to support the development of access is a minimal requirement, it is not sufficient for the SESAMMTOOL interface. the desired integrated engineering environment, where a tool is expected to expose services to allow other tools to modify its managed artefacts. This is reflected 4. Experiments and Lessons Learnt in the interoperability scenarios acknowledged in the OSLC and LDP standards, which motivated the speci- This section presents the results of applying a con- fication of services such as creation factories and dele- ventional Linked Data extraction technology to sup- gated user interface dialogues for resource creation. port the development of the SESAMMTOOL interface. In addition, even after considerable customisation We choose to experiment with D2RQ [9], being a effort, the mapping remained not completely satisfac- mature platform for accessing relational databases as tory. SESAMMTOOL’s database schema is highly nor- RDF graphs. The study does not aim to specifically malised, based on Anchor Modelling [12]. The tech- evaluate the D2RQ platform, but instead views it as nique is adopted in order to efficiently handle the time a representative solution of the various SQL-to-RDF dimension, and capture the time intervals during which mapping solutions such as DB2OWL [10], FDR2 [11], any entity version is valid. Moreover, the technique al- etc. lows for the evolution of the information model over In the first experiment (Section 4.1), we attempt to time, without a substantial change in the database use the functionality of D2RQ as-is. Having discov- schema. As a result, information about a specific entity ered certain limitations, we complement D2RQ in the (such as a UF) is in practice distributed across many ta- second experiment (Section 4.2) with additional fea- bles. Figure 2 shows an extract of the database schema tures that try to mitigate the identified limitations. Each of relevance to the UF artefact. The UserFunctionAn- subsection below includes an analysis of the experi- chor is the central access table, yet it itself contains no ment results based on the presented case study. These properties on a UF artefact. Table UserFunctionHis- analyses then lead to the set of requirements as sum- tory handles all properties of a UserFunction that may marized in Section 5. change over time, while UserFunctionMeta handles its constant properties. Each of UserFunctionAnchor, 4.1. Experiment 1 - D2RQ Evaluation UserFunctionMeta and UserFunctionHistory tables in- herit from the tables AnchorBase, MetaBase and His- In this initial investigation, we use the D2RQ Plat- toryBase, which themselves hold properties that are form to expose the SESAMMTOOL content residing in common across all other artefacts (such FunctionCate- the relational database as an RDF graph that is ulti- gory or Use Case.) In total, information about a User- mately saved in a triplestore. Function is distributed across six tables. 6 /

Fig. 2. A subset of the SESAMMTOOL database schema, centred on the tables relevant for the UserFunction artefact.

So, it is theoretically possible to define D2RQ map- 4.2. Experiment 2 - Complement D2RQ with OSLC pings to join the necessary tables and produce a mean- RESTful services ingful RDF graph representing the UF entities. But, this essentially equates to the effort of designing the To remedy the identified limitations in the first ex- schema of the RDF graph, with little benefit gained periment, we decide to complement the D2RQ ap- from the D2RQ automatic mapping capabilities. More- proach with a mechanism that additionally supports over, a manual mapping would need to be maintained write-access to the tool data. This missing mechanism and updated over time, when the SESAMMTOOL in- is precisely that supported by the OASIS OSLC stan- formation model changes. Such a restriction is deemed dard, where the REST architectural pattern is used to unacceptable, since it contradicts the intention of the handle create, read, update, and delete (C.R.U.D.) re- Anchor Modelling, initially adopted to facilitate model quests on Linked Data resources. We here detail how changes over time. D2RQ can be complemented to also provide an OSLC- Alternatively, an extension of the D2RQ mapping compliant RESTful interface for its Linked Data re- generator could be developed to generate a more pre- sources. cise mapping. It would take the heuristics for the An- In the previous experiment, the D2RQ platform was chor Model into account to produce a mapping that used for two purposes: would require little manual modifications. Such an ap- 1. Vocabulary Mapping - To define the RDF vo- proach is feasible for SESAMMTOOL, but would no cabulary of SESAMMTOOL, based on an analy- longer be a general approach that can be reused for sis and mapping of the SQL database schema. other software tools. D2RQ’s “generate-mapping” tool produces a de- / 7

fault mapping file, which can then be manually Java classes to database tables. Through this mapping, adjusted. Hibernate can then deal with the read and write access 2. Data Exposure - To expose the structured SQL to the database entities. That is, the OSLC4J-annotated content as RDF data – according to the defined resource classes are now further augmented with Hi- mapping. This can be exposed either through bernate annotations. a one-off transformation into an RDF graph or In summary, an extension component of the OSLC through real-time translation of SPARQL queries code generator – SQL4OSLC – is developed to (1) au- to SQL. tomatically transform the D2RQ mapping file into an OSLC interface model, and (2) generate POJOs with The mapping was useful to a certain extent to au- both OSLC4J and Hibernate annotations to handle the tomate the definition of the SESAMMTOOL vocabular- end-to-end transition between REST client requests on ies. The data exposure mechanism needs to be replaced RDF resources and their corresponding SQL queries with an OSLC RESTful interface in order to provide on the destination database. Figure 3 illustrates this read-write access. process. 4.2.1. Implementation From the developer perspective, the process of de- We use and extend the existing OSLC interface code veloping an adaptor consists of: generator [13] that automatically generates an almost 1. SQL to RDF mapping generation - using the complete REST interface for RDF resources, based on D2RQ “generate-mapping” tool. a graphical specification of the vocabulary and its de- 2. Manual configuration of the default mapping file sired RESTful services. - Typical changes include removing tables that The current generator produces OSLC4J-annotated need not be exposed or renaming the RDF re- Java classes that model the RDF vocabularies as Plain sources. Old Java Objects (POJOs). At runtime, helper meth- 3. OSLC interface model generation - the SQL4OSLC ods use the OSLC4J annotations to create RDF graphs generator extension transforms the D2RQ map- from class instances. An RDF graph can then be fur- ping file into an OSLC adaptor specification ther serialised to JSON-LD or Turtle representations. model. In reverse, the helper methods can unmarshal RDF rep- 4. Manual configuration of services - Once the ini- resentations (normally received as REST requests us- tial model is defined, it is necessary to define ing RDF/XML or Turtle) to construct class instances the OSLC Services (such as query capabilities, of the expected vocabulary, which can then be further creation factories, and the RESTful operations) manipulated by the application software. that are needed for the relevant resources. Not all The generator also produces the JAX-RS classes resources would require such services, and the to handle resource REST services – as defined in identification of the necessary services would de- the model. Each JAX-RS class contains the necessary pend on the usage scenario of the interfaces. For methods to handle the C.R.U.D. methods to interact this reason, it remains a manual step to define with resources. the required services, through the graphical mod- The graphical model is typically defined manually. elling support already provided by the base Lyo In our case, given that the vocabulary is now available code generator. in a D2RQ mapping file, we transform the D2RQ map- 5. Automatic generation of OSLC interface - Once ping file to an equivalent OSLC adaptor specification the resources and their corresponding services model. From this model, the OSLC generator can fur- are configured, the OSLC adaptor is generated ther generate the corresponding adaptor interface code. through the SQL4OSLC code generator exten- With the current generator, it also remains the task sion. of a developer to manually implement the code that communicates with the source tool to access its inter- Upon generation, the adaptor is complete, read-to- nal data. In our case, given that the source data resides run, and does not need to be modified nor comple- in a relational database, we take advantage of ORM mented with much additional manual code. The devel- techniques – in particular Hibernate [14] – to automate oper can still manually insert additional java code and this access. We transform the mapping information in customise the default functionality where desired. The the mapping file to a set of classes with appropriate developer can safely add manual code in designated ar- Hibernate annotations that represent the mapping from eas of the code. The generator ensures that such man- 8 /

Tool SQL DB User Order name amount

Hibernate

Order orderedBy User OSLC amount name Interface Model

@Table(name="dbo.orders") @Table(name="dbo.users") OSLC REST @OslcName("http://example.com/ns/#order") @OslcName("http://example.com/ns/#user") Server class Order { class User { @Column(name="amount") @Column(name="name") @OslcName("amount") @OslcName("foaf:givenName") @OslcOccurs(Occurs.ExactlyOne) @OslcOccurs(Occurs.ZeroOrOne) @OslcReadOnly(false) @OslcReadOnly(false) Double getAmount() {…} String getName() {…} } @ManyToOne(fetch = FetchType.LAZY) @JoinColumn(name = "user_id") @OslcName("placedBy") @OslcOccurs(Occurs.ExactlyOne) @OslcRange({User.class}) @OslcReadOnly(false) User getUser() {…} } HTTP @prefix : . REST @prefix ex: .

:a rdf:type ex:User; ex:name “User A”. OSLC Client :b rdf:type ex:Order; ex:amount 1.00; ex:placedBy :a.

Fig. 3. The transition process from an SQL schema to RDF representations, through Hibernate and OSLC4J-annotated Java classes.

a number of database tables, so that meaningful re- Tool 1 GENERATE Schema !" SQL to RDF Mapping File sources can be exposed at the interface. #" OSLC Interface Model Moreover, now that we are capable of modifying 2 RECONFIGURE !" SQL to RDF Mapping OSLC the content of SESAMMTOOL, we realise that a client #" Interface Model Interface 3 GENERATE Model !" Complete OSLC Interface change request that results in changes in the database #" Placeholders for flexible 4 FEEDBACK adjustment - through Hibernate - bypasses a substantial amount !" Add custom code #" Safe regeneration without of the business logic, which would otherwise be han- losing added code RESTful OSLC Server dled by the SESAMMTOOL application. This issue is best illustrated through Fig. 5 that shows the typical Fig. 4. Development steps of the adaptor. three-layer architectural pattern of any large application, in which the end-user interface, application business logic, and data management functionality are sep- ual code remains intact after subsequent generations. arated into layers. The middle Controller layer controls This allows for the incremental development of the an application’s functionality, and performs the logi- adaptor model and its resulting code. This overall de- cal decisions before data from the Presentation layer velopment process is illustrated in figure Fig. 4. is made persistent in the Data layer. The Controller also controls and manipulates data in the Data layer 4.2.2. Analysis before it is passed further up to the Presentation layer. We apply this second solution to SESAMMTOOL, In both experiments with D2RQ, by directly accessing and the resulting interface was capable of supporting the Data layer to expose Linked Data resources, we are the expected C.R.U.D. services. This allows us to pro- bypassing any business logic necessary to control the ceed further with the case study, and lead to the dis- correct handling of the stored artefacts. covery of more substantial limitations with the overall The need for the business logic is more acutely ap- approach of both experiments. parent upon modification requests to the tool artefacts Not unexpectedly, considerable effort is still needed since it directly affects the internal state of the tool. For to configure the default mapping, in order to join example, a client request to modify a User Function / 9

Finally, with the solution of this second experiment, clients now lose the ability to perform advanced SPARQL queries at the interface. This was previ- ously available through the D2RQ platform, by sav- Presentation ing the RDF graph in a triplestore with a SPARQL endpoint. The resulting generated interface does provide an alternative, based on the OSLC Query Capabil- ity [15]. Relative to SPARQL, this is however deemed Controller to be insufficient since the language is less expres- sive. More importantly, one needs to implement specific OSLC query support for each interface, and cannot take advantage of off-the-shelf SPARQL engines that are readily available. Data From these early experiments, the overall conclu- sion is that conventional Linked Data extraction techniques, such as D2RQ, may work well for relational databases that capture relatively well the business ob- Fig. 5. Three-layered application architecture. jects of the application. Many engineenring software tools do not however fall in this category, making the should only be approved if its associated Change Re- application of D2RQ less valuable. In the next sec- quest is in an active state. Such a condition is clearly tion, we compile the set of requirements an end-to-end controlled when the user performs the change via the tool interoperability context places on extraction tech- Presentation layer. When directly accessing the Data niques for Linked Data. layer, the implemented Linked Data interface needs to perform the same control. This leads to additional development effort, as well as an increased risk for incon- 5. Requirements on Linked Data extraction of sistencies between the two resulting controller logic. structured content Business logic is also necessary when reading artefacts, yet such need is generally late to identify. When Our experiences with D2RQ and OSLC lead us to publishing read-only content, it is likely that the pub- identify and better formulate the necessary require- lisher is less concerned in case the data is misunder- ments on a suitable solution for the extraction of struc- stood or misused by a client. It is also likely that a tured content as Linked Data: client misinterprets the provided information, with no opportunities available to obtain feedback from the 1. Read-write RESTful access - It is necessary to publisher. Only when an external client tries to modify support client requests to modify (create, delete the publisher content that the need for business logic and update), as well as read tool artefacts through control arises. their exposed Linked Data resources. Accessing the data through the application con- 2. Access to business objects - The Linked Data re- troller ensures that the internal state of the applica- sources to be exposed ought to represent the busi- tion remains consistent, through any of the established ness objects handled and defined by the tool. This mechanisms used by the controller, such as transac- does not necessarily map to entities at the Data tion handling, authentications, logging, etc. Addition- Access layer, and will most likely be reflected at ally, access through the controller will ensure the cor- the Controller layer. rect handling of any external actions to other software 3. Access controlled by business logic - Client re- systems, which may be bypassed otherwise. For exam- quests to modify a business object need to be ple, The JIRA bug tracking tool allows external ser- controlled by the business logic of the applica- vices to subscribe to events via webhooks. Changes to tion - as defined in the Controller. Such control Jira via the controller will ensure the triggering of such can also be relevant for client read access. webhooks, and hence the correct interoperability with 4. Loose coupling to software tool - A sustainable other software tools. However, a direct change to its RDF interface shall not be dependent on internal database content will simply not be detected. components of the software tool, including the 10 /

database schema used to internally manage the Controller. This ensures that SPARQL query re- tool data. Such a dependency restricts the devel- sponses are consistent with the state of the busi- opment of the tool software itself. ness objects of the tool. 5. SPARQL query capabilities - In order to search – A Lyo Store library provides a simplified Triple- and explore resources, a query interface needs to store interface for the OSLC Server and handles be provided as a complement to the read-write the update requests from the Tool Controller. access interface to resources. The standardized With this architecture, RDF representations of busi- SPARQL query interface is to be preferred over ness objects are exposed to clients via one of three re- custom query interfaces, such as OSLC’s limited quest flows: query capability. 6. Interface development support - given the rich 1. Read operations (from OSLC client GET re- and domain-specific resources expected to be quests) are delegated to Lyo Store from the exposed from the different software tools, sup- OSLC Server. Lyo Store then retrieves the report with the development of tool interfaces is quested resources from the Triplestore. needed to reduce the cost of development. Sup- 2. Write operations (from OSLC client PUT, port can take the form of Software Development POST, DELETE requests) are directly delegated Kits (SDK), libraries, code generators, graphical to the Tool Controller via the OSLC Server. models, analysis tools, etc. Development support 3. Read-only SPARQL queries are directly exe- should take advantage of the fact that tools may cuted by the Triplestore. share similar technologies, and that the content The delegation of the read operations occurs with- of each tool is available in a structured digital out the involvement of the tool Controller. This im- form. proves the overall response performance of the adaptor, and reduces the load on the Controller, particu- larly in usage scenarios dominated by intensive read 6. Proposed Architecture requests from clients. Read operations are specifically handled by the Store Interface (Fig. 7). Store In- In response to the requirements identified in Sec- terface is part of the Lyo Store library and simplifies tion 5, an architecture evolved from the solution dis- storing and retrieving the OSLC resources from the cussed in Section 4.2 to provide a RESTful tool inter- triplestore. When write operations are performed, the face, which: Triplestore is not updated simultaneously upon such – Communicates with the tool via its Controller in- requests. Instead, the Triplestore will be eventually up- stead of directly accessing its Data layer. dated by the tool Controller - as detailed later in this – Offers clients read and write access through a subsection. This ensures that the business logic in the REST interface. tool Controller is not bypassed and that the triplestore – Offers clients a capability to perform SPARQL contents will not conflict with the internal state of the queries. tool. – Handles the specific business objects of any tool, The ability to maintain a synchronised set of RDF yet interacts with both the tool Controller and its resources representing the business objects of the tool external clients in a generic way. domain is essential to this architecture. The architecture supports two alternatives for updating the Triple- The tool Adaptor consists of three main components store (Fig. 7): (Fig. 6): – A push notification is sent to the Update Service – An OSLC Server handles RESTful C.R.U.D. re- by the Tool Controller, upon any change to its in- quests, as well as other OSLC-specific services ternal state. The Update Service then submits an (such as Delegated User Interface dialogues) update request to the Update Manager. from OSLC Clients. – A poll is periodically performed by the Update – An RDF Triplestore handles SPARQL queries Manager. from the OSLC Server and the Clients. The Triplestore maintains a synchronised set of RDF In both cases, the update process consists of the fol- representations of all business objects from the lowing steps ( See Fig. 7): / 11

Engineering Tool Tool Adaptor

Presentation

Tool OSLC WRITE Server User REST READ Controller POLL Lyo OSLCOSLC REST REST & & PUSH SPARQL clients Store SPARQL SPARQL clients QUERY

RDF Data Triplestore

Fig. 6. The overall Tool Adaptor architecture, showing how C.R.U.D. REST client operations are handled, while also providing advanced SPARQL query capabilities to clients.

Engineering Tool Tool Adaptor

REST WRITE OSLC Server

READ

Lyo Store POLL Change FETCH Provider Update Manager Controller PUSH Update MESSAGE Service CHANGES

Handlers Store Interface Java ! RDF

SPARQL QUERY & UPDATE SPARQL QUERY RDF Triplestore

Fig. 7. Details of the Lyo Store component, showing how the C.R.U.D. operations are handled, as well as the internal triplestore updates via push and pull mechanisms.

1. The Update Manager requests changes from to be stored as well as accompanying metadata Change Provider since the last update. (such as the timestamp, and whether the object 2. The Change Provider fetches the data from the is created, updated or deleted). Lyo Store de- tool Controller and provides a collection of ﬁnes the Change Provider as an interface that the changes.A change consists of a business object adaptor developer is expected to implement. This 12 /

standardises the way tool updates are fetched 8. Evaluation from an arbitrary Tool controller with a specific vocabulary. 8.1. Requirements Analysis 3. The Update Manager sends the changes to all registered Handlers. We here analyse the proposed architecture with re- 4. A Handler updates the resources in The triple- spect to the identified requirements of Section 5: store according to the changes. 1. Read-Write RESTful access - The proposed ar- Finally, Lyo Store interacts with the tool Controller chitecture is capable of providing RESTful read and OSLC Server based on instances of OSLC4J- and write access to resources. Similar to the annotated classes, which are expected to represent D2RQ solution, read access is offered via the the tool’s business objects. This allows the Adaptor RDF Triplestore, which will hold all the tool re- components to work generically with any tool Con- sources according to the defined vocabulary. The troller, while at the same time being able to han- architecture additionally supports write access. dle tool-specific domain objects. When interacting Unlike the second experiment, write access is with the RDF triplestore, Lyo Store eventually mar- no longer automated but is instead delegated to shals/unmarshals such instances into an RDF graph, the tool Controller. From a client perspective, the through the available OSLC4J helper methods (as read-write access is defined to comply with the shown in step 3 on Fig. 3). OSLC standard, which in turn builds upon the LDP recommendation. In this way, clients can interact with an engineering tool in a standardized fashion to other OSLC-compliant interfaces. 7. Reference Implementation 2. Access to business objects - In this architecture, the exposed resources are expected to reflect the The Lyo Store component of this architecture is im- business objects of the application. This assump- plemented as an open-source library, as part of the tion is guaranteed, given that the interactions be- Eclipse Lyo [16] project. It makes use of the Jena tween the tool Controller and the adaptor compo- Framework API [17] to interact with any RDF Triple- nents (OSLC Server and Lyo Store) are defined store that can provide a SPARQL endpoint over HTTP. in terms of such entities. Unlike D2RQ, defining Naturally, all components of this architecture need the business objects cannot be automated, and to share the common set of OSLC4J-annotated classes. will most likely need to be performed manually To facilitate this effort, the adaptor developer can take by the interface designer. advantage of the OSLC Lyo Modelling tool [18] in or- 3. Access controlled by business logic - This re- der to graphically model the business objects to be ex- quirement is satisfied by restricting read-write posed, as well as the services of the OSLC Server com- access to the engineering tool’s artefacts solely ponent. From such a model, the classes and services via the tool’s Controller. For read access, the can be generated [13]. business logic is applied when storing artefacts In summary, with the libraries and adaptor devel- in the Triplestore. The architecture cannot, how- opment support available through Lyo, the following ever, enforce this same business logic when steps need to be performed for a developer to produce clients make the actual read requests. a functioning tool interface: 4. Loose coupling to software tool - This requirement is satisfied by restricting the interaction – Graphically define the tool’s vocabulary to be ex- with the engineering tool to its controller. posed, and its OSLC services. 5. SPARQL Query Capabilities - This require- – Generate the OSLC Server, including OSLC4J- ment is satisfied through the RDF Triplestore annotated classes. query interface, whose content is ultimately up- – Implement the Change Provider interface to col- dated and controlled by the tool Controller. lect the set of changed business objects since the 6. Interface development support - The automa- last update. tion features of D2RQ to generate the tool vocab- – Implement either a push or poll mechanism to ulary, and provide access to RDF resources, are trigger the Triplestore update process. lost with the proposed architecture. As discov- / 13

ered in our experiments, such automation did not tools by whether an ontology is strictly prefedefined result in practically valuable results anyway. In- [24,25,26] or is a product of the mapping. stead, the proposed architecture can benefit from The tools that belong to the latter group can be fur- the Lyo modelling tool [18] that allows the inter- ther divided into three more categories: face designer to graphical define the interface vo- 1. Tools that generate an ontology with a ba- cabulary to match the expected business objects. sic mapping [27,28,29,11]. Basic mapping as- This is in turn complemented with the corre- sumes that the concepts of a database schema sponding code generator [softwareX] which pro- are mapped directly to an ontology (one-to-one duces the necessary classes to represent the busi- mapping betweeen tables and classes as well as ness objects. between entity attribites to properties). 2. Tools that can map the relational data on a 8.2. Implementation Evaluation domain-specific ontology that is not limited to a simple mapping of the concepts [27,30,31]. The The proposed architecture was successfully applied adjustment of the ontology from the simple map- in the development of three tool adaptors. The software ping to the one that reflects the domain is per- tools differed in their capabilities to interact with an formed with the active involvement of an expert. external adaptor, allowing us to validate and test vari- 3. Tools that apply a range of heuristics on the ous parts of the architecture: database schema, especially on the primary and – Bugzilla - An adaptor was developed to extract foreign keys, to generate an ontology that reflects Bugzilla bug reports as OSLC Change Request the domain [32,33]. resources [19]. Since it was not easily possible The authors conclude with an opinion that “purely to detect changes to artefacts within the Bugzilla manual tools, where mappings are given by the human tool, the poll mechanism was deployed by the Up- user, capture by definition the true meaning of the log- date Manager to update the Triplestore. ical schema, whereas purely automatic tools can rarely – JIRA - An adaptor was similarly developed for achieve such levels of successful interpretation”. This JIRA to expose OSLC Change Request resources. further confirms our experiences when trying to auto- In this case, JIRA webhooks could be used to mate the bidirectional mapping between Linked Data push changes via the Update Service. and relational artefacts. – ProR - Besides the standard handler to update Spanos et. al left the Linked Data based updates as the Triplestore, this adaptor included an addi- future work, highlighting that the early work in this tional handler extension to support the Tracked area has focused only on a basic mapping [34,35,36]. Resource Set protocol [20]. Besides the REST & Spanos et al. consider the problem of updating the re- SPARQL query access to clients, the TRS pro- lational database similar to the database view update tocol provides a third interaction point to clients problem [37,38,39] and therefore suggest simply port- that allows them to track additions, changes and ing solutions from that field to the linked data up- removals from all resources in the set. dates. As we have discussed before, even an advanced RDBMS update approach will not allow to satisfy the During these implementations, Lyo Store was also Access to business logic requirement. Read-write sup- validated using two different triplestores through the port for applications based on RDBMS is, however, same interface - the NoSQL database MarkLogic [21] very important, as argued in Applicability assessment and the Apache Jena Fuseki SPARQL server [22]. of Semantic Web technologies, because it allows to achieve broader tool integration [40]. Mapping languages underpin the tools exposing 9. Related Work linked data from relational sources. Hart et al. presented a comparison of various mapping languages and There are many tools implementing a range of tech- respective systems that are based on those languages niques for mapping relational databases into Linked [41]. The comparison was performed using a list of Data. A comprehensive survey of such tools is pre- 15 criteria evaluating the capabilities of the respective sented in [23]. In the paper, Spanos et al. present a systems. The last criterion assessed the presence of classification of the approaches, broadly grouping the bidirectional mapping, which supports updating rela- 14 / tional database through the linked data updates. It was and (c) read-write integration. The authors identified concluded that a basic mapping (in the paper referred D2RQ/Update as an initial solution for solving their to as a direct mapping) does not need support in the read-write integration challenge with RDBMS but did mapping language to be possible to implement. The not evaluate it [34]. survey also highlighed mapping languages used by Re- lational.OWL [24] and OntoAccess (R3M language) [36], which include support for bidirectional mapping 10. Summary constructs. However, support for the advanced mapping scenarios that these languages theoretically allow This paper studies the challenges of information ex- was not implemented in the respective tools. traction in an industrial setting, in which structured Several improvements have been made over the product data residing in conventional databases needs mapping systems mentioned above. In D2RQ++, Ra- to be exposed as Linked Data resources, in order to be manujam et al. added update functionality to D2RQ integrated across the organisation. system [35], which maps updated triples to SQL As the first main contribution, we report on our queries and stores the triples that cannot be written experiments in using existing information extraction back to the relational database in the native triplestore. techniques from the Linked Data domain, when ap- Work by Eisenberg et al. present the D2RQ/Update plied to an industrial context. From our experiences, that builds upon D2RQ++ [34]. It allows updates of we conclude that such techniques cannot be applied tables that have various constraints by using an al- on the software tools from which one needs to extract gorithm that performs a topological sort of triples product data. Besides not supporting write-access to to correctly group them into the corresponding SQL the exposed resources, existing approaches tend to fo- queries. In OntoAccess, Hert et at. presented R3M, an cus on extracting information directly from the data update-aware mapping language that allows specify- storage facilities, bypassing the important controller ing database constraints [36]. The 2014 survey of RDB logic of the software tool. to RDF translation approaches and tools by Michel et These negative results lead to a clearer understand- al. concludes that rich RDB-to-RDF mappings are of- ing of the data extraction needs. To satisfy these needs, ten one-way only, while tools with bi-directional map- we present - as the second contribution - a proposal ping support, such as OntoAccess, will have to “find for an alternative Linked Data extraction architecture a compromise between the expressiveness of RDB-to- that can mitigate the identified shortcomings. the pro- RDF mapping languages and the need for updating posed approach targets the controller layer of the soft- re-lational data using protocols of the semantic web” ware tool, allowing the interface to capture the seman- [42]. tics of the tool’s domain entities as opposed to the un- A new RML specification is being drafted to extend derlying schema of its database. While less automated the R2RML mapping to other data sources [43]. While compared to the existing techniques, the proposed ar- it allows for more uniform and reusable definitions, it chitecture is realised as a standalone library that can does not solve the problem of query rewriting that is still facilitate the extraction process. crucial for the bidirectional access. We were unable to find research around RML that has focused on applying it for tool integration scenarios in particular or any bi-directional Linked Data mapping in general. Within the industrial setting, multiple research projects have attempted to use Linked Data as the integration technilogy [44,45,46]. In these projects, the authors did not identify the need for updating source tool data via the Linked Data requests, probably because their efforts focused primarily on the integration of the tool datasets and not the underlying tools directly. Frischmuth et al. have explored the challenges that a large enterprise faces in Linked Data integration [47]. Among the biggest challenges it identified were: (a) performance and scalability issues, (b) tool support, / 15

References [18] Jad El-khoury, Didem Gürdür, and Mattias Nyberg. A model- driven engineering approach to software tool interoperability [1] Henning Kagermann, Wolfgang Wahlster, and Johannes Hel- based on linked data. International Journal On Advances in big. Recommendations for implementing the strategic ini- Software, 9(3 & 4):248–259, 2016. tiative industrie 4.0 – securing the future of german manu- [19] OSLC change management specification, version 3.0, facturing industry. Final report of the industrie 4.0 working . URL https://tools.oasis-open.org/ group, acatech – National Academy of Science and Engineer- version-control/browse/wsvn/oslc-ccm/ ing, 2013. URL http://forschungsunion.de/pdf/ trunk/specs/change-mgt/change-mgt.html. industrie_4_0_final_report.pdf. (Accessed on 04/28/2017). [2] Peter C Evans and Marco Annunziata. Industrial inter- [20] OSLC tracked resource set specification. net: Pushing the boundaries. General Electric Reports, https://tools.oasis-open.org/ 2012. URL https://www.ge.com/docs/chapters/ version-control/svn/oslc-core/trunk/ Industrial_Internet.pdf. specs/tracked-resource-set.html, . (Accessed [3] Jad El-Khoury, Cecilia Ekelin, and Christian Ekholm. Support- on 03/26/2017). ing the linked data approach to maintain coherence across rich [21] MarkLogic. http://www.marklogic.com/. (Accessed emf models. In European Conference on Modelling Founda- on 04/20/2017). tions and Applications, pages 36–47. Springer, 2016. [22] Apache Jena Fuseki. https://jena.apache.org/ [4] PTC Integrity. http://www.ptc.com/ documentation/fuseki2/index.html, . (Accessed application-lifecycle-management/ on 04/20/2017). integrity. (Accessed on 04/20/2017). [23] Dimitrios-Emmanuel Spanos, Periklis Stavrou, and Nikolas [5] Bernhard Weichel and Martin Herrmann. A back- Mitrou. Bringing relational databases into the semantic web: bone in automotive software development based on XML A survey. Semantic Web, 3(2):169–209, 2012. and ASAM/MSR. SAE technical paper, 03 2004. [24] Cristian Pérez de Laborda and Stefan Conrad. Relational. owl: doi:10.4271/2004-01-0295. a data and schema representation format based on owl. In [6] Open Services for Lifecycle Collaboration. http://www. Proceedings of the 2nd Asia-Pacific conference on Conceptual oasis-oslc.org/. (Accessed on 04/20/2017). modelling-Volume 43, pages 89–96. Australian Computer So- [7] Ashok Malhotra, Steve Speicher, and John Arwe. Linked data ciety, Inc., 2005. platform 1.0. W3C recommendation, W3C, February 2015. [25] Yuan An, Alex Borgida, and John Mylopoulos. Discovering http://www.w3.org/TR/2015/REC-ldp-20150226/. the Semantics of Relational Tables Through Mappings, pages [8] Atul Adya, José A. Blakeley, Sergey Melnik, and S. Muralid- 1–32. Springer Berlin Heidelberg, Berlin, Heidelberg, 2006. har. Anatomy of the ado.net entity framework. In Pro- ISBN 978-3-540-46330-6. . doi:10.1007/11890591_1. ceedings of the 2007 ACM SIGMOD International Confer- [26] Wei Hu and Yuzhong Qu. Discovering Simple Mappings Be- ence on Management of Data, SIGMOD ’07, pages 877–888, tween Relational Database Schemas and Ontologies, pages New York, NY, USA, 2007. ACM. ISBN 978-1-59593-686-8. 225–238. Springer Berlin Heidelberg, Berlin, Heidelberg, doi:10.1145/1247480.1247580. 2007. ISBN 978-3-540-76298-0. . doi:10.1007/978-3-540- [9] Christian Bizer and Andy Seaborne. D2rq-treating non-RDF 76298-0_17. databases as virtual RDF graphs. In Proceedings of the 3rd [27] Christian Bizer and Andy Seaborne. D2RQ – treating non- international semantic web conference (ISWC2004), volume RDF databases as virtual RDF graphs. In Proceedings of the 2004. Citeseer Hiroshima, 2004. 3rd international semantic web conference (ISWC2004), vol- [10] Raji Ghawi and Nadine Cullot. Database-to-ontology mapping ume 2004. Citeseer Hiroshima, 2004. generation for semantic interoperability. In VDBL’07 confer- [28] Cristian Pérez de Laborda and Stefan Conrad. Relational.owl ence, VLDB Endowment ACM, pages 1–8, 2007. - A data and schema representation format based on OWL. In [11] Makym Korotkiy and Jan L Top. From relational data to RDFS Conceptual Modelling 2005, Second Asia-Pacific Conference models. In International Conference on Web Engineering, on Conceptual Modelling (APCCM2005), Newcastle, NSW, pages 430–434. Springer, 2004. Australia, January/February 2005, pages 89–96, 2005. [12] Lars Rönnbäck, Olle Regardt, Maria Bergholtz, Paul Johannes- [29] Matt Fisher, Mike Dean, and Gregory Joiner. Use of OWL and son, and Petia Wohed. Anchor modeling – agile information SWRL for semantic relational database translation. In Pro- modeling in evolving data environments. Data & Knowledge ceedings of the Fourth OWLED Workshop on OWL: Experi- Engineering, 69(12):1229–1253, 2010. ences and Directions, Washington, DC, USA, 1-2 April 2008., [13] Jad El-khoury. Lyo code generator: A model-based code 2008. generator for the development of OSLC-compliant tool in- [30] Andy Seaborne, Damian Steer, and Stuart Williams. SQL- terfaces. SoftwareX, 5:190 – 194, 2016. ISSN 2352-7110. RDF. In W3C Workshop on RDF Access to Relational doi:10.1016/j.softx.2016.08.004. Databases, 2007. [14] Christian Bauer and Gavin King. Hibernate in action. 2005. [31] Kate Byrne. Having triplets-holding cultural data as rdf. In [15] OSLC Core version 3.0. Oasis committee specification, OA- Proceedings of the ECDL 2008 Workshop on Information Ac- SIS, April 2017. http://docs.oasis-open.org/oslc-core/oslc- cess to Cultural Heritage, 2008. core/v3.0/oslc-core-v3.0-part1-overview.html. [32] Nasser Alalwan, Hussein Zedan, and François Siewe. Generat- [16] Eclipse Lyo - enabling tool integration with OSLC. https: ing owl ontology for database integration. In Advances in Se- //www.eclipse.org/lyo/. (Accessed on 04/20/2017). mantic Processing, 2009. SEMAPRO’09. Third International [17] Apache Jena. https://jena.apache.org/index. Conference on, pages 22–31. IEEE, 2009. html, . (Accessed on 04/20/2017). 16 /

[33] Farid Cerbah. Mining the content of relational databases to [41] Matthias Hert, Gerald Reif, and Harald C Gall. A comparison learn ontologies with deeper taxonomies. In Proceedings of of rdb-to-RDF mapping languages. In Proceedings of the 7th the 2008 IEEE/WIC/ACM International Conference on Web In- International Conference on Semantic Systems, pages 25–32. telligence and Intelligent Agent Technology-Volume 01, pages ACM, 2011. 553–557. IEEE Computer Society, 2008. [42] Franck Michel, Johan Montagnat, and Catherine Faron- [34] Vadim Eisenberg and Yaron Kanza. D2rq/update: updating re- Zucker. A survey of RDB to RDF translation approaches lational data via virtual RDF. In Proceedings of the 21st In- and tools. Research report, I3S, May 2014. URL https: ternational Conference on World Wide Web, pages 497–498. //hal.archives-ouvertes.fr/hal-00903568. ACM, 2012. ISRN I3S/RR 2013-04-FR 24 pages. [35] Sunitha Ramanujam, Vaibhav Khadilkar, Latifur Khan, Steven [43] Anastasia Dimou, Miel Vander Sande, Pieter Colpaert, Ruben Seida, Murat Kantarcioglu, and Bhavani Thuraisingham. Bi- Verborgh, Erik Mannens, and Rik Van de Walle. RML: A directional translation of relational data into virtual RDF generic language for integrated RDF mappings of heteroge- stores. In Semantic Computing (ICSC), 2010 IEEE Fourth In- neous data. In Proceedings of the 7th Workshop on Linked Data ternational Conference on, pages 268–276. IEEE, 2010. on the Web, April 2014. [36] Matthias Hert, Gerald Reif, and Harald C. Gall. Updat- [44] Markus Graube, Johannes Pfeffer, Jens Ziegler, and Leon Ur- ing relational data via sparql/update. In Proceedings of the bas. Linked data as integrating technology for industrial data. 2010 EDBT/ICDT Workshops, EDBT ’10, pages 24:1–24:8, International Journal of Distributed Systems and Technologies New York, NY, USA, 2010. ACM. ISBN 978-1-60558-990-9. (IJDST), 3(3):40–52, 2012. . doi:10.4018/jdst.2012070104. doi:10.1145/1754239.1754266. [45] Jan Hladik, Conny Christl, Frank Haferkorn, and Markus [37] François Bancilhon and Nicolas Spyratos. Update semantics Graube. Improving industrial collaboration with linked data, of relational views. ACM Transactions on Database Systems owl. In OWLED, 2013. (TODS), 6(4):557–575, 1981. [46] Shusaku Egami, Takahiro Kawamura, Akihiro Fujii, and Ak- [38] Rom Langerak. View updates in relational databases with an ihiko Ohsuga. Building of industrial parts lod for edi-a case independent scheme. ACM Transactions on Database Systems study. In Joint International Semantic Technology Conference, (TODS), 15(1):40–66, 1990. pages 146–161. Springer, 2014. [39] Arthur Michael Keller. Updating relational databases through [47] Philipp Frischmuth, Jakub Klímek, Sören Auer, Sebastian views. PhD thesis, Citeseer, 1995. Tramp, Jörg Unbehauen, Kai Holzweissig, and Carl-Martin [40] Valentina Janev and Sanja Vraneš. Applicability assessment of Marquardt. Linked data in enterprise information integration. semantic web technologies. Information Processing & Man- Semantic Web, pages 1–17, 2012. agement, 47(4):507–517, 2011.