The W3C Linked Data Platform (LDP) speci cation de nes a standard HTTP-based protocol for read/write Linked Data and provides the basis for application integration using Linked Data. This paper presents an LDP adapter for the Bugzilla issue tracker and demonstrates how to use the LDP protocol to expose a traditional application as a read/write Linked Data application. This approach provides a exible LDP adoption strategy with minimal changes to existing applications.
integrating ALM tools by using the LDP protocol and this paper presents an LDP adapter developed to LDP-enable the Bugzilla3 issue tracker. 2
The three main alternatives for LDP-enabling an application are: (a) native support built into the application; (b) an application plugin; and (c) an LDP adapter. Providing native support requires modi cation to the application and not all applications allow extensions through plugins. As we have seen in the early stages of web services [4], adapters provide a more exible mechanism to gradually adopting a technology while using the existing tools with minimum changes, and we have leveraged this approach.
An application is de ned in terms of its data model and business logic. An LDP-enabled application exposes the data as Linked Data and allows to drive its business logic following the REST design principles. Thus to LDP-enable an application, its data model should be expressed in RDF by mapping it to a new ontology or by reusing existing vocabularies. In the Bugzilla adapter, the Bugzilla native data model is mapped to the ALM iStack ontology4. The adapter exposes the Bugzilla data as LDP resources by transforming the data between the ALM iStack ontology and the Bugzilla native model so that LDP clients can consume RDF data from Bugzilla as if it was a native LDP application.
The Bugzilla LDP adapter, which is a JavaEE web application, consists of three main layers: (a) LDP layer, (b) transformation layer, and (c) application gateway layer, as illustrated in Figure 1.
The LDP layer handles the LDP communications and exposes the Bugzilla data as LDP resources. This layer is built using the LDP4j framework5 which provides a middleware for the development of read/write Linked Data applications [5]. The concepts such as bugs, products, product versions, and users are mapped to LDP containers which list these entities and allow creating new entities. Each entity such as a bug, a product, or a user is mapped to an LDP resource with its own URI that can be used by clients to access them.
The transformation layer handles data validation and transformation. This includes extracting information from RDF data, validating them based on application restrictions, and mapping them to the Bugzilla model. The ALM iStack ontology is generic so that it can be used with other issue trackers (e.g., JIRA6, Redmine7); thus there is an impedance mismatch between the ontology and the Bugzilla native model which is managed by the adapter.
The application gateway layer handles the communication with the Bugzilla instance using its XML-RPC remote interface. Because the Bugzilla bug tracker is also accessed using its web UI, the adapter synchronizes with the 3 http://www.bugzilla.org/ 4 http://delicias.dia.fi.upm.es/ontologies/alm-istack.owl 5 http://www.ldp4j.org/ 6 https://www.atlassian.com/software/jira 7 http://www.redmine.org/
A Linked Data Platform Adapter for Bugzilla Bugzilla instance based on user-de ned policies. In addition there are several cross-cutting services such as con guration management, consistency, security, and synchronization which are utilized by multiple layers. This demonstration shows how LDP clients can use the adapter to access the Bugzilla bug tracker and to perform tasks such as discovering bugs reported against a product, modifying the status or the other properties of the bug, or creating new bugs (e.g., Fig. 2 shows a creation request and response).
For example, a continuous integration server in an integrated ALM setting
encounters a build failure. Thus, the \integration server agent " (
Once this request is received by the adapter, it extracts the necessary information, transforms it into the Bugzilla model using a mapping between the ontology and Bugzilla models, and creates a bug in the Bugzilla instance using its remote XML-RPC interface. Once created, the Bugzilla instance returns the identi er for the bug inside Bugzilla. Then, the adapter generates an URI for the bug and manages the mapping between the identi er given by the Bugzilla and the URI. Any information that does not t into the Bugzilla model such as links to external applications is maintained in the adapter. Finally, the adapter returns the URI using the Location header (7) and lets the client know it is an LDP resource using the \type" link relation (8) according to the LDP protocol.
The LDP client or other external applications can access and link to the bug using the URI returned by the adapter. In addition, clients can modify the bug using the PUT operation with modi ed RDF data which then will be propagated to the Bugzilla instance following a similar process. 4
In this paper, we presented the Bugzilla LDP adapter and provided an overview of how to build adapters for LDP-enabling existing applications in order to use them as read/write Linked Data applications. With minimal changes to the existing application, the Bugzilla LDP adapter enables semantic integration of the Bugzilla tool with other LDP-enabled applications and makes possible to have typed links between application data.
Acknowledgments: The authors are partially supported by the ALM iStack project of the Center for Open Middleware.