=Paper= {{Paper |id=Vol-1296/paper1 |storemode=property |title=Mapping Legal Requirements to SLAs: An Ontology Based Approach for Cloud-based Service Consumption |pdfUrl=https://ceur-ws.org/Vol-1296/paper1.pdf |volume=Vol-1296 }} ==Mapping Legal Requirements to SLAs: An Ontology Based Approach for Cloud-based Service Consumption== https://ceur-ws.org/Vol-1296/paper1.pdf
         Mapping legal requirements to SLAs:
           an ontology based approach for
          cloud-based service consumption

           Dirk Thatmann1 , Erwin Schuster2 , and Gökhan Coskun1
                          1
                            Technische Universität Berlin,
               Service-centric Networking (SNET), Berlin, Germany
                  {d.thatmann,goekhan.coskun}@tu-berlin.de
                         http://www.snet.tu-berlin.de/
                  2
                    T-Systems Austria GesmbH, Vienna, Austria
                              es.ontology@netsky.at
                            http://www.t-systems.at/


      Abstract. This work presents a new approach to ensure compliance to
      legal regulation in Cloud Computing, especially in Software-as-a-Service.
      Since high demanding business sectors, such as the health care sector,
      require high legal certainty, when contracting services offered by exter-
      nal providers. We provide a lightweight ontological representation of the
      German Federal Data Protection Act (BDSG) and a methodological ap-
      proach how this work can be extended with additional laws. Furthermore,
      we integrate the generic ontology into the Linked Unified Service De-
      scription Language (Linked-USDL) as Compliance to External Services
      (Linked-USDL CES) module. This extension enables service customers
      and providers to negotiate services more fine grained related to legal
      obligations, which increases legal certainty and thus the acceptance of
      a cloud-based service consumption. We demonstrate the applicability of
      the proposed ontology with the concrete use case “physician’s letter” that
      is part of a running national project TRESOR, which aims at the devel-
      opment of a trusted cloud ecosystem.

      Keywords: Linked-USDL, Legal Regualation, Ontology, BDSG, Mar-
      ketplace, Service Selection, Cloud Computing


1   Introduction
Through increasing awareness for the economic benefits it promises, Cloud Com-
puting approaches gained momentum. Having neither geographical borders nor
national limits, it is a global market where providers e.g. in India can have cus-
tomers in Jamaica. On the one hand, this distribution and flexibility provide
benefits for the customers. They are able to choose between offers from all over
the world and select the most appropriate one. This process is mostly supported
by marketplaces, which provide support for comparing different functional and
non-functional aspects of products from different companies. This in turn, in-
creases the competition in this market to the benefits of the customers. On the
2       D. Thatmann, E. Schuster, G. Coskun

other hand, it challenges businesses which are subject of legal restrictions and
have to follow national regulatories for the used software and the utilized data.
The aforementioned marketplaces are currently focusing on functional aspects
and have a few non-functional details like pricing information. Due to the com-
plexity of the laws and the expected legal consequences in case of disregard, the
legal aspects are omitted so far.
    In this paper, we want to attract attention to this issue by presenting concrete
use cases from the health care sector along with the legal regulatories from the
German privacy law. We advocate that legal aspects of Cloud Computing offers
should be semantically described, enabling machine-supported comparability on
marketplaces. By this means, the market is opened for businesses dealing with
sensitive data. Concretely, we present an extension for Linked-USDL that is a
remodeled version of the Unified Service Description Language (USDL). It is
described with semantic technologies and published following the Linked Data
principles. We exemplify the usage of the proposed extension by applying it to
the German privacy law.
    The remainder of this paper is structured as follows. In the following section,
we elaborate the necessity for describing legal aspects of Cloud Computing offers
(focusing on Software-as-a-Service), enabling businesses like the health care sec-
tor to benefit from the economic advantages. In Section 3 we present briefly the
related work in this field. In Section 4 we describe the core contribution of this
work, namely Linked USDL-CES and demonstrate in Section 5 the realization
of a concrete use case. After discussing the main critical points of this work in
Section 6, we conclude the paper with as summary and outlook in Section 7.


2   The Need for Describing Legal Aspects of SaaS Offers

Today, almost every organization makes use of IT components and software
products to some extend. Thus, optimizations of capital as well as operational
expenditure for IT solutions is concerning everyone. This explains the payed
attention attracted by and the success of Cloud Computing approaches. By
bundling resources and allowing shared usage, the different business models like
Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-
as-a-service (SaaS) optimize the exploitation of hardware as well as software
components. This is expected to lead to promising significant economic benefits
for the customers, which is mostly a convincing argument for the management
levels of various organizations.
    Being at the highest abstraction layer, SaaS solutions address end-users and
have therefore the biggest audience. Whoever uses software is a potential cus-
tomer for SaaS providers and can leverage its economic advantages. Currently,
daily used enterprise software like office products and customer relationship man-
agement software as well as very specialized graphic tools for design experts are
available “out-of-the-cloud”. This allows SaaS providers to offer their products
globally and to acquire customers all over the world, where network connectivity
is the only requirement.
                                       Mapping legal requirements to SLAs        3

    For supporting the customers in selecting the best offer for their needs, dif-
ferent marketplaces for SaaS offers arise which provide functional as well as
non-functional descriptions of existing offers and allow their comparison. How-
ever, for particular business sectors SaaS solutions are still not usable. As one
concrete example, the health sector is subject of comprehensive legal restrictions
and regulations. Although, a very simple SaaS solution for storing and editing
doctors’ records about patient treatment would reduce the costs of health care
institutions significantly, this sector cannot make use of the economic benefits
current Cloud Computing based solutions provide. In the current situation each
institution has to have its own IT infrastructure and administration staff. Driven
by this motivation, the currently running project Trusted Ecosystem for Stan-
dardized and Open cloud-based Resources (TRESOR) aims at opening the SaaS
market for the health sector.




               Fig. 1. Abstract illustration of the TRESOR project

   The main objective of TRESOR is the development of a trusted cloud ecosys-
tem that consists of an open platform for offering and consuming cloud services.
A broker and marketplace component mediates and combines services, whereas
a proxy enables the access to those cloud services by taking enterprise guidelines,
regulations by law and security policies into consideration.
   A central part of the TRESOR broker is the service description language,
that enables describing various aspects of SaaS offers. The Linked-USDL ex-
tension that is presented in this paper is a possible add-on of this description
language. With this extension, the health care institutions are able to control to
which extend the offers are compliant with legal requirements, select the most
appropriate one and establish negotiations. Due to the societal aspects of this
particular sector, the achieved significant cost reduction is expected to have a
remarkable impact on the societal expenses.


3   Related Work

Our goal is to support a fine grained description of compliance to legal regula-
tions in a service description in order to increase legal certainty on both service
provider and customer side. Our main task is to realize a Service Description
Language (SDL) with a lightweight ontology, able to express the BDSG and
4      D. Thatmann, E. Schuster, G. Coskun

similar acts. Especially, legal obligations for service customers and providers in-
cluding their relation to operation of a services and any processing of data are of
interest. As next, we list and rate the related work in accordance with our tasks.
In our rough structuring we differentiate between expressive and lightweight
ontologies. Representatives of expressive ontologies are:
    There are several ontologies in the field of legal reasoning and argumentation.
Edwina Rissland et al. [25] discussed the characteristics of the legal domain and
its main points of interest for the application of AI techniques in 1985. In [13,
p. 2] seven challenges are listed that AI and the legal domain face. Since then,
many representational languages and legal rules have been invented. However,
none reached the full expressiveness and complexity of existing legal texts in
a consistent manner [17]. Gorden et al. present a formal, mathematical model
of argument evaluation which applies proof standard [18]. Prakken’s model [24]
is suitable for modeling particular legal procedures, learning about actual le-
gal procedures and to learn about the process of formalizing an actual legal
dispute. Brüninghaus’ [10] methods automatically generate legal argumentation
and predictions from case texts. The Ontology of Professional Judicial Knowl-
edge (OPJK) [12] focuses on semantic search in the context of question and
answer (Q&A) systems. A request, formulated in a natural language, leads to
a response with a high level of consilence. [12] but has no added value for our
use-case. Gangemi et al. [15] introduce a design pattern for defining legal content
ontologies. Whereas Despres et al. [14] focus on how to apply a linguistics-based
tool “TERMINAE” to the legal domain and its alignment to core ontologies.
However, all these approaches do not support us in our main objective to de-
scribe services and its properties related to legal regulations, such as required
by the BDSG.
    In the field of E-Contracting, the description of legal aspects and obligations
mainly focus on general Terms and Conditions. Lamparter et al. [20] introduce
a formal model in cooperating common contractual items and rights/obligations
and applies the model in a scenario proofing the creditworthiness of customers.
The defined ontology allows the use of SWRL-based [19] rules in order to enable
automated proofing of the results. However, this work seems to have several sim-
ilarities and overlaps with our use-case, but does not focus on how to incorporate
legal obligations.
    The LKIF-core [9] bases on OWL. It covers a standard vocabulary of basic
legal terms having the focus on scenarios where the exchange of knowledge be-
tween different knowledge-based systems is required. LKIF’s shortcomings are
twofold. Firstly, both legal modules “legal-action” and “legal-role” offer terms
which support the definition of rules in the context procedural terms and roles
(compare action- role process). Furthermore, it is not easily possible to link to
a specific law, such as the BDSG. This could lead to the need of extensive ex-
pansions. Secondly, the core ontology is defined in English. A mapping layer and
legal dictionaries are required, which means that an additional fuzzy layer is
present.
                                        Mapping legal requirements to SLAs        5

    Knöpfler’s ontology already concentrates on the BDSG. However, his work is
motivated by the Computational Law. His ontology [27] maps rules taken from
the BDSG to programmable logic. Due to pragmatic reasons, Knöpfler chooses
SWI-PROLOG [29] to proof the fundamental technical feasibility of his idea. He
selects just a single section out of a total of 63 which already leads to an impres-
sive amount of rules and objects. A meaningful and appropriate visualization is
extremely difficult (comp. [27] p. 298.) to achieve. However, only few segments
seem to be reusable for our goal to develop an ontology addressing compliance
to legal regulation during a service description and requirement matching.
    In contrast to aforementioned expressive legal ontologies, we identified several
lightweight ontologies in the legal domain. This includes ontologies used for
representation of legal documents, such as MetaLex [9], a structured and nearly
complete representation, and the Akoma Ntosa XML standard presented by
Barabucci et al. [8]. The European Union published the multi-language thesauri
EuroVoc [4], which contains a subsection for legal terms. EuroVoc bases on
a SKOS extension [3] and new definitions are taken from the dublin-core [1].
However, these technologies and achievements can only supplement our solution.
    In the field of SDL, we identified the Linked-USDL [11], since it combines the
Linked Data [22], [2] principles and the Web of Data by remodeling the existing
USDL specification as RDF(S) vocabulary in order to enable a better support
for machines when trading services on the Web of Data. Linked-USDL currently
contains three modules: USDL-Core, USDL-Pricing and USDL-SLA [21]. The
USDL comes with a legal module which is designed only to express copyright
and license information. Thus, it is not usable to support legal compliance as
defined in our scope.
    Summing up, we have to propose our own lightweight ontology for describ-
ing services and their compliance to legal regulation for service discovery and
selection scenarios. We choose Linked-USDL since its wide scope, its Linked-
Data alignment and its focus on services descriptions seem to provide the most
promising basement for adding appropriate ontologies able to describe acts and
their obligations for service providers and consumers.


4   Ontological Description of Legal Compliance

The essential criteria for reliable decisions based upon service descriptions are
twofold. The first criteria is a matter of knowledge and trust. The service to
be described has to be known in-depth. By letting the service creator and ser-
vice provider create the description, who are expected to possess the mentioned
knowledge, this can be regarded merely as a question of trust. As such, it can
be tackled e.g. by the introduction of a trusted 3rd party or some certification
procedures. The second criteria is the quality of the service description language
as well as its usability. On the one hand, the expressivity needs to allow the
correct description of various facets. On the other hand, it needs to be easy to
understand and to use.
6       D. Thatmann, E. Schuster, G. Coskun

    Aiming at the description of legal aspects of SaaS services, we advocate
making use of semantic technologies and following the Linked Data principles
in reusing existing vocabularies and interlinking newly created ones with ex-
isting Web ontologies. To be more concrete, the Resource Description Frame-
work (RDF), RDF Schema (RDFS) and the Web Ontology Language (OWL))
emerged from the Semantic Web vision and defined as standards by the World
Wide Consortium (W3C) represent a profound basis for expressiveness in defin-
ing a language. Along with manifold tools for editing and reasoning, the usage
of these standards is very promising. Additionally, the ever increasing number of
online available vocabularies and ontologies for various domains, including the
service description domain as well as the legal domain, encourage their reuse by
pragmatically following the Linked Data principles. Reusing existing and broadly
used ontologies, which can be seen as de-facto-standards, is expected to simplify
the understanding of the new language constructs.

4.1   From the Law to the Ontology
The endeavor to develop an ontology, which provides language constructs to de-
scribe legal aspects of SaaS offers, requires the analysis of valid and relevant laws
for the particular context. Due to the circumstance of the TRESOR project, we
focused on the Germany Federal Data Protection Act (Bundesdatenschutzgesetz
- BDSG)[16]. Because of the complexity of the domain as well as the hierarchi-
cal relations between national, European and global regulations, we decided to
start with the concrete and develop the ontology in a bottom up approach. For
that purpose, we analyzed the text of the Germany privacy law and modeled
the domain ontology.
    We extracted nine concrete characteristics applicable to SaaS services, which
we call Compliance Criteria. For each we defined a set of possible Criteria Values.
Figure 2- A illustrates this in a simple notation.
    The extraction process we applied consist of the following steps:
1.0 Rough structuring of the BDSG [16] and scope reduction.
2.0 Define and structure the requirements.
    2.1 Compliance BDSG examples
    2.2 Compliance BDSG and USDL-CES
3.0 Defining an ontology - The USDL-CES
    Through the first step (rough structuring), we identified the following six
sections. (1) General and common provisions, (2) Data processing by public bod-
ies, which includes subsections, such as Legal basis for data processing, Rights
of the data subject and Federal Commissioner for Data Protection and Freedom
of Information. (3) section Data processing by private bodies and commercial
enterprises under public law contains of three subsections. The subsection Legal
basis for data processing is followed by Rights of the data subject and Supervisory
authority. In the end the structuring conclude with (4) Special-, (5) Final- and
(6) Transitional-provisions. Based on this structure we can now concentrate on
further questions, such as:
                                                                                          Mapping legal requirements to SLAs                                                    7


                                                                       Bundesdatenschutzgesetz TBDSG&
      A                                                                    TGerman3Federal3Data3Protection3Act&




        Stellen                                                                                  Zweckbestimmung
                                    Empfänger          Geschäftszweck         Schutzklasse                         Verarbeitung     UnternehmensArt           Schutzart
  TPublic3and3private                                                                              TPurpose3and
                                    TRecipient&      TBusiness3Objectiv&    TProtection3Class&                     TProcessing&     TEnterprise3class&    TProtection3class&
        bodies&                                                                                       scope&


                                    Controct3data                               Non3personal
     Family.related                                       Internal3use                                 Using         Recording          Non3special          Official3secrecy
                                     processor                                      data
                                     Identifiable                                                                                                              Suspected
      EU3countries                                       Advertisment          Personal3data         Processing       Alteration       Credit3institute
                                    natural3person                                                                                                             Indictable
                                                           Foreign                 Special           Processing                         PolOPhilORelO
         Public                        jrd3party                                                                     Transferring                             Account3data
                                                         advertisment           personal3data          Using                              Unions
        Public                       Responsable           Reporting              Criminal                                               Research             Professional
                                                                                                      Gathering       Blocking
      competition                     processing            agency                offense                                               organisation            secrecy
                                         point                                                        Gathering
       Non.public                                           Scoring             Anonym3data                            Erasing             Press               Research
                                                                                transmission           Using
                                                             Data
                                                         Transmission              Market            Gathering                        DeutscheWelle           Anonymised
                      Zweck                                                       research           Processing
                                                           Address
                    Tpurpose&                             Collection R          Data3privacy         Gathering
                                                           Transfer                                  Processing
                                                           Address              Employment.            Using
                        free3text
                                                           directory               related
                                                                                transmission




                     Fig. 2. German Federal Data Protection Act (BDSG) Taxonomy



   Q: Which sections contain relevant information for legal compliance? Which
we answer by: all sections containing obligations.
   Q: Which sections contain rights for 3rd parties? For the opposite case this
can be seen as obligations for service-customers and service-providers which in-
cludes e.g. rights, such as “provision of information and granting permission to
consult records to the persons concerned”.
   In order to reduce the scope, answering the opposite questions help to exclude
non-relevant legal text parts.


                                                                   Recipient (Empfänger)

        Name         Value                         Description
Contract data pro-    1     Bodies collecting, processing or using personal data on
cessor                      behalf of others, in accordance with §11 and §46 (3)
Identifiable natural  2     A natural person who can be identified and to whom the
person (“subject”).         data belongs, in accordance with §3 (1)
3rd Party             3     Each recipient of data or any person or body other than
                            the controller, in accordance with §3 (8), §46 (3)
Responsible     Pro-  4     Any person or body which collects, processes or uses per-
cessing        Point        sonal data on his, her or its own behalf, or which com-
(Controller)                missions others to do the same. In accord. with §3 (7)
      Table 1. Characteristics of Compliance Criteria ”Recipient (Empfänger)”

    In our case, based on the recently introduced BDSG sections, our result can
be summed up as: the core of the relevant legal sections are part of Section
2 and 3. Here we find concrete rules and guidelines for handling data within
different scopes and purposes, distinguished by public and private institutions.
8       D. Thatmann, E. Schuster, G. Coskun

This informations is important, since service providers do not know service-
customers’ obligations. Furthermore, Section 4 “Lawfulness of data collection,
processing and use” is important, since (1) stated: “The collection, processing
and use of personal data shall be lawful only if permitted or ordered by this Act
or other law, or if the data subject has provided consent”. In summary, it can
be ascertained that after rough structuring and scope reduction some Sections,
such as Section 1, Section 2 including Subsection 3, Section 5 and 6 (Final- and
Transitional-provisions) can be skipped.
    Gathering criteria is time consuming (and can be improved or automated
for sure), since it requires to understand the legal text in details and derive nec-
essary conclusions. The complete result of our work is spread over approximated
20 printed pages. Therefore, we are going to list just some for Section 5 relevant
use-case criteria in Table 1 and 2. However, additional information is available
online [7]:

                      Public and Private Bodies (Stelle )

       Name           Value                        Description
Family-related          1    Personal or family related in accordance with §1 (2)
                             No.3
EU countries            2    EU/EWR country without germen establishment in ac-
                             cordance with §1 (5)
Public                  3    Processing Points in accordance with §2(1)-(3)
Public competition      4    Public undertaking, participation in the economic con-
                             test in accordance with §27 (1) No. 2 (commercial enter-
                             prises which are, though in public ownership, exposed
                             to competition)
Non-public              5    Non-public Processing Point in accordance with §2(4)
Table 2. Characteristic of Compliance Criteria ”Public and Private Bodies (Stelle)”




4.2   Abstracting from the Law Ontology


Following the design of Linked-USDL, we introduce USDL-CES module in order
to address common Compliance for External Services (CES). The goal of CES is
to create a structure which can express on the one hand afore mentioned BDSG
taxonomy and on the other laws, structured in a similar way. Figure 3- B depicts
the ontology. The three levels between Figure 2- A and Figure 3- B are congruent
and show how to instantiate the BDSG-Taxonomy. “BDSG” maps to “Statute
or Act”, “Recipients” maps to “Compliance criteria” and “3rd Party” maps to
“Criteria Value”. In case of replacing the taxonomy by an
                                                           Mapping legal requirements to SLAs               9

                               usdl-core:
                                                                                       Gesetz
                                Service                                             StatuteLorLAct




                                                                                                        B
                  has                         has
                                                                                     has
                        0..1                        0..1                                       1…*
                                            usdl-ces:
            usdl-sla:                                                           Compliance-Merkmal
                                      ComplianceLevel
        ServiceLevelProfil               Profile                                  ComplianceLCriteria


                                                                has       1…*
            has                             has                                       has
                  1…*                                1…*                                       0…*

            usdl-sla:                       usdl-ces:                 has 0…*      Ausprägung
         ServiceLevel                ComplianceLevel                                 CriteriaLValue




    Fig. 3. Combining the generic BDSG taxonomy with the Linked-USDL ontology

    appropriate taxonomy expressing other acts, different namespaces should be
introduced and applied.


4.3    LinkedUSDL-CES (Integration into LinkedUSDL)

In order to use this ontology for service description, we combine the USDL-CES
with Linked-USDL, as depicted in Figure 3.


5     Realizing a Use-Case with Linked USDL-CES

We apply our approach to a sample use-case motivated by the TRESOR project.
In this example a hospital, which is a Public Enterprise and acts as a Public Body
wants to use a Physician’s Letter-service provided by an external service provider
(Recipient: 3rd party). The hospital’s requirements on legal regulation related
to this use-case are listed in Table ??. Since the Business Objective is set to
Internal Usage, the hospital may - under specific requirements - use (compare
BDSG Section 14) the Special Personal Data for other internal purposes. Spe-
cial Personal Data refers to especially Sensitive Personal Information (compare
BDSG Section 3, Paragraph 9) to be processed, which includes medical data
of patients. For instance, the service provider retrieves the knowledge by both
statements, that the usage of Special Personal Data under the terms an defini-
tion of BDSG Section 14, Paragraph 5 is permitted even if the purpose is not
listed. Since Physician’s Letter is stated as purpose the service provider can de-
rive that it is prohibited to transfer the data to 3rd parties, such as laboratories.
This example shows how restrictive the criteria can be handled and enforced
with our approach. In addition, we achieve a high level of compliance to legal
regulation which means a higher level of legal certainty for all parties, service
customer (SC) and service provider (SP).
10      D. Thatmann, E. Schuster, G. Coskun


     Compliance Criteria (Name)                  Criteria Value (Ausprägung)

      English                German               English               German
Pub./Priv. Bodies     Stelle              Public                   ÖffWettbewerber
Recipient             Empfänger          3rd Party                Dritter
Business Objectiv     Geschäftszweck     Internal usage           Eigennutzen
Protection Class      Schutzklasse        Special Personal Data BesPersonenDaten
Purpose and Scope Zweckbestimmung         Using                    Nutzen
Processing            Verarbeitung        n/a                      
Purpose               Zweck               Physician’s Letter       ”Arztbrief“
Enterprise Class      UnternehmenArt      n/a                      
Protection Class      Schutzart           n/a                      
Table 3. Description of BDSG legal compliance criteria and values - Physician’s Letter




6    Discussion

Due to the challenging objective of this work, it has inherently some critical
points, we want to discuss briefly in this section. The first one is the semantic
complexity and expressiveness of the proposed ontology. However, the creation
of an ontological representation of laws is a difficult task. Even if the ontology
engineer focuses only on a small part. On the one hand, understanding the mean-
ing of legal text in-depth without being an expert for the concrete legal text at
hand is very challenging. In order to understand all aspects and to comprehend
the interrelation with other laws, it is also necessary to know how judges inter-
preted the text and how they made their decisions in concrete examples. On the
other hand, creating a comprehensive ontology, that represents such a complex
knowledge exhaustively seems to be unfeasible. This is due to the fact, that re-
liable decisions in this context can only be made within margin of discretion by
humans, respective judges.
    Therefore, an ontology for such a domain is not expected to represent the
knowledge enabling automatic decision making, but the basic terms in order
to allow communicating the legal aspects between providers and customers. In
this concrete work, we aim at providing a basic set of terms, representing an
extraction from the German law, namely BDSG, and allowing SaaS providers
to communicate legal compliance. We are convinced that such a description is
essential for the success of SaaS for sensitive business sectors and want to attract
attention to this issue and make a first proposal.
    A second critical aspect is its focus on the German law. However, as one of
the most comprehensive privacy data protection laws available, we think that it
provides a good starting point and represents the basis for fruitful discussions
for the next steps, towards an international standard.
    The last critical aspect, we want to mention is the following. For a really
legally valid description language, an internationally accepted standard has to
be created with the authorities in this area. Until then, we think it is of high
                                         Mapping legal requirements to SLAs        11

value to work on basics towards this challenging goal and expect some light-
weight ontologies become de-facto-standards. These in turn, can simplify the
definition of a real standard.


7    Summary and Outlook

In order to support a better legal compliance when negotiating contracts between
SaaS consumers and providers, we propose a generic methodology for deriving a
taxonomy for specific laws/acts, such as the German Federal Data Protection Act
(BDSG). Based on the taxonomy we described how to instantiate the taxonomy
in our generic Linked-USDL CES module, which we propose as new extension for
Linked-USDL. As proof of concept, we applied our approach in a sample use-case
named Physician’s Letter in the context of the Cloud Ecosystem TRESOR [6].
Since we finished our research before Pedrinaci et al. presented a Linked-USDL
vocabulary [23], we have to check whether an adaptation is required. A next step
could be to create taxonomies for other German or European acts.


Acknowledgments. This work was performed in the context of the TRESOR
project and was funded by the German Federal Ministry of Economic Affairs
and Energy.


References
 1. Dublin Core, http://eurovoc.europa.eu/drupal/?q=de/abouteurovoc,http://
    dublincore.org/documents/2012/06/14/dcmi-terms/?v=elements
 2. Linked Data. W3C, http://www.w3.org/standards/semanticweb/data
 3. Simple Knowledge Organization System (SKOS). W3C, http://www.w3.org/
    2004/02/skos/
 4. Thesaurus EuroVoc, http://eurovoc.europa.eu/drupal/?q=de/node/411
 5. Unified Service Description Language (USDL). W3C Language Incubator Group,
    http://www.w3.org/2005/Incubator/usdl/
 6. TRESOR (2012), http://www.cloud-tresor.com/
 7. Linked-Data CES (March 2013), http://cloud-tresor.de/linked-usdl-ces/
 8. Barabucci, G., Cervone, L., Palmirani, M., Peroni, S., Vitali, F.: Multi-layer
    Markup and Ontological Structures in Akoma Ntoso. In: Casanovas, P., Pagallo,
    U., Sartor, G., Ajani, G. (eds.) AI Approaches to the Complexity of Legal Systems.
    Complex Systems, the Semantic Web, Ontologies, Argumentation, and Dialogue,
    Lecture Notes in Computer Science, vol. 6237, pp. 133–149. Springer Berlin Hei-
    delberg (2010)
 9. Boer, A., Winkels, R., Vitali, F.: MetaLex XML and the Legal Knowledge In-
    terchange Format. In: Casanovas, P., Sartor, G., Casellas, N., Rubino, R. (eds.)
    Computable Models of the Law, Lecture Notes in Computer Science, vol. 4884, pp.
    21–41. Springer Berlin Heidelberg (2008)
10. Brüninghaus, S., Ashley, K.D.: Generating Legal Arguments and Predictions from
    Case Texts. In: Proceedings of the 10th International Conference on Artificial In-
    telligence and Law. pp. 65–74. ICAIL ’05, ACM, New York, NY, USA (2005)
12      D. Thatmann, E. Schuster, G. Coskun

11. Carlos Pedrinaci, T.L.: Linked USDL (2012), http://www.linked-usdl.org/
12. Casellas, N.: Modellinglegal knowledge through ontologies. OPJK: The Ontology
    of professional judicial knowledge. Ph.D. thesis (Dec 2008)
13. Casellas, N.: Legal Ontology Engineering - Methodologies, Modelling Trends, and
    the Ontology of Professional Judicial Knowledge. Springer (2011)
14. Despres, S., Szulman, S.: TERMINAE Method and Integration Process for Le-
    gal Ontology Building. In: Proceedings of the 19th International Conference on
    Advances in Applied Artificial Intelligence: Industrial, Engineering and Other Ap-
    plications of Applied Intelligent Systems. pp. 1014–1023. IEA/AIE’06, Springer-
    Verlag, Berlin, Heidelberg (2006), http://dx.doi.org/10.1007/11779568_108
15. Gangemi, A.: Design patterns for legal ontology construction. In: The semantic
    Web and the Regulation of Electronic Social Systems (2007)
16. German Federal Ministy of Justice: Federal Data Protection Act (BDSG).
    Federal Law Gazette I (September 2009), http://www.bfdi.bund.de/EN/
    DataProtectionActs/Artikel/BDSG_idFv01092009.pdf, federal Data Protection
    Act (BDSG) as at 1 September 2009 with amendments 2010
17. Gordon, T.F., Governatori, G., Rotolo, A.: Rules and Norms: Requirements for
    Rule Interchange Languages in the Legal Domain. In: Governatori, G., Hall, J.,
    Paschke, A. (eds.) Rule Interchange and Applications, Lecture Notes in Computer
    Science, vol. 5858, pp. 282–296. Springer Berlin Heidelberg (2009)
18. Gordon, T.F., Walton, D.: The Carneades Argumentation Framework: Using Pre-
    sumptions and Exceptions to Model Critical Questions. In: Proceedings of the 2006
    Conference on Computational Models of Argument: Proceedings of COMMA 2006.
    pp. 195–207. IOS Press, Amsterdam, The Netherlands, The Netherlands (2006)
19. Horrocks, I., Patel-Schneider, P.F., Boley, H., Tabet, S., Grosof, B., Dean, M.:
    SWRL: A Semantic Web Rule Language Combining OWL and RuleML (Mai 2004),
    http://www.w3.org/Submission/SWRL/
20. Lamparter, S., Luckner, S., Mutschler, S.: Formal Specification of Web Service
    Contracts for Automated Contracting and Monitoring. In: System Sciences, 2007.
    HICSS 2007. 40th Annual Hawaii Intl. Conference on. pp. 63–63 (Jan 2007)
21. Leidig, T., Momm, C.: USDL Service Level Agreements. http://www.
    linked-usdl.org/ns/usdl-sla (April 2012)
22. Linked Data Community: Linked Data, http://linkeddata.org/
23. Pedrinaci, C., Cardoso, J., Leidig, T.: Linked USDL: A Vocabulary for Web-scale
    Service Trading (April 2014)
24. Prakken, H.: Formalising ordinary legal disputes: a case study. Artificial Intelli-
    gence and Law 16(4), 333–359 (2008)
25. Rissland, E.: AI and Legal Reasoning. AI Mag. 9(3), 45–55 (Sep 1988)
26. Sartor, G.: Legal concepts as inferential nodes and ontological categories. Artificial
    Intelligence and Law 17(3), 217–251 (2009)
27. Siegfried Knöpfler: Computational Law und Datenschutz: Innovativer Datenschutz.
    Duncker & Humblot Berlin (2012), ISBN 978-3-428-13860-9
28. Slawik, M.: Domain Specific Language and a Pertinent Business Vocabulary for
    Cloud Service Selection. In: Proceedings of the 11th International Conference on
    Economics of Grids, Clouds, Systems and Services (GECON). Springer (Sep 2014)
29. Wielemaker, J.: SWI-Prolog, http://www.swi-prolog.org/