19.2.3.URIQA Section in Virtuoso Configuration File
By default,the Virtuoso server acts only as URIQA proxy, i.e. it redirects incoming requests to other servers without trying to return metadata about DAV resources or other data stored on the server itself. To let URIQA retrieve local metadata, the Virtuoso server should know names that can be used by clients to access it. Virtuoso configuration file, e.g., virtuoso.ini, can contain these names as parameters in "[URIQA]" section
| "DefaultHost" is the "canonical" server name that is used to identify the service. It should be either server name including domain name, or an IP address in standard notation, if the server does not have any name. If Virtuoso default HTTP port is not equal to 80 then the port should be mentioned, e.g. "www.example.com:8088". |
| "LocalHostNames" lists all names that can be used to access the server, such as server names with and without domain name, IP addresses in Internet and intranets etc. The list is comma-delimited string of names. If an URIQA client can reside on server's box, e.g. for debugging purposes, then it may be worth to add names "localhost, localhost.localdomain, 127.0.0.1" to this list. |
| "LocalHostMasks" is similar to "LocalHostNames" but it lists patterns for names in SQL "like" operator style. If Virtuoso listens at multiple ports and it is the only URIQA enabled service on the machine then it can be convenient to specify "LocalHostMasks = www.example.com:%" instead of "LocalHostNames = www.example.com:8088, www.example.com:8089, www.example.com:8090 ...". |
| "Fingerprint" is a string that identifies a group of servers that shares same metadata, such as servers that replicate each other. It is an error if two servers have the same fingerprint string and one of them tries to redirect a URIQA request to another instead of prepare an response locally. Such behavior indicates configuration error, and the use of fingerprints help administrator to get a meaningful diagnostics, because suspicious URIQA requests become signed by all intermediate Virtuoso proxies. If this parameter is not specified then a random unique string is created and stored in the database, so you don't have to specify this parameter for typical installations. |
"DynamicLocal" is a flag (1 or 0), when it is on and the host
part of the IRI matches the Host header of the HTTP request in
context or the DefaultHost if outside of HTTP context, then this is
replaced with local: before looking up the IRI ID. Even if
DynamicLocal is not on and the local: prefix occurs in the IRI string
being translated to IRI_ID, the translating the IRI_ID back to the
IRI name will depend on the context as described as follows: When
returning IRI's from id's, this prefix is replaced by the Host
header of the HTTP request and if not running with HTTP, with the
DefaultHost from this section. The effects of DynamicLocal = 1 can
be very confusing since many names can refer to the exact same
thing. For example, if the DefaultHost is http://dbpedia.org,
iri_to_id
('http://dbpedia.org/resource/Paris') = iri_to_id
('local:///resource/Paris) is true and so is 'http://dbpedia.org/resource/Paris' = id_to_iri
(iri_to_id ('local:///resource/Paris')) These hold in a SQL
client context, i.e. also when connected through RDF frameworks
like Jena or Sesame. When running a SPARQL protocol request, the
Host: header influences the behavior, likewise when using web
interactive SQL in Conductor. |
These configuration parameters are "sticky". If they're found in configuration file then they are preserved in the database registry. If configuration file has changed then new values will be used after server restart. If database dump is replayed on a server whose configuration file does not contain these parameters then values from dump will stay in the registry. If database dump is replayed on a server whose configuration file contains other values then values from dump will stay in the registry till server restart.