Linked USDL (initial version: Unified Service Description Language) was developed for describing business and software services using computer-readable and computer‐understandable specifications to make them tradable on the web/Internet, by comprising modules (e.g. usdl-core) where each module targeting a specific aspect.
Alongside with the business specifications, privacy has a crucial role in the services description. Personal data agreement properties should describe the privacy categorization that is applied onto the data that are provided, shared and utilized within the service and provide answers to the following questions.
How are data categorized into information types?
Which data is exactly collected (detailed specification)?
Who can access these data (which information type)?
Which actions describe each actor purpose (related with the data utlization and processing)?
Through the implementation of the privacy module tool, we focused on tackling the privacy questions mentioned above - by categorizing the data into two main types of information and extending the basic usdl-core module by defining new business roles that describe each actor's role and interaction with the data at hand.
Data are categorized into two main types of information.
General knowledge information (Regular Data)
Sensitive personal information (Sensitive Data).
Actors are the end users of the service and can be either human or computer entities.
Owners (the users that are the 'original'' data providers to the service)
Person of Interest
Authorised Person
System users (system users, including the service provider, are the entities that consist the system and their work is strictly related from it)
Third-party users (the users that do not belong in the organization/system, where the Rightful owners provide directly their information)
Third-party providers
Third-party end users
Authority/Regulator
Actions are the available tasks that Actors can perform on the Data classifications based on their business scope and restrictions.
accessDenied
analyzes
distributes
maintains
modifies
oversees
processes
provides
storages
In addition, custom annotations were created for modelling various concepts that can be applied on data actions with their respective values. To be more specific, the custom annotations focus on the security enhancement (labelled as "securityenhancement"), use intention (labelled as "useIntention") and retention period (labelled as "retentionPeriod").
The developed tool* leverages the SPARQL language in order to extract information from ontologies that are designed based on the above data, actors and actions categorization and present the entire model properties in a user-friendly format.
Please cite this work using:
@inproceedings{kapitsaki2018linked,
title={Linked USDL Privacy: Describing Privacy Policies for Services},
author={Kapitsaki, Georgia and Ioannou, Joseph and Cardoso, Jorge and Pedrinaci, Carlos},
booktitle={2018 IEEE International Conference on Web Services (ICWS)},
pages={50--57},
year={2018},
organization={IEEE}
}.
Upon modification of any javascript (.js) file we need to bundle up (using Browserify) all dependencies that are referenced in the code, due to the fact that browsers dot not have the 'require' method defined by default. Along with Browserify, we need to install some additional packages that allow us to bundle, copy/move and export our javascript code.
For convenience, we created a couple grunt tasks that allow us to automate the process of installing additional node modules (including Browserify), bundling our modified javascript files, and export them into the 'build' directory that the index HTML file will fetch them from.
Node.js and Grunt javascript tools are required for this automation and need to be installed.
Once all the required tools are installed, we can perform the following commands from within the project directory.
> 'npm install' (first time only, installs all required node modules)
> 'grunt' (required after each change in .js files, all tasks will be executed)
The tool supports ontologies that were build based on Protégé. Prior running the tool against an ontology, a verification should be made that in the first line of the ontology file the prefix is referring the actual ontology file and not some other required one (by default Protégé does so).
A simple format of the required configuration is as follows.