Virtuoso SPARQL LOAD Service


Using SPARQL LOAD service to get remote endpoint's description.


Provides additional data that might be useful such as: if a local server knows what syntax extensions are supported by the remote SPARQL endpoint for ex.: then it can improve the compilation of SPARQL queries that contain clauses like:

SERVICE <> {...} .


To get the description of remote endpoint, one should run the following statement at its local server:


The retrieved description will be stored in local RDF storage as a part of " System Metadata" graph , so the user calling this statement should have appropriate write permissions.


  1. Suppose the following query:

    INSERT INTO <> { ?s owl:sameAs ?o. } WHERE { GRAPH <> { ?s rdf:type skos:Concept.} SERVICE <> { SELECT ?o WHERE { ?s <> ?o . FILTER REGEX(str(?o), "^") . } LIMIT 10 } }

  2. Next we will bound the ?s in the graph part and the ?s in the scope of the service part: For every concept ?s in the graph <> we want to retrieve the owl:sameAs elements in the service <> , so for ex:
    • Locally there is the following triple:

      { dbpedia:A a skos:Concept }

    • In dbpedia there are the following triples:

      { dbpedia:B owl:sameAs dbpedia:C. dbpedia:A owl:sameAs dbpedia:D. }

    • The expected result we want to be:

      { dbpedia:A owl:sameAs dbpedia D. }

  3. The simplest way to make ?s interrelated is to alter the select statement and to add ?s into its result set:

    INSERT INTO <> { ?s owl:sameAs ?o. } WHERE { GRAPH <> { ?s rdf:type skos:Concept.} SERVICE <> { SELECT ?s ?o WHERE { ?s <> ?o . FILTER REGEX(str(?o), "^") . } LIMIT 10 } }

  4. The change will affect to the following:
    1. ?s from service and ?s from graph <> {} will both appear at the same scope and the equality between them will be required by the semantics.
    2. The optimizer will understand that it's better to pass the ?s as parameter to the service instead of selecting all pairs of ?s and ?o and filter them at the main query server.
    3. The code generator will try to write a code for sending a query to but it may fail if it are not known the capabilities of SPARQL compiler at , so before the first compilation, one should execute the following statement:


      • The effect of executing the SPARQL LOAD SERVICE statement will be:
        1. Recognize what syntax extensions are supported by the compiler inside service endpoint. E.g., whether that endpoint can deal with external parameters.
        2. Will write small description of the endpoint to local metadata but will not try to copy any data stored remotely to the local storage.
  5. Important Note: that if the graph <> { ?s rdf:type skos:Concept.} will produce many values for ?s, there will be many requests to dbpedia, and the sum of round-trip latencies will be high. In some cases it may be faster to get one big list of ?s ?o pairs from dbpedia and then search in local graph. To change the order of execution to "remote first" variant, the order of clauses should be changed to:

    INSERT INTO <> { ?s owl:sameAs ?o. } WHERE { SERVICE <> { SELECT ?s ?o WHERE { ?s <> ?o . FILTER REGEX(str(?o), "^") . } LIMIT 10 } GRAPH <> { ?s rdf:type skos:Concept.} }