Usage of the Sponger Middleware via REST patterns
What?
How to interact with the Sponger via REST patterns.
Why?
Delegation and proxies are part of the Internet and Web's federated architecture. Thus, developers of RESTful applications benefit immensely from the ability to leverage Sponger functionality via delegation to it as a proxy.Two proxies are available: /about (deprecated) and /describe. /about provides a simple RDF browsing interface, /describe exposes a functionally richer faceted browser.
How?
The following table presents list of the supported URL parameters:
Parameter | Value | Description | Example |
---|---|---|---|
sponger:get | soft | Use: Add triples only if the target graph is initially empty Network Resource Fetch data subject to the cache invalidation policies and associated rules of instance. May be used together with refresh=<seconds> to override the default cache expiration. |
Network Resource Fetch data with option soft and refresh on every 10 seconds /describe /about |
sponger:get | replace | Use: When adding new triples, overwrite existing triples with the same subject and predicate Replace subject to cache invalidation policy and rules, but coverage includes non fetched triples if such exist in a given named graph. may be used together with refresh=<seconds> to override the default cache expiration. |
Replace data and refresh on every 10 seconds /describe /about |
sponger:get | add | Use: When adding new triples, do not overwrite existing triples with the same subject and predicate Add new triples to named graphs, progressively. This is the default value for the parameter sponger:get . May be used together with refresh=<seconds> to override the default cache expiration (which is based on a cache expiry date/time calculated from information in the HTTP headers returned from a previous sponge of the target data source). |
Add new triples and refresh on every 10 seconds /describe /about |
sr (/describe) refresh (/about) |
clean | Use: Clear the target graph before sponging The 'clean' usage explicitly clears the target graph i.e. will cause the Sponger to clear it's cache even if it is marked to be in use. Thus, if the fetch cache is for some reason left in an inconsistent state, for instance by a shutdown during Network Resource fetching, then 'clean' is required as it doesn't check the cache state beforehand. Note: * must be used with caution as other threads may be doing fetching of network resources at same time. * refresh must be used in tandem with @Lookup@ i.e. &@Lookup@=&refresh=clean |
Explicitly clear the graph /describe /about |
Related
- Sponger Queue API?
- Technical White Paper
- Supported Virtuoso Sponger Cartridges?
- SPARQL Sponger?
- Virtuoso Linked Data Middleware REST Patterns
- Parametrized Examples of Meta Cartridge Usage via REST Request?
- Sponger Cartridge RDF Extractor?
- Extending SPARQL IRI Dereferencing with RDF Mappers?
- Programmer Guide for Virtuoso Linked Data Middleware ("Sponger")?
- Create RDF Custom Cartridge Tutorial?
- OpenLink-supplied Virtuoso Sponger Cartridges?
- Virtuoso Authentication Server?
- Virtuoso SPARQL OAuth Tutorial
- Virtuoso Sponger Access Control List (ACL) Setup?
- WebID Protocol & SPARQL Endpoint ACLs Tutorial?
- Virtuoso Documentation