Policy-enabled Linked Data Server (PeLDS)

The Policy-enabled Linked Data Server was a project to control the disclosure of Linked Data graphs with user-defined access policies and WebID as authentication layer. It was part of the Diploma thesis of Hannes Mühleisen. The project has since been discontinued, but this page remains for reference, downloads and documentation.

Download

Publications

Installation

Requirements

PeLDS can and has been installed on Linux, Mac OS X and Windows. Please make sure you have a recent (> 1.6) Java runtime environment and one of the supported database servers is installed on the target system. The installation instructions will continue with MySQL 5.x as a database server, but HSQLDB, MySQL, Oracle, PostgreSQL, and Apache Derby are supported.

Please also make sure the environment variable JAVA_HOME points to the Java 1.6 installation directory.

Download and unpack

Download the latest PeLDS / Tomcat bundle and unpack them somewhere on your hard disk. You should have a directory "pelds-tomcat" with some subdirectories. The subdirectories "bin" and "conf" are relevant for the installation.

Database prepraration

You need to create a new database within your database system. If you are using MySQL, you may use the SQL script "tables.sql" within the "conf" folder. This script creates a database "pelds" and a user "pelds". Change the default password "changeme" to prevent unauthorized access.
On a Unix system, you can execute the SQL script by opening a terminal window. Change to the "conf" directory within the PeLDS installation and type

mysql -u root -p < tables.sql

You will then be asked to provide your MySQL root user password.

Configuration

Open the configuration file "pelds.properties" within the "conf" folder. Change the database access parameters to your system. If you used the MySQL setup script, you only need to change the value of "pelds.db.pass" to the password for the "pelds" database user you defined before.

Startup

Well, now we should be set for first startup. Execute the script startup.sh on Linux and OSX or startup.bat on windows. You will find those within the "bin" folder in the PeLDS installation. If everything went well you should see something like

Using CATALINA_BASE: /var/pelds-tomcat
Using CATALINA_HOME: /var/pelds-tomcat
Using CATALINA_TMPDIR: /var/pelds-tomcat/temp
Using JRE_HOME: /System/Library/Frameworks/JavaVM.framework/Home

Now you can try accessing the PeLDS API to check PeLDS out.
PeLDS runs on the TCP ports 7080 for HTTP queries and 7443 for HTTPS queries. If you are using the same machine you installed PeLDS on, use this link to access PeLDS.

If you dont see the PeLDS web interface, check your JAVA_HOME environment message or the PeLDS log files in the "logs" folder. If nothing helps, use the Support section.

PeLDS Usage

PeLDS can be used to securely serve your RDF data to HTTP clients. In order to do that, you have to publish an access policy and your data within your PeLDS instance. To keep this documentation short, we will assume the reader is familiar with the principles of Linked Data, RDF and SPARQL.

Our example case will consist of a user publishing his current GPS position in a safe manner.

In order to issue commands modifying policies or data to a PeLDS server, you have to be authenticated using FOAF+SSL. Most operations can be tried out on the HTML interface available on your local installation at https://localhost:7443.

Publish access policy

Access policies have to be provided in our new PsSF-Format, which is based on the rule language SWRL.
Consider the following rule:

                        PosAccessRule:
                        QueryAction (?action) &&
                        actor(?action,http://example.com/someuser)
                        =>
                        permit_triple(*,exOnt:longitude,*) &&
                        permit_triple(*,exOnt:latitude,*);
                        


This rule named "PosAccessRule" says: If someone issues a query referred to by the variable "?action", and the predicate "actor" with parameters containing the query action and the URI of a authorized user, then (=>) permit access to the triples with have "longitude" and "latitude" as a predicate to control which triples are allowed to be served.

Rules start with an alphanumeric label followed by a ":", a list of conditions on which the rule should apply terminated by "=>" and finally a list of consequences. The rule is closed with a ";" character. The elements in the included lists are separated by "&&". An access Policy can contain many rules separated by either a newline or a space character.

Predicates can be used as described in the SWRL documentation, but there are three custom predicates allowed in the consequence list: permit_triple, permit_resource and permit_instance.

permit_triple(subject,predicate,object) can be used to describe single triples. The wildcard "*" may be used for any of the parameters. permit_resource(uri) collects all triples describing a particular uri, and permit_instance(class_uri) collects all triples describing instances of a certain class.

Example of a full access policy:

                        PublicRule:
                        pelds:QueryAction(?action)
                         => 
                        pelds:permit_triple(http://example.com/horststein,rdfs:seeAlso,*) ;
                        
                        FamilyRule:
                        pelds:QueryAction(?action) && 
                        pelds:actor(?action,?actor) && 
                        foaf:isMarriedTo(http://example.com/horststein,?actor)
                         => 
                        pelds:permit_triple(http://example.com/horststein,*,*) ;
                        

Add this policy to your local PeLDS instance

Publish RDF data

RDF data can be published and modified on a PeLDS instance by using the SPARQL/Update update language. Be sure to include Be sure to specify a dataset with INTO/FROM statements. If you want to create a dataset, just use it in a update statement, and it will be created.

The endpoint for updates is /update, the parameter containing the SPARQL/Update query is named "query".

Example of a SPARQL/Update query:

                        PREFIX foaf: <http://xmlns.com/foaf/0.1/>
                        PREFIX rdfs: <http://www.w3.org/2000/01/rdf-schema#>

                        INSERT INTO <http://example.com/horststein> {
                          <http://example.com/horststein>
                            a foaf:Person ;
                            foaf:name "Horst Stein" ;
                            foaf:phone "030123456" ;
                            foaf:isMarriedTo <http://example.com/annastein> ;
                            rdfs:seeAlso <http://example.org/staff/horststein> .
                        }
                        

Add this graph to your local PeLDS instance

SPARQL queries

SPARQL queries can be issued using the SPARQL query language and the SPARQL REST-Protocol on the endpoint /query . The parameter containing the SPARQL query is named "query". Another parameter "output" controls the output format, set "xml" for RDF/XML, "json" for JSON, and "txt" for a text-based format useful for debugging.

Example:

                        PREFIX foaf: <http://xmlns.com/foaf/0.1/>
                        SELECT ?name ?phone FROM  <http://example.com/horststein>
                        WHERE {
                          <http://example.com/horststein> 
                            foaf:phone ?phone ;
                            foaf:name ?name .
                        }    
                        

Run this query on your local PeLDS instance

If you followed all parts of the example, the phone number contained in the published graph is now only visible to the graph owner (you), and the user identified by http://example.com/annastein, because the access policy permits that triple to be retrieved by her.

Linked Data dereferencing

In order to publish linked data, a requester has to be able to dereference the URLs used within a graph. If you are using an URL prefix pointing to PeLDS, this can be achieved with builtin methods. Configure the "pelds.dereferencing.prefix" configuration value to contain that prefix and then use the /data endpoint to resolve them. For example, if your PeLDS instance is installed unter https://example.pelds/, you would use URLs starting with http://example.pelds/data/ within your graphs and also configure pelds.dereferencing.prefix = http://example.pelds/data/ .
Then, a request to http://example.pelds/data/res1 returns a resource description.