{'fraction_non_alphanumeric': 0.028070175438596492, 'fraction_numerical': 0.021052631578947368, 'mean_word_length': 4.449044585987261, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Revisiting Blank Nodes in RDF to Avoid the Semantic Mismatch with SPARQL

Jointly with the release of RDF in 1999 as recommendation of the W3C, the natural problem of querying RDF data was raised. Since then, several designs and implementations of RDF query languages have been proposed (see [9] and [7] for detailed comparisons of RDF query languages). In 2004, the RDF Data Access Working Group released a first public working draft of a query language for RDF, called SPARQL [13]. Since then, SPARQL has been rapidly adopted as the standard for querying Semantic Web data. In fact, SPARQL became a W3C Recommendation in January 2008. In spite of being the standard query language for RDF, the design of SPARQL was made to keep the efficiency of the language considering the current database technology. In this direction, the current definition of the semantics of SPARQL does not consider the combined treatment of two of the distinctive features of RDF graphs, namely the semantics of blank nodes and RDFS vocabulary recommended by the W3C in the definition of RDF [10]. In fact, the semantics of SPARQL does not match in some constructions the semantics for blank nodes recommended by the W3C in [10]. To see that this is the case, consider the RDF graphs G1 and G2 shown in Figure 1. In these graphs, :b1, :b2 and :b3 are blank nodes, which are used to represent objects that are owned by John and Peter. According to the semantics for blank nodes proposed by the W3C [10, 8], these two graphs are equivalent as they can be mapped into each other . Thus, one would expect that the answer to any SPARQL query over G1 is the same as over G2. However, this is not the case for the following SPARQL query Q: