Note: This article was written for a seminar at university. It is a summary of mainly two papers: "On partial encryption of rdf-graphs" by Giereth (2005) and "Possibilities to encrypt an RDF-Graph" by Gerbracht (2008). If you are intereseted in more literature, check out the related work section of "HDTcrypt: Compression and encryption of RDF datasets" by JD Fernández et al. (2020) including the following papers: "HDTcrypt: Compression and encryption of RDF datasets" by JD Fernández et al. (2020), "Self-enforcing access control for encrypted RDF" by JD Fernández et al. (2017), "Towards search on encrypted graph data" by A. Kasten et al. (2013), and "Privacy-preserving reasoning for hypergraphical knowledge bases" by G. Voutsadakis (2008). (Thank you anonymous reviewer.)

Introduction

In the course of digitization, society has started to collect information about everything and everyone. We are now able to correlate and link the collected data to increase the information value and draw deeper conclusions. Such vast amounts of information and the resulting conclusions offer us many advantages and an immense knowledge potential: companies can recognize customer needs and provide the right products; widespread diseases can be detected at an early stage to save the lives of thousands of individuals; traffic in a metropolis can be directed efficiently to reduce pollution and avoid bottlenecks in the infrastructure.

However, many people regard information about themselves as very personal. Therefore, they want their personal data to be protected. The need for privacy in data processing is strong and we cannot ignore it. Privacy in this context means that sensitive data is only accessible to authorized entities.

A fundamental challenge in the described development of data collection is to not miss the opportunities offered by the data without violating the privacy of the individual.

Merging and re-using distributed data to gain knowledge is an important aspect of the Semantic Web (Giereth, 2005). As part of the Semantic Web, the Resource Description Framework (RDF) and RDF graphs are important technologies often used in large NoSQL stores to correlate large amounts of data (Giereth, 2005Gerbracht, 2008). In this context, a solution is desirable that protects relevant data and thus ensures privacy, while still allowing further processing of the data. One approach is to only partially encrypt the data so that some of the data can still be processed. These approaches address some of the aforementioned requirements, but also introduce new challenges.

In this article, we will take a closer look at RDF graphs and how we can use cryptographic methods to achieve privacy. We compare the approach of partially encrypted data with approaches where the data is fully encrypted. This comparison illustrates the tradeoff between maximum privacy and the ability to process data.

Related Work

Although the broad field of cryptography is a popular field of research, comparatively little has been done in the field of encryption of RDF graphs (Gerbracht, 2008). Some of the most extensive works come from Giereth (compare for example (Giereth, 2005)) and Gerbracht (see for example (Gerbracht, 2008)) who provide solutions for partial encryption of RDF Graphs.

RDF Graphs, Privacy & Cryptography

In this section we will explain the background for the remaining sections in greater detail. To that end, we will address a number of topics: we explain what RDF graphs are, we discuss privacy for information systems in general, and, last but not least, we explore what privacy means in the context of RDF graphs.

Resource Description Framework (RDF)

The Resource Description Framework, or RDF, is an assertional language (Giereth, 2005). According to the World Wide Web Consortium (W3C) RDF is a standard model for data interchange on the Web ("RDF Primer", 2004).

The language itself consists of assertions. Assertions link data together, showing that a particular piece of information about a resource is true (Gerbracht, 2008Giereth, 2005). There are various ontologies and vocabularies, such as FOAF (FOAF, 2014) or OWL (OWL, 2012) to describe assertions. The basic structure, however, is usually the same: an assertion consists of a subject, a predicate, and an object. It is represented as triple  < s, p, o>. The structure of an assertion triple can be expressed as: {U ∪ B} × {U} × {U ∪ B ∪ L}, where U denotes the set of valid Uniform Resource Identifiers (URI) (Berners-Lee et al., 2005), B is the set of blank nodes, and L is the set of RDF literals. (Gerbracht, 2008Giereth, 2005"RDF/XML Syntax Specification", 2004)

A number of assertions can be considered as a set of triples. Such a set of triples is commonly referred to as an RDF Graph (Giereth, 2005"RDF/XML Syntax Specification", 2004). An RDF Graph or triple set can be interpreted as a Directed Labeled Graph (DLG): Subjects and objects form nodes, triples are edges and predicates are edge labels (Giereth, 2005"RDF Primer", 2004). The result is a representation that provides both structural information and label information (Giereth, 2005). Figure 1 shows an example of a simple RDF Graph containing two assertions. Besides a visualization as DLG, an RDF Graph can be serialized. Different languages such as RDF/XML, N-Triples or Notation 3 (N3) can be used for serialization (Giereth, 2005Gerbracht, 2008"RDF/XML Syntax Specification", 2004).

Ways to gain Privacy: Cryptography

There are various ways to achieve privacy, and the possibilities of gaining privacy in information processing can be broken down into two methods (as discussed in (Giereth, 2005).)

1. We can control the access to the sensitive data and then secure the infrastructure used for storing and transferring the data (Giereth, 2005).

2. We can protect the sensitive data itself by using cryptographic methods (Giereth, 2005).

The first approach seems rather obvious, but is hardly feasible. Controlling the access to data and securing communication channels requires a trustworthy infrastructure. This is very difficult, almost impossible to achieve. We must always assume that there are hostile participants in a network at any time: According to the widely accepted Dolev-Yao attacker model, the attacker is the network (Dolev & Yao, 1983). Therefore, in principle, the attacker has the possibility to change, readdress, duplicate, delete, or add new messages. Consequently, the first approach is not really an option to ensure privacy.
The second approach with cryptographic methods is the more reliable solution. This is the case because, for this approach, reliability is not based on the security of the network, but on the strength of the cryptographic algorithms used. In contrast to the security of a network, we have more control over the strength of cryptographic algorithms.

In the following section, we provide a short overview regarding basic secure cryptographic methods including general encryption and decryption algorithms, symmetric and asymmetric encryption methods, and data integrity.

Encryption An encryption process encrypts readable plaintext data using an encryption algorithm in combination with an encryption key. The resulting ciphertext should not reveal any information about the original data. Then it is only readable for authorized users who can restore the original information by decrypting the ciphertext. We can express an encryption process as e(m,k_e) = c, with e as a function implementing the encryption algorithm, m as the plaintext, k_e as the encryption key, and c the resulting ciphertext. (Gerbracht, 2008Giereth, 2005)

Decryption A decryption process can be expressed as d(c,k_d) = m, with d as a function implementing the decryption algorithm, c as the ciphertext, k_d as the decryption key, and m the resulting plaintext (Gerbracht, 2008Giereth, 2005). A decryption process is the inverse process to the encryption process e so that d(e(m,k_e),k_d) = m applies (Gerbracht, 2008).

Symmetric and asymmetric approaches We can distinguish cryptographic methods between symmetric and asymmetric approaches. The cryptographic method is symmetric if k_e = k_d applies; otherwise it is asymmetric. (Gerbracht, 2008Giereth, 2005) Examples for symmetric algorithms include the Data Encryption Standard (DES) ("Data Encryption Standard", 1999) and the Advanced Encryption Standard (AES) ("Advanced Encryption Standard", 2001). A typical application of a symmetric approach is the encryption of hard drives. Here, the same entity encrypts the data for protection with a key that later decrypts the data for access with the same key. Asymmetric approaches include for example the public-key cryptosystem by Rivest, Shamir and Adleman, also known as RSA (Rivest et al., 1978). A typical application of asymmetric approaches is the encryption of emails. In this case, the sender of an email encrypts the data with a public key of the intended recipient and the receiver decrypts the data for access with a different private key.

Data Integrity Secure cryptographic methods require a solution to ensure the integrity of the data; one way hash functions provide solutions for data integrity checks (Giereth, 2005). We can use hash functions to generate a digest of a message. This digest can then be used to detect whether the message has been changed since the original digest was generated. (Secure Hash Standard, 2015)
Examples of hash functions for data integrity checks include the Secure Hash Algorithms (SHA) as described in the Secure Hash Standard (SHS) of the National Institute of Standards and Technology (NIST) (Secure Hash Standard, 2015), and the MD5 Message-Digest Algorithm (MD5) (Rivest, 1992).

Privacy in RDF Graphs

An RDF Graph provides two types of information: structure information and label information. Both types can be protected. Protecting structure information means to not reveal the topology. Protecting label information means to not reveal node and edge values. (Giereth, 2005)

It is often the case that sensitive and non-sensitive data are mixed in one RDF graph. Therefore, it would be sufficient to protect only the sensitive data to provide the desired level of privacy, not the complete set of data. For RDF graphs, this means that it suffices to encrypt only parts of the graph. Regardless of which portion of the graph is to be protected – the entire graph or only parts of it – we can use common encryption methods as described in section Encryption. Depending on the application, symmetrical and asymmetrical methods are possible. The major challenge is the selection of relevant fragments.

As indicated earlier, data integrity checks are important when working with cryptographic techniques and should always be performed. RDF graphs present some challenges in this regard. The number of possible values in RDF graphs is typically not large because certain schemas are used, which usually specify only a certain number of possible values (Giereth, 2005"RDF/XML Syntax Specification", 2004). This creates an opportunity for attackers to guess the original message by testing all possible values and comparing the hash values.
The concept of one-way hash values can be extended by advanced methods such as randomized hash values. Randomized hash values can work around the aforementioned problem. The approach provides a higher degree of security because attackers can not guess the original message by exploiting the hash values. This method, however, introduces a compromise between security and data integration: we can still use the result for integrity checks but no longer for merging. (Giereth, 2005)

There are multiple ways to gain privacy in RDF graphs using cryptographic methods. Following the aspect of different proportions of sensitive data, the approaches can be broken down into two categories of methods as illustrated in Figure 2: the full encryption of the entire RDF graph and the partial encryption of sensitive subgraphs of the RDF graph.

Fully Encrypted RDF Graphs

One approach to protecting the sensitive data of RDF graphs is to fully encrypt the entire graph. This is necessary if the entire graph represents sensitive information. In principle, this is also applicable if only a part of the data is sensitive, since it protects the entire graph with the procedure. This also means that the sensitive parts are protected.

Full Encryption Process

The encryption process is very straightforward and does not really differ from the encryption of common messages or data structures. We interpret the complete graph as one coherent data block and we therefore ignore the inner structure of the graph itself or its semantic; we take the entire data block and encrypt it using common encryption methods. As a result, we get a ciphertext containing the encrypted RDF graph. If desired, digests can be calculated during the encryption process to enable integrity checks.

Decryption Process of Fully Encrypted RDF Graphs

The decryption process is the inverse process of the encryption process. We simply access the entire cipher block and decrypt it as a whole. As a result, we get the original RDF graph. If data integrity methods were applied in the encryption process, we can check the integrity of the accessed ciphertext during the decryption process.

Characteristics

Most of the characteristics depend on the chosen cryptographic methods. Among other things, a fully encrypted RDF Graph as presented has the following characteristics.

Structural Information and Label Information Both types of information provided by an RDF Graph – the structure information and the label information – are completely hidden by the full encryption of the graph.

RDF Compliance Since the result is a common ciphertext, the result is not RDF compliant. In fact, it is not possible to infer the nature of the original data from the encrypted data. Without additional information, it is not apparent that the original data is an RDF graph.

Data Integrity Data integrity checks using hash functions can be applied.

Access Only authorized individuals who have access to the decryption key can access the information by decrypting the ciphertext. The level of protection depends entirely on the encryption methods used.

Working with the data In order to work with the RDF graph, the entire cipher block has to be accessed and decrypted by an authorized person –- even if only a single information is required and no matter how big the RDF graph and the corresponding ciphertext is.

Partially Encrypted RDF Graphs

Another approach to protect sensitive data of RDF graphs is to encrypt only sensitive elements and subgraphs, while leaving non-sensitive data unencrypted and readable in the graph (Gerbracht, 2008Giereth, 2005). This results in a partially encrypted RDF graph. There are several ways to approach partial encryption of RDF graphs. A commonly applied practice is to remove the sensitive elements from the original graph, encrypt the removed data, and store it in a new file. Afterwards, the file is linked to the original graph (Giereth, 2005). According to Giereth (Giereth, 2005), these methods have some disadvantages: The original RDF Graph is separated into different files, the result with multiple files is not RDF-compliant, the linkage has to be done manually, and there are no on ow to reintegrate the data into the RDF graph.
Besides this approach, there are other solutions for encoding elements and RDF subgraphs that are more optimal. These approaches include solutions based on XML-Encryption (Imamura et al., 2013) and XML-Signature (Bartel et al., 2013). For this article, we propose the method presented by Giereth (Giereth, 2005). This approach uses Encryption Containers and replaces the sensitive data with blank nodes that in turn link to the corresponding Encryption Container (Gerbracht, 2008Giereth, 2005).

Encryption Container (EC) The Encryption Container (EC) is an XML encryption compliant representation that contains the ciphertext of sensitive data elements and all necessary metadata. Encryption metadata contains all relevant information such as the cryptographic keys, ciphers and the chosen encryption algorithm (Giereth, 2005). XML literals can be inserted as objects in valid RDF graphs. So you can simply integrate the EC as an XML literal into the original graph. The result is still a well formed RDF Graph (Gerbracht, 2008"RDF/XML Syntax Specification", 2004). We will see more about the exact use of ECs later in the Encryption Process section.

Blank Nodes Blank nodes can occur in valid RDF graphs. A triple can have a blank node as subject, object or both ("RDF/XML Syntax Specification", 2004). It is not possible to encrypt RDF graphs partially that contain blank nodes, since the rematching of the nodes to their original statements in the decryption process would fail. As one possible solution, we can replace all blank nodes with blank node identifiers (Gerbracht, 2008"RDF/XML Syntax Specification", 2004). This can be achieved by applying Carroll’s One-Step Deterministic Labeling Algorithm presented in (Carroll, 2003).

Graph Transformations

The encrypted data is integrated into the graph as literal value. This means the original node is replaced by its EC serialization. In RDF, only objects can be literal values ("RDF/XML Syntax Specification", 2004). If we want to encrypt a subject or predicate, a graph transformation is required in order to get a well formed RDF Graph as result (Gerbracht, 2008Giereth, 2005). Figure 3 shows examples for all relevant transformations. We can distinguish three general cases:

Subject Transformation This transformation is required when we want to encrypt a subject. For each subject S, we add a new triple  < B, renc:encNLabel, EC_S> to the graph, B as newly created subject and EC_S as the XML serialized EC of S. Afterwards we replace all references to S with references to B. This means that the encryption of S requires one change for each triple containing S as subject or object. (Gerbracht, 2008Giereth, 2005)

Object Transformation Theoretically, it is possible to replace objects directly by their encryption container serialization. This would change the data type of the node to rdf:XMLLiteral. However, it makes sense to apply a graph transformation in order to get a uniform presentation format. This process is similar to the subject transformation. For each object O, we add a new triple  < B, renc:encNLabel, EC_O> to the graph, with B as newly created subject and EC_O as the XML serialized EC of O. Afterwards we replace all references to O with references to B. (Gerbracht, 2008Giereth, 2005)

Predicate Transformation In RDF, only URI references are allowed as predicates. Thus, we can not just replace the predicate with a new blank node: a transformation is required. To solve this, we can apply the concept of RDF reification ("RDF Primer", 2004) while transforming the graph. (Gerbracht, 2008Giereth, 2005"RDF/XML Syntax Specification", 2004) The transformation of predicates includes three steps: 1. we replace the original predicate P with the URI reference renc:encPredicate, 2. we add a new reification quad to identify it, and 3. we add a new property renc:encPLabel = EC_P to the reification quad. This property indicates that the real predicate is encrypted in EC_P.

Partial Encryption Process

The partial encryption process itself comprises three steps: segment selection, segment encryption, and encryption graph transformations.

Segment Selection We select all fragments that are relevant for the encryption. Usually all sensitive data are candidates for encryption. Fragments can be subjects, objects, predicates or triples (Giereth, 2005). In this process we separate the graph into two sets: encryption fragments that are selected for the encryption and plaintext fragments that remain in the original graph (Giereth, 2005). The selection task itself can be done with different methods. We can explicitly list the encryption fragments. This approach is called static selection. Furthermore, we can use dynamic selection for which we define a selection pattern that automatically selects all relevant fragments (see Encryption Policies (Giereth, 2005)). A random selection where we randomly select fragments is also conceivable. (Gerbracht, 2008Giereth, 2005)

Segment Encryption This step in the encryption process is very straightforward. We serialize the fragments selected in the previous step and encrypt them using common encryption methods as presented in section Encryption (Gerbracht, 2008Giereth, 2005). The result of this step is an EC containing encrypted data and encryption metadata.

Encryption Graph Transformation In this step we replace all selected fragments with their corresponding EC. As described earlier, XML literals are only allowed as objects. Graph Transformations are required to get a well-formed graph. We already described the schema for graph transformations in Section Graph Transformations.
After performing all graph transformations, we get a single self-describing RDF-compliant graph containing encrypted data, encryption metadata and plaintext fragments (Gerbracht, 2008Giereth, 2005).

Decryption Process of Partially Encrypted RDF Graphs

The decryption process includes three steps: encryption container identification, segment decryption, and decryption graph transformations.

Encryption Container Identification We identify and extract all ECs with the encryption metadata. An RDF query language can be used for this purpose. (Giereth, 2005Gerbracht, 2008)

Segment Decryption We decrypt the extracted ECs according to the specifications in the encryption metadata. This step is only possible with the correct decryption key. The decryption process can fail with an incorrect key.

Decryption Graph Transformation We reconstruct the original RDF Graph by replacing the ECs with the corresponding plaintext values. Afterwards we can perform the inverse graph transformations of the transformation step in the encryption process. If all ECs are decrypted successfully, the new graph is identical to the original graph before encryption. If some ECs failed to decrypt, those encrypted data remain in the new graph. (Gerbracht, 2008Giereth, 2005)

Characteristics

A partially encrypted RDF Graph as presented has the following characteristics, among others. Additional characteristics depend on the chosen cryptographic methods.

Label Information The label information of the selected segments is hidden due to the encryption of the label content.

Structural Information Hiding structural information is possible but requires some effort. The presented encryption solution is a dependency preventing encryption and thus leaks information about the encrypted data (Giereth, 2005). It allows guessing of the plaintext data. There are some solutions for this problem, such as a Dependency Destroying Encryption presented by Gerbracht in (Gerbracht, 2008). These approaches take multiple encryption steps depending on the number of statements the elements are part of. These approaches produce much overhead, but increase the privacy protection capabilities (Gerbracht, 2008).

RDF Compliance The result of the encryption process is RDF compliant (Gerbracht, 2008Giereth, 2005).

Encryption Overhead The resulting graph after encryption is larger than the original graph because additional statements are inserted during the encryption process (Gerbracht, 2008Giereth, 2005). Gerbracht (Gerbracht, 2008) presents a method that uses URIs to optimize the presented method. With the adapted method, only one new statement is created per selected element. The encryption overhead is reduced to a minimum.

Information Leakage due to Ontologies Semantic Web applications often use ontologies. This is also the case for RDF graphs (Gerbracht, 2008Giereth, 2005"RDF/XML Syntax Specification", 2004). An ontology is a schema containing classes, instances, properties, data types, cardinalities and more (Giereth, 2005).
An ontology provides lots of information about the domain of an RDF Graph and thus can be used for attacks. For example, an attacker who tries to guess the plaintext just has to check all values provided by the corresponding ontology. (Giereth, 2005)

Data Integrity Additional security methods such as checksums using hash functions can be used for data integrity checks (Giereth, 2005).

Access Anyone with access to the graph can access all non-sensitive plaintext data. Only authorized individuals can access encrypted data by decrypting the corresponding fragments.

Working with the Data After encryption, it is still possible for everyone to work on the non-encrypted data. The encrypted fragments can be decrypted by authorized individuals if necessary to access this information.

Discussion

Both solution approaches presented in this article – full encryption and partial encryption – can hide both types of information: label information and structural information.

The full encryption process offers privacy that depends only on the cryptographic methods used. The complete data is protected by the encryption. The data can only be used to a very limited extent: The data set must be accessed and decrypted completely, even if only one piece of information is needed. Added value from the information – sensitive as well as non-sensitive – is reserved for authorized individuals only.

The partial encryption process can protect sensitive parts of the graph and still allow one to work with the partially encrypted graph. The strength of the encryption itself depends on the applied cryptographic methods. Independent of the cryptographic algorithm, partially encrypted graphs can reveal some information about their structure. The process always produces an overhead, independent of the cryptographic methods used, since additional elements are inserted into the graph. The partial encryption process is more complex than the full encryption. One consequence of this is that it potentially provides more sources of failure. There is a risk that sensitive data remains in the graph as plaintext. The selection of the right elements for encryption is the main challenge to ensure that no information is leaked unintentionally. Extended selection rules can be used for the partial encryption process. Such selection rules describe what statements have to be encrypted when a specific element is selected to gain a higher level of security (Gerbracht, 2008Giereth, 2005). The risk of sensitive data remaining as plaintext in the graph can thus be reduced to a minimum. However, it cannot be completely eliminated. With this condition in mind and with regard to the information derived from the structure, it can be stated: With partially encrypted graphs, there always remains a certain risk of unintentional information leakage.

Conclusion and Outlook

The approaches presented in this article are above all a tradeoff between maximal privacy and the ability to still work on the data. As so often, the question of which method is better depends completely on the system requirements: If sensitive data is to be protected at all costs, complete data encryption is to be preferred. If concepts of the Semantic Web are the more important aspects, partially encrypted graphs can offer a suitable solution.

An important feature of the Semantic Web is the ability to merge distributed data and re-use data. This is hard to accomplish on fully encrypted data. A solution where only sensitive data is encrypted and non-sensitive data as well as non-critical data derived from encrypted data is still available for processing is desirable. The partial encryption process is such a solution approach. Everybody can work on non-encrypted parts of the graph, and further concepts can be applied in order to provide the ability to work on the masked data. Advanced methods as presented in (Kepner et al., 2014) use sparse linear algebra of associative arrays to enable work on the masked data itself without having to decrypt the data. Analyzing encrypted data to gain knowledge offers a lot of potential for the Semantic Web.

The complete encryption of RDF graphs does not require other concepts apart from the cryptographic methods. A lot of research is being done in the field of cryptography. Partially encrypted RDF graphs offer many advantages. Much can still be researched in this direction until the disadvantages of the methods are reduced to a minimum.

Ultimately, a system should always strive for a state of optimal privacy. This is necessary to best serve the interests of society: Protecting the privacy of individuals while enabling general progress through knowledge gain.

References

• Bartel, M.; Boyer, J.; Fox, B.; LaMacchia, B.; Simon, E. (2013). XML Signature Syntax and Processing Version 1.1. W3C Recommendation. Retrieved from https://www.w3.org/TR/xmldsig-core/ Accessed: 2018-04-25.
• Berners-Lee, T.; Fielding, R.; Masinter, L. (2005). Uniform Resource Identifier (URI): Generic Syntax. RFC 3986.
• Carroll, J. (2003). Signing RDF Graphs. In (Fensel, Dieter; Sycara, Katia; Mylopoulos, John, eds): The Semantic Web - ISWC 2003. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 369–384.
• Dolev, D.; Yao, A. (1983). On the security of public key protocols. IEEE Transactions on Information Theory, 29(2):198–208.
• FOAF Vocabulary Specification 0.99. (2014). Retrieved from http://xmlns.com/foaf/spec/ Accessed: 2018-04-20.
• Gerbracht, S. (2008). Possibilities to Encrypt an RDF-Graph. In: 2008 3rd International Conference on Information and Communication Technologies: From Theory to Applications. pp. 1–6.
• Giereth, M. (2005). On Partial Encryption of RDF-Graphs. In: The SemanticWeb – ISWC 2005. Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 308–322.
• Imamura, T.; Dillaway, B.; Simon, E.; Yiu, K.; Nyström, M. (2013). XML Encryption Syntax and Processing Version 1.1. W3C Recommendation. Retrieved from https://www.w3.org/TR/xmlenc-core/ Accessed: 2018-04-25.
• Kepner, J.; Gadepally, V.; Michaleas, P.; Schear, N.; Varia, M.; Yerukhimovich, A.; Cunningham, R. K. (2014). Computing on masked data: a high performance method for improving big data veracity. In: 2014 IEEE High Performance Extreme Computing Conference (HPEC). pp. 1–6.
• National Institute of Standards and Technology (NIST). (1999). Data Encryption Standard (DES). Technical Report. Retrieved from https://csrc.nist.gov/csrc/media/publications/fips/46/3/archive/1999-10-25/documents/fips46-3.pdf Accessed: 2018-04-25.
• National Institute of Standards and Technology (NIST). (2001). Advanced Encryption Standard (AES). Technical Report, November 2001. Retrieved from https://csrc.nist.gov/csrc/media/publications/fips/197/final/documents/fips-197.pdf Accessed: 2018-04-25.
• National Institude of Standards and Technology (NIST). (2015). Secure Hash Standard (SHS). Technical Report, August 2015. Retrieved from https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf Accessed: 2018-04-25.
• W3C. (2012). OWL 2 Web Ontology Language Document Overview (Second Edition). Retrieved from https://www.w3.org/TR/owl2-overview/, 2012. Accessed: 2018-04-20.
• W3C. (2004). RDF Primer. W3C Recommendation, February 2004. Retrieved from https://www.w3.org/TR/rdfprimer/Accessed: 2018-04-25.
• W3C. (2004). RDF/XML Syntax Specification. W3C Recommendation, February 2004. Retrieved from https://www.w3.org/TR/REC-rdf-syntax/ Accessed: 2018-04-20.
• W3C. (2014). RDF Resource Description Framework (RDF). Retrieved from https://www.w3.org/RDF/, February 2014. Accessed: 2018-04-20.
• Rivest, R. (1992). The MD5 Message-Digest Algorithm. Technical Report, April 1992. Retrieved from http://www.faqs.org/rfcs/rfc1321.html Accessed: 2018-04-25.
• Rivest, R. L.; Shamir, A.; Adleman, L. (1978). A Method for Obtaining Digital Signatures and Public-key Cryptosystems. Commun. ACM, 21(2):120–126.