Skip to content

Quad Store Configuration¤

Virtuoso setup¤

This section only covers setup options that 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 for this option 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 rows in a result. The effective limit is the lowest value 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 only covers 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. Make sure to add the parameters described 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. Additionally, the following properties are 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 (which 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 for the database is set to true (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 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 that the datatype of all literals declaring a sub-datatype of xsd:integer is generalized on load or insert:

original datatype of literal new datatype of canonicalized literal
xsd:int xsd:integer
xsd:short xsd:integer
xsd:byte xsd:integer
xsd:nonNegativeInteger xsd:integer
xsd:positiveInteger xsd:integer
xsd:nonPositiveInteger xsd:integer
xsd:negativeInteger xsd:integer
xsd:unsignedLong xsd:integer
xsd:unsignedInt xsd:integer
xsd:unsignedShort xsd:integer
xsd:unsignedByte xsd:integer

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.

Comments