RDF Cartridges (RDF Mappers or RDFizers)
RD-S-1 RDF Cartridges
This article explains how to develop and test a custom RDF Cartridge.
Concept
RDF cartridges provide a modular approach to RDF oriented entity extraction and ontology mapping as part of a Linked Data production pipeline. Typical sources include (X)HTML pages, images, Office documents and PDF documents amongst others.
Cartridges expose their functionality to service consumers via the Virtuoso Sponger ("Sponger"), a middleware layer that extracts and delivers RDF to other Virtuoso components such as the Web Crawler and SPARQL Query Process. In addition it is directly exposed as a REST-style Web Service for external applications and services to exploit.
A Cartridges is comprised of an initialization PL procedure (hook) and an entity extractor and mapper. The entity extractor and mapping component can be developed using PL, C or any external language supported by Virtuoso via the Virtuoso Server Extensions APIs.
Once the cartridge has been developed, it is plugged into the Virtuoso Sponger by adding a record to the table DB.DBA. DB.DBA.SYS_RDF_MAPPERS.
How Cartridges Work:
SPARQL Query Processing
When a SPARQL query is dispatched to Virtuoso, it invokes the Sponger during the act of graph or resource URI dereferencing i.e. it actually crawls the Web, locates a resource via it's URI/IRI (using a variety of RDF discovery heuristics), and then differences the data that the URI exposes. If RDF is discovered, the cartridges play no role. On the other hand, if RDF isn't discovered the Sponger will look in the DB.DBA.SYS_RDF_MAPPERS table (in RM_ID order), and for every matching URI or MIME type pattern (depending on RM_TYPE column value) it will invoke the associated cartridge by invoking the hook procedure. If the hook returns zero the next cartridge will be tried. If the result is negative the process stops, instructing the SPARQL engine that nothing was retrieved. If the result is positive the process stops, this time instructing the SPARQL engine that RDF data was successfully retrieved.
PL hook requirements
Every PL function used to plug a cartridge into the SPARQL engine must have the following parameter signature:
- in graph_iri varchar: the local storage graph IRI
- in new_origin_uri varchar: target information resource URI
- in destination varchar: the target graph IRI
- inout content any: the content of the information resource retrieved for dispatch to the Sponger
- inout async_queue any: an asynchronous queue, can be used for background processing (if required)
- inout ping_service any: the value in the [SPARQL] section of a Virtuoso instance (i.e PingService? INI parameter) which is enables RDF triple propagation and notification to pinger services such as http://pingthesemanticweb.com
- inout api_key any: a plain text id single key value or serialized vector of keys, basically the value of RM_KEY column of the DB.DBA.SYS_RDF_MAPPERS table, which is used for handling of API keys for 3rd party Web Services.
Note: the names of the parameters are not important, but their order and presence are vital.
Implementation
In the example script we implement a basic cartridge which maps a text/plain mime type to an imaginary ontology, which extends the class Document from FOAF with properties 'txt:UniqueWords?' and 'txt:Chars', where the prefix 'txt:' we specify as 'urn:txt:v0.0:'.
To test the cartridge we just use /sparql endpoint with option 'Retrieve remote RDF data for all missing source graphs' to execute:
select * from <URL-of-a-txt-file> where { ?s ?p ?o }
It is important that the SPARQL_SPONGE role needs to be granted to "SPARQL" user account (or any other account bound to SPARQL functionality) in order to enable persistence to local storage.
If the above is set correctly then you can just hit this link.
More complex examples can be found in the rdf_cartridges package implementation.
| View the source | Action |
|---|---|
| 1. rd_s_1.sql | Set the initial state |
OpenLink Home
Technical Support