There are cases where it is desirable to have IRI's in RDF
storage that will change to reflect a change of the host name of
the containing store. This is specifically true of DAV resource
metadata for local DAV resources. Such IRI's must be stored
prefixed with local: .
If a user application makes statements with such a URI, then
these statements will be returned with local: substituted with a
prefix taken from the context as described below.
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 URIQA. This behavior is always in effect.
When converting strings to IRI id's, the local: prefix may or may not be introduced
depending on ini file and other context factors. If DynamicLocal defined in the
[URIQA] section of the Virtuoso INI file 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 id, the translating
the IRI_ID back to the IRI name will depend on the context as
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 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. Also be careful when loading RDF
files that may have URI's corresponding to the local host name.