Quad Store Configuration¤

Virtuoso setup¤

This section covers only setup options which have a direct impact on the interoperability between DataPlatform and Virtuoso. There are far more options which can significantly improve the overall performance. For an overview of all configuration files and options of Virtuoso refer to the document Database Server Administration of the official product documentation. Ensure to add the suggested parameters to the corresponding subsections of the configuration file before starting the server.

Compatibility¤

• Virtuoso 7.2.4.2 - DataPlatform is compatible with Virtuoso 7.2.4.2. Compatibility with other versions is not guaranteed.

Configuration¤

The following options apply to the Virtuoso configuration file virtuoso.ini. Check these options before starting DataPlatform and adjust them if necessary.

SSL support¤

Mandatory configuration if sparqlEndpoints.virtuoso[i].sslEnabled=true. The server must have a valid certificate, which must be trusted by the system where DataPlatform runs. In this case, the sparqlEndpoints.virtuoso[i].port property must point to the SSLServerPort.

[Parameters]
SSLServerPort      = 2111
;; Make sure that <PATH_TO_CERTS_DIR> is contained by DirsAllowed
SSLCertificate     = <PATH_TO_CERTS_DIR>/public-cert.pem
SSLPrivateKey      = <PATH_TO_CERTS_DIR>/private-key.pem

Transaction size limit (optional)¤

This option has impact on the maximum file size which can be uploaded using the SPARQL Graph Store endpoint and executing update queries.\ The maximum value you can set this option to is 2147483000 bytes.

[Parameters]
TransactionAfterImageLimit = <size_limit_in_bytes> # default 50000000

Database buffers¤

These options determine the amount of RAM used by Virtuoso to cache database files. To choose the appropriate values consult the virtuoso.ini file.

[Parameters]
NumberOfBuffers          = <size>
MaxDirtyBuffers          = <size>

ResultSet max rows¤

This setting is used to limit the number of the rows in a result. The effective limit is the lowest of this setting and the SPARQL query LIMIT clause value (if present). The exact value is situation-related and depends on the size of the datasets and the consequential number of returned rows. We recommend to set this option to 0 to disable the limitation.

[SPARQL]
ResultSetMaxRows = 0 # default 10000

Stardog setup¤

This section covers only limitations and options which have a direct impact on the interoperability between DataPlatform and Stardog. For an overview of all configuration options of Stardog refer to the official Stardog documentation. Ensure to add the parameters explained in this section to the stardog.properties configuration file before starting the server.

Compatibility ¤

• Stardog 7.2.1 -DataPlatform is compatible with Stardog version 7.1.1. Compatibility with newer versions is not guaranteed.
• Stardog 6.2.3 (deprecated) - DataPlatform is compatible with Stardog version 6.2.3.

!!! note Support for 6.2.3 is deprecated and will be removed in later DataPlatform releases.

Configuration ¤

• Search enabled\ DataPlatform relies on the Stardog Semantic Search, which has to be enabled by setting:
• search.enabled=true\ You can set this property using either Stardog Studio or the stardog-admin commands.\ Refer to the Stardog documentation for more detailed information.
• Server side named graph security\ If the PROVISIONED access control strategy is used for the configured endpoint, you have to set the property security.named.graphs=true for the configured database as explained in the Stardog documentation. Furthermore, the following properties are also required:
• password.length.max: For the provisioned mode to work properly. This property should have a value of at least 64.

• password.regex: The default value configured in Stardog is not compatible with the passwords generated by DataPlatform. The regex should be [\\w+\\/=]+

• SSL support\ Mandatory configuration if sparqlEndpoints.stardog[i].sslEnabled=true. The server must have a valid certificate, which must be trusted by the system where DataPlatform runs. In this case, the sparqlEndpoints.stardog[i].port property must point to the SSL port (whose default value is 5821).\ Consult the Configuring Stardog to use SSL section of Stardog’s manual for more information on the topic.

• Query timeout override\ In order to allow DataPlatform to override the query timeout for individual queries, you have to ensure that the property query.timeout.override.enabled is set to true for the database (which is the default).\ Consult the Configuring Query Management section of Stardog’s manual for further information.

Limitations¤

• Quad format upload\ The Graph Store Protocol implementation for Stardog does not support uploading of RDF quad data (TriG, N-Quads).
• Initial connection\ The first request to DataPlatform can take up to several seconds due to connection startup to the Stardog server.

Caveats¤

Datatype canonicalization¤

By default Stardog performs canonicalization of XSD integer datatypes as explained in the Stardog documentation. That means the datatype of all literals declaring a sub-datatype of xsd:integer is generalized on load or insert:

For example, when ingesting the following RDF data

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

xsd:long <urn:example:value> "42"^^xsd:long .
xsd:int <urn:example:value> "42"^^xsd:int .
xsd:short <urn:example:value> "42"^^xsd:short .
xsd:byte <urn:example:value> "42"^^xsd:byte .
xsd:nonNegativeInteger <urn:example:value> "42"^^xsd:nonNegativeInteger .
xsd:positiveInteger <urn:example:value> "42"^^xsd:positiveInteger .
xsd:nonPositiveInteger <urn:example:value> "-42"^^xsd:nonPositiveInteger .
xsd:negativeInteger <urn:example:value> "-42"^^xsd:negativeInteger .
xsd:unsignedLong <urn:example:value> "42"^^xsd:unsignedLong .
xsd:unsignedInt <urn:example:value> "42"^^xsd:unsignedInt .
xsd:unsignedShort <urn:example:value> "42"^^xsd:unsignedShort .
xsd:unsignedByte <urn:example:value> "42"^^xsd:unsignedByte .

in a Stardog database with index.literals.canonical set to true (default), it will be stored as

@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

xsd:long <urn:example:value> "42"^^xsd:integer .
xsd:int <urn:example:value> "42"^^xsd:integer .
xsd:short <urn:example:value> "42"^^xsd:integer .
xsd:byte <urn:example:value> "42"^^xsd:integer .
xsd:nonNegativeInteger <urn:example:value> "42"^^xsd:integer .
xsd:positiveInteger <urn:example:value> "42"^^xsd:integer .
xsd:nonPositiveInteger <urn:example:value> "-42"^^xsd:integer .
xsd:negativeInteger <urn:example:value> "-42"^^xsd:integer .
xsd:unsignedLong <urn:example:value> "42"^^xsd:integer .
xsd:unsignedInt <urn:example:value> "42"^^xsd:integer .
xsd:unsignedShort <urn:example:value> "42"^^xsd:integer .
xsd:unsignedByte <urn:example:value> "42"^^xsd:integer .

If data is to be copied between CMEM setups backed by Stardog, the index.literals.canonical options of the corresponding databases must be set to the same value on both setups.

It is recommended to only turn this canonicalization off when it is strictly necessary, due to a negative impact on database performance without it.

GraphDB setup¤

This section covers only limitations and options which have a direct impact on the interoperability between DataPlatform and GraphDB. For an overview of all configuration options of GraphDB refer to the official GraphDB documentation.

Compatibility ¤

• GraphDB 9.2.0 - DataPlatform is compatible with GraphDB version 9.2.0. Compatibility with newer versions is not guaranteed.

Configuration ¤

No specific configuration changes are needed in order to run with GraphDB.