Solving Compatibility Issues with AllegroGraph

[eltonfss]

1. Changing default xsd type for non-integer numbers to decimal (from double)

Motivated by the recently detected differences between the number of decimal cases supported for double XSD in Jena Fuseki and AllegroGraph, as well as several external references that point towards the more general nature the decimal XSD, I propose we change the default serialization of non-integer numbers (frequently present in properties of an HKEntity) to decimal XSD.

External references:

• Why xsd:double? Why not xsd:decimal? w3c/json-ld-syntax#318
• https://stackoverflow.com/questions/26909331/what-are-the-limits-of-the-decimal-type-in-xml-schema-xsd
• https://www.ibm.com/docs/en/jfsm/1.1.2.1?topic=queries-xsd-data-types
• https://www.w3schools.com/xml/schema_dtypes_numeric.asp
• https://franz.com/agraph/support/documentation/current/datatypes.html
• https://stackoverflow.com/questions/17073781/allegrograph-xsd-float-literals

OBS: I'm considering this to be a major release as it introduces a potentially (but not necessarily) breaking change.

2. Adding automatic unescaping of literals objects in JSONGraph

As detected in recent tests with Jena Fuseki and AllegroGraph, some literals with escaped double quotes were being retrieved unescaped in Jena's configuration and escaped in AllegroGraph's configuration. The main reason for this is that our TrigGraph implementation (based on N3.js library) that automatically unescapes literals stored in objects (such as JSON stored within a literal) was being used when retrieving SPARQL query results from Jena (which were in application/trig format), while in AllegroGraph's configuration is was not. This occurred because AllegroGraph retrieved the results in application/json format, forcing the usage of our JSONGraph implementation, that does not perform automatic unescaping (since it is not based on N3.js library), instead of the TrigGraph implementation.

As we could not find the list of supported SPARQL response mime types in AllegroGraph's HTTP Reference we tried using "application/trig", "application/n-quads", and "text/turtle" (which could be parsed with the TrigGraph) . For all of those, AllegroGraph retrieved an error response with 406 status code and an error message similar to the following:

No suitable response format available for row-cursor. Your request accepts: text/turtle. Supported formats are: application/json, application/processed-csv, application/sparql-results+json, application/sparql-results+json-rows, application/sparql-results+ttl, application/sparql-results+xml, application/sparql-results+xml-rows, application/x-ag-binary-rdf, application/x-direct-upis, application/x-lisp-structured-expression, text/csv, text/csv-rows, text/integer, text/simple-csv, text/tab-separated-values, text/tab-separated-values-rows, text/table.

We've also tried using the application/sparql-results+ttl mime type, which seemed to be similar to "text/turtle" (although it has not been explicitly mentioned SPARQL Protocol Specification) and parse the results as a TrigGraph pretending that it was in "text/turtle" format. Unfortunately this did not work and we had to pursue a different solution.

Therefore, to maintain this behavior (of automatic unescaping) when using AllegroGraph, we reproduced part of the unescaping logic present in the N3.js library (used by the TriGraph) within our JSONGraph implementation.

3. Handling redundant escaping of quotes in AllegroGraph

During our tests, we also detected that some literals contained redundant escaping of double quotes and, to properly handle those cases, the unescapeLiteral method implemented in JSONGraph needed to be refactored to perform as many unescapes where necessary to produce a completely unescaped string. Nonetheless, this also required that we added an additional treatment in the updateTriples method the SPARQLFactory class, to properly escape those literals when generating INSERT DATA clauses of a SPARQL update query.