Download Virtuoso_Deploying_Linked_Data210409

OpenLink Virtuoso – Linked Data
Deploying Linked Data
© 2009 OpenLink Software, All rights reserved
Linked Data
 Term coined by Tim Berners-Lee
 Describes recommended best practice for exposing & connecting data
on the Semantic Web
 Use the RDF data model
 Identify real or abstract things (resources) in your ‘universe of
discourse’ (Data Spaces), using URIs as unique IDs
 Make URIs accessible via HTTP so people can discover and
explore these Data Spaces
 Allow these URIs to be dereferenced and return information
 Include links to provide ‘discovery paths’ to entities in other Data
Spaces
© 2009 OpenLink Software, All rights reserved
Deployment Challenges
Semantic ‘Data Web’ vs Traditional ‘Document Web’
 These are two dimensions of the Web separated by a
common element – the URI
 Document Web
 URIs always point to physical resources (they are URLs)
 Data Web
 URIs Identify physical or abstract resources
 URIs for the Document and Data Webs must be interpreted
differently
© 2009 OpenLink Software, All rights reserved
Web Resources
 What do we really mean by the term ‘resource’?
 The ‘Traditional’ and Semantic Webs require subtly different
interpretations
© 2009 OpenLink Software, All rights reserved
Document Web Resources
In the traditional Document Web:
 All resources are document-orientated
 URI dereferencing returns a document
 Rendered representation is nearly always a document
 No real distinction between a resource and its
representation
 Such resources have been referred to as ‘information
resources’
© 2009 OpenLink Software, All rights reserved
Semantic Web Resources
In the Semantic Web:
 A URI identifies a thing (piece of data) in a data space
 The identity of a thing is distinct from its address and representation
 things may have several possible representations
 the most desirable representation of a thing may change, depending
on the consumer (human or software-agent)
 things may be associated with data at different addresses within a
data space
 Unfortunately, URIs identifying things are generally referred to as ‘noninformation resources’ in W3C parlance
 Entity or Object IDs, or Data Source Names, are preferable terms
© 2009 OpenLink Software, All rights reserved
Access vs Reference
 The Semantic and Document Webs interpret the term
‘resource’ differently
A corollary of this difference in interpretation is:
 The Semantic and Document Webs interpret URIs
differently
 Document Web: assumes that a resource URI provides
an address to a document or other resource types
 Semantic Web: a URI simply Identifies a thing – data
access returns a description of the thing/entity, not the
thing/entity itself (e.g. the entity may be Paris)
© 2009 OpenLink Software, All rights reserved
Access vs Reference – Another View
Paraphrasing Pat Hayes’ paper “In Defense of Ambiguity”
 Names (URIs) are used to both refer to (reference) and
access things
 Access should be unambiguous
 A name (URI) should provide an unambiguous access
path
 Reference to abstract (physically inaccessible) entities is
inherently ambiguous
 Referring to an abstract entity relies on describing the
entity
 As there are many possible descriptions (facets),
reference is ambiguous
© 2009 OpenLink Software, All rights reserved
Deployment Challenges
We’ve established that the Semantic Web and Linked Data
require:
 Data access with unambiguous naming
 Data (de)reference with ambiguous association
Or put another way, we need mechanisms for an HTTP server
to:
 Answer the question “Does this URI identify a (physical)
document resource or an (RDF based) abstract
entity/thing?”
 Provide alternative representations of an entity/thing
© 2009 OpenLink Software, All rights reserved
Deployment Challenge Resolution
Two solutions proposed by the SemWeb Community:
 Distinguish resource type through URL formats
 ‘Hash’ vs ‘slash’ URLs
 Content negotiation with URL rewriting
© 2009 OpenLink Software, All rights reserved
‘Hash’ vs ‘Slash’ URLs
 A solution using the syntax of the URL to differentiate
‘abstract’ resources from ‘information’ resources
 Slash URIs
 Don’t contain a fragment identifier (#)
 Identify document resources in traditional Web

E.g. http://demo.openlinksw.com/Northwind/Customer/ALFKI
 Identifies a physical (X)HTML document
 Hash URIs
 Contain a fragment identifier
 Identify data resources (entities) in Semantic Web

E.g. http://demo.openlinksw.com/Northwind/Customer/ALFKI#this
 Identifies the entity ALFKI, distinct from its representation
© 2009 OpenLink Software, All rights reserved
Difficulties with ‘Hash’ URIs
Using ‘hash’ URIs as data object identifiers poses problems…
The fragment identifier ‘#’ may not reach the server:
 Most clients process it locally (for scrolling) and strip it off request URLs
To a Linked Data server the following URLs look identical:
 http://demo.openlinksw.com/Northwind/Customer/ALFKI
 http://demo.openlinksw.com/Northwind/Customer/ALFKI#this
© 2009 OpenLink Software, All rights reserved
Content Negotiation
 Mechanism defined in HTTP specification
 Makes it possible to serve different versions of a document
(or, more generally, a resource) at the same URL
 Software agents can choose which version they want.
 HTML Web browsers prefer HTML/XHTML
 Linked Data browsers prefer RDF/XML
© 2009 OpenLink Software, All rights reserved
Content Negotiation - Example
HTTP Request:
HTML browser requests a HTML/XHTML document in English or French
GET /whitepapers/data_mngmnt HTTP/1.1
Host: www.openlinksw.com
Accept: text/html, application/xhtml+xml
Accept-Language: en, fr
 Accept header indicates preferred MIME types
 RDF browser might instead stipulate a MIME type of
application/rdf+xml or application/rdf+n3
© 2009 OpenLink Software, All rights reserved
Content Negotiation - Example
HTTP Response:
Server redirects to a URL where the appropriate version can be found
HTTP/1.1 302 Found
Location: http://www.openlinksw.com/whitepapers/data_mngmnt.en.html
 Redirect is indicated by HTTP status code 302 (Found)
 Client then sends another HTTP request to the new URL
 HTTP defines several 3xx status codes for redirection
© 2009 OpenLink Software, All rights reserved
HttpRange-14 Recommendations
W3C TAG guidelines for indicating resource type through HTTP response
code (aka the HttpRange-14 issue)
HTTP
Response
Code
Material
Returned
Inference
200
(success)
A resource
representation
Requested resource is an information resource.
A representation has been returned.
303
(see other)
A resource
location (URI)
The resource may be a document (information
resource) or an entity (non-information resource). The
client is being redirected to an associated
representation of the resource in the desired format.
The URI of the associated resource has been returned.
4xx or 5xx
(error)
Nothing
The specified resource or representation format does
not exist.
© 2009 OpenLink Software, All rights reserved
Content Negotiation Decision Table
URI
URI Type
(X)HTML
Representation
Requested
200 OK
RDF
Representation
Requested
http://demo.openlinksw.com
/Northwind/Customer/ALFKI
Slash based
(identifies a
document
resource)
200 (OK) if an HTML
document exists, or
406 (Not available) if
one doesn’t exist
406 (Not available),
or 303 (Redirect) to a
URL which returns an
RDF description of
the entity ALFKI
http://demo.openlinksw.com
/Northwind/Customer/ALFKI
#this
Hash based
(identifies an
entity / object
ID)
303 (Redirect) to
associated HTML
document describing
ALFKI, or
406 (Not available) if
one doesn’t exist
200 (OK) – return an
RDF description of
the entity ALFKI
© 2009 OpenLink Software, All rights reserved
URL Rewriting
 Is the act of modifying a URL prior to final processing by a
Web server
 Provides a means to build a URL ‘on the fly’ identifying the
resource in the required representation format referred to
by a 303 redirection
 Ideal solution is a rules-based URL rewriting processing
pipeline using regular expression or sprintf substitutions
© 2009 OpenLink Software, All rights reserved
URL Rewriting – Example Pipeline
Source URI
(Regex)
HTTP Accept
Header (Regex)
HTTP Response
Code
HTTP Response
Headers Rule
Rule Processing
Order
/Northwind/Custom
er/([^#]*)
None (i.e. default)
200 or 303
redirect to a
resource with
default
representation
None
Normal
(order irrelevant)
/Northwind/Custom
er/([^#]*)
(text/rdf.n3) |
(application/rdf.xml)
303 redirect to a
URL which
DESCRIBEs the
entity identified by
the URI
None
Normal
(order irrelevant)
/Northwind/Custom
er/([^#]*)
(text/html) | (*/*)
406 (Not
acceptable) or
303 redirect to a
URL which can
render the
requested
representation
For 406:
Vary: negotiate,
accept Alternates:
{“ALFKI” 0.9 {type
application/rdf+xml}}
Last
(must be last in
processing chain)
© 2009 OpenLink Software, All rights reserved
Dynamic RDF Renderings
To provide an RDF rendering of the entity being dereferenced
by the client:
Use SPARQL DESCRIBE or CONSTRUCT
 DESCRIBE <entity-uri> FROM <graph-uri>
 ‘Unconstrained’ – DESCRIBE output not prescribed by
SPARQL specification
 Virtuoso supports custom procedures for generating
output through SPARQL define sql:describe-mode
 CONSTRUCT { <entity-uri> ?p ?o } FROM <graph-uri>
WHERE { <entity-uri> ?p ?o }
© 2009 OpenLink Software, All rights reserved
Content negotiation for RDF representation
© 2009 OpenLink Software, All rights reserved
Deploying Linked Data Using Virtuoso
 Virtuoso’s approach is to implement the generic solution
outlined so far, using
 Content negotiation
 URL rewriting
 Virtuoso includes a Rules-based URL Rewriter
 Can be used to inject Linked Data into the Document Web
© 2009 OpenLink Software, All rights reserved
Virtuoso - URL Rewriter Key Elements
 Rewriting Rule
 Describes how to parse a ‘nice’ URL and compose the
actual ‘long’ URL of the resource to be returned
 Two types: sprintf-based and regex-based
 Rewriting Rule List
 Named, ordered list of rewriting rules or rule lists
 Tried from top to bottom, first matching rule is applied
 Conductor UI for rewriting rule configuration
 Configuration API – alternative to Conductor UI, for scripts
 Functions for creating, dropping, enumerating rules &
rule lists
© 2009 OpenLink Software, All rights reserved
Conductor UI for URL Rewriter
RDF view for Northwind sample database:
Rewriting rule for HTML requests
© 2009 OpenLink Software, All rights reserved
Conductor UI for URL Rewriter
RDF view for Northwind sample database:
Rewriting rule for RDF/XML or N3 based resource description requests
© 2009 OpenLink Software, All rights reserved
Conductor UI for URL Rewriter
Defining the SPARQL query underpinning the ‘Destination Path Format’ of
the RDF/XML / N3 rewriting rule – Automatically URL encoded when saved
© 2009 OpenLink Software, All rights reserved
Rewrite Rule Components in Conductor UI
 Request Path Pattern e.g. (/[^#]*)
 a regular expression matched against the input path
 Substitution parameters
 Each successive pair of parentheses in the regex
denotes a parameter referred to elsewhere in the rewrite
rule as $U1, $U2, $U3 … or $s1, $s2, $s3 …
 Can be used to substitute the part of the input path that
was matched into the new URL being composed
 $accept parameter substitutes matched content types
specified in Accept header
 ‘U’ format specifier – URL encodes inserted text
 ‘s’ format specifier – inserts matched text ‘as is’
© 2009 OpenLink Software, All rights reserved
URL Rewriter – URIQADefaultHost Macro
URIQADefaultHost Macro
 Makes rewriting rules (& RDF View definitions) more
portable
 Each occurrence is substituted with the value of the
DefaultHost parameter in URIQA section of virtuoso.ini
configuration file
 DefaultHost ::= server name. e.g. www.example.com:8890
DESCRIBE <http:///^{URIQADefaultHost}^$U1#this>
FROM <http://^{URIQADefaultHost}^/Northwind>
© 2009 OpenLink Software, All rights reserved
URL Rewriting Process for RDF Requests
© 2009 OpenLink Software, All rights reserved
URL Rewriting Process for HTML
Requests
HTML requests are redirected via proxy /about/html to a rendering template - description.vsp
description.vsp rendering of Customer entity
<http://demo.openlinksw.com/Northwind/Customer/ALFKI#this>
© 2009 OpenLink Software, All rights reserved
description.vsp – Rendering RDF as HTML
Destination path in rewrite rule for HTML requests:
/about/html/http://^{URIQADefaultHost}^$s1
 Redirects client to the Virtuoso ‘Page Description Service’
via proxy interface /about/html
 Page description services invokes description.vsp which in
turn invokes the Virtuoso Sponger
 Sponger: a customizable RDFizer with pluggable cartridges
 Extracts RDF from the target URL
 Native RDF sources: RDF is returned ‘as is’
 Non-RDF sources: Meta-data is extracted and converted
to RDF using ontology mapping and XSLT
 description.vsp renders the extracted RDF as HTML
 Substitutes RDF ‘hyperdata’ links with HTML hyperlinks
© 2009 OpenLink Software, All rights reserved
Exporting URL Rewriting Rules from Conductor
 Rewrite rules configured in Conductor can be exported as
Virtuoso PL for backup, use on another system etc.
 Exported script recreates rules using Virtuoso’s
URL Rewriting Configuration API
© 2009 OpenLink Software, All rights reserved
Example Exported Rule Definitions
DB.DBA.VHOST_DEFINE (
lhost=>'*ini*', vhost=>'*ini*',
lpath=>'/Northwind',ppath=>'/DAV/home/demo/',
is_dav=>1, vsp_user=>'dba',
ses_vars=>0, opts=>vector ('url_rewrite',
'demo_nw_rule_list1'), is_default_host=>0);
DB.DBA.URLREWRITE_CREATE_RULELIST (
'demo_nw_rule_list1', 1, vector ('demo_nw_rule1',
'demo_nw_rule2'));
DB.DBA.URLREWRITE_CREATE_REGEX_RULE (
'demo_nw_rule1', 1, '(/[^#]*)',vector ('path'), 1,
'/about/html/http://^{URIQADefaultHost}^%s',
vector ('path'),
NULL, '(text/html)|(\\*/\\*)', 0, 303, NULL);
DB.DBA.URLREWRITE_CREATE_REGEX_RULE (
'demo_nw_rule2', 1, '(/[^#]*)', vector ('path'), 1,
'/sparql?query=DESCRIBE+%%3Chttp%%3A//^{URIQADefaultHost}^%U%%2
3this%%3E+%%3Chttp%%3A//^{URIQADefaultHost}^%U%%3E+FROM+%%3Chtt
p%%3A//^{URIQADefaultHost}^/Northwind%%3E&format=%U', vector
('path', 'path', '*accept*'), NULL,
'(text/rdf.n3)|(application/rdf.xml)', 0, NULL, NULL);
© 2009 OpenLink Software, All rights reserved
URL Rewriter API: Enabling Rewriting




Enabled through vhost_define( ) function
vhost_define( ) defines a virtual host or virtual path
opts parameter is a vector of field-value pairs
Field url_rewrite controls / enables URL rewriting
 Field value is the IRI of the rule list to apply
e.g.
DB.DBA.VHOST_DEFINE (
lhost=>'*ini*', vhost=>'*ini*',
lpath=>'/Northwind',ppath=>'/DAV/home/demo/',
is_dav=>1, vsp_user=>'dba',
ses_vars=>0, opts=>vector ('url_rewrite', 'demo_nw_rule_list1'),
is_default_host=>0);
© 2009 OpenLink Software, All rights reserved
URL Rewriter API: Summary
Functions in DB.DBA schema:
 URLREWRITE_CREATE_SPRINTF_RULE
 URLREWRITE_CREATE_REGEX_RULE
 URLREWRITE_CREATE_RULELIST
 URLREWRITE_DROP_RULE
 URLREWRITE_DROP_RULELIST
 URLREWRITE_ENUMERATE_RULES
 URLREWRITE_ENUMERATE_RULELISTS
© 2009 OpenLink Software, All rights reserved
‘Nice’ URLs vs ‘Long’ URLs
 Rewriter developed with broader objectives than Linked
Data – consequently influenced terminology
 Rewriter takes a ‘nice’ URL and rewrites it as a ‘long’ URL
 ‘Nice’ URL
 Free from parameters, typically short
 ‘Long’ URL
 Typically contains query string with named parameters
 Often ignored by web crawlers (viewed as highly
dynamic) => low page ranking
© 2009 OpenLink Software, All rights reserved
Sprintf Rules vs Regex Rules
 For ‘nice’ to ‘long’ URL conversion
 Functionally equivalent
 Only difference is syntax of match pattern definition
 For ‘long’ to ‘nice’ URL conversion
 Only works for sprintf-based rules
 Regex-based rules are unidirectional
© 2009 OpenLink Software, All rights reserved
URLREWRITE_CREATE_REGEX_RULE
URLREWRITE_CREATE_REGEX_RULE (
rule_iri, allow_update, nice_match, nice_params, nice_min_params,
target_compose, target_params, target_expn := null,
accept_pattern := null, do_not_continue := 0,
http_redirect_code := null, http_headers := null) ;
rule_iri: rule’s name / identifier
nice_match: regex to parse URL into a vector of ‘occurrences’
nice_params: vector of names of the parsed parameters.
Length of vector equals # of ‘(…)’ specifiers in the regex
target_compose: ‘compose’ regex for the destination URL
target_params: vector of names of parameters to pass to the
‘compose’ expression as $1, $2 etc
target_expn: optional SQL text to execute instead of a regex compose
accept_pattern: regex expression to match the HTTP Accept header
do_not_continue: on a match, try / don’t try next rule in rule list
http_redirect_code: null, 301, 302 or 303. 30x => HTTP redirect
http_headers: HTTP headers to supply with the rewritten request
© 2009 OpenLink Software, All rights reserved
URL Rewriter - Verification with curl
curl utility provides a useful tool for verifying HTTP server responses and
rewriting rules
$ curl -I -H "Accept: application/rdf+xml" http://demo.openlinksw.com/Northwind/
Customer/ALFKI
HTTP/1.1 303 See Other
Server: Virtuoso/05.09.3037 (Solaris) x86_64-sun-solaris2.10-64 VDB
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Date: Thu, 12 Feb 2009 11:23:31 GMT
Accept-Ranges: bytes
Location: http://demo.openlinksw.com/sparql?query=DESCRIBE+%3Chttp
%3A//demo.openlinksw.com%2FNorthwind%2FCustomer%2FALFKI%23this%3E+%3Chttp
%3A//demo.openlinksw.com%2FNorthwind%2FCustomer%2FALFKI%3E+FROM+%3Chttp
%3A//demo.openlinksw.com/Northwind%3E&format=application%2Frdf%2Bxml
Content-Length: 0
Note: default rule for RDF requests changed to return HTTP response 303, rather than use an internal redirect, to allow the
generated SPARQL query to be viewed and checked with curl
© 2009 OpenLink Software, All rights reserved
Browsing & Exploring Linked Data
OpenLink Data Explorer (ODE)
 Browser extension (Firefox, support for others to follow)
 See http://ode.openlinksw.com
 RDF and HTML views of Linked Data
 RDF view incorporates ‘hyperdata’ links between entities
 HTML view substitutes hyperlinks
 Also available as a hosted service
 E.g. http://demo.openlinksw.com/ode
iSparql Query Tool
 Interactive SPARQL Query Builder
 E.g. http://demo.openlinksw.com/isparql
 See http://wikis.openlinksw.com/dataspace/owiki/wiki/OATWikiWeb/InteractiveSparqlQueryBuilder
© 2009 OpenLink Software, All rights reserved
Content Negotiation Revisited - TCN
Virtuoso supports two flavours of content negotiation:
 HTTP/1.1 style content negotiation (introduced earlier)
 Server-driven negotiation only
 Transparent Content Negotiation (TCN)
 Server-driven or agent-driven negotiation
 Suitably enabled user agents / browsers can take
advantage of TCN
 Non-TCN capable user agents continue to be handled
using HTTP/1.1 content negotiation
© 2009 OpenLink Software, All rights reserved
Transparent Content Negotiation
 A protocol defined by RFC2295, layered on top of HTTP/1.1
 Addresses deficiencies in HTTP/1.1 content negotiation
 Limited to server selecting best variant
(server-driven negotiation)
 Server doesn’t always know/select best variant
 User agent might often be better placed to decide what is best
for its needs
 Inefficient
 Sending details of user agent's capabilities and preferences with
every request is inefficient
 Large number of Accept headers required
 Very few Web resources have multiple variants
© 2009 OpenLink Software, All rights reserved
Transparent Content Negotiation
 Supports variant selection by user agent or by server
 Transparent - all variants on server are visible to the agent
Variant Selection by User Agent:
 User agent chooses best variant itself from variant list sent
by server
 Requires sending fewer/smaller Accept headers
Variant Selection by Server:
 User agent can instruct server to select best variant on its
behalf
 Server uses ‘remote variant selection algorithm’ (RFC2296)
© 2009 OpenLink Software, All rights reserved
TCN – Basic Mechanics
Client
 Supplies Negotiate* request header
 Content negotiation directives include:
 "trans" => user agent supports TCN for the current request
 "vlist" - user agent wants a variant list for the resource
 Variant list is expressed as an Alternates header.
 Implies "trans".

"*" - user agent allows servers and proxies to run any
remote variant selection algorithm
Server
 Returns a TCN* response header signalling that the resource is
transparently negotiated and either a choice or a list response as
appropriate
*New headers introduced by RFC2295
© 2009 OpenLink Software, All rights reserved
Example – Preferred format: XML
 Assumes Virtuoso WebDAV server contains 3 variants of resource named ‘page’:
 /DAV/TCN/page.xml
 /DAV/TCN/page.html
 /DAV/TCN/page.txt
 User agent indicates preference for XML
$ curl -i -H "Accept: text/xml,text/html;q=0.7,text/plain;q=0.5,*/*;q=0.3"
-H "Negotiate: *" http://demo.openlinksw.com/DAV/TCN/page
HTTP/1.1 200 OK Server: Virtuoso/05.00.3021 (Linux) i686-pc-linux-gnu VDB
Connection: Keep-Alive
Date: Wed, 2 Feb 2009 15:44:07 GMT
Accept-Ranges: bytes
TCN: choice
Vary: negotiate,accept
Content-Location: page.xml
Content-Type: text/xml
ETag: "8b09f4b8e358fcb7fd1f0f8fa918973a"
Content-Length: 39
<?xml version="1.0" ?>
<a>some xml</a>
© 2009 OpenLink Software, All rights reserved
Example – Preferred format: HTML
 User agent indicates preference for HTML
$ curl -i -H "Accept: text/xml;q=0.3,text/html;q=1.0,text/plain;q=0.5,*/*;q=0.3"
-H "Negotiate: *" http://demo.openlinksw.com/DAV/TCN/page
HTTP/1.1 200 OK
Server: Virtuoso/05.00.3021 (Linux) i686-pc-linux-gnu VDB
Connection: Keep-Alive
Date: Wed, 3 Feb 2009 15:43:18 GMT
Accept-Ranges: bytes
TCN: choice
Vary: negotiate,accept
Content-Location: page.html
Content-Type: text/html
ETag: "14056a25c066a6e0a6e65889754a0602"
Content-Length: 49
<html>
<body>
some html
</body>
</html>
© 2009 OpenLink Software, All rights reserved
Example – Variant list request
 User agent asks for a list of variants
$ curl -i -H "Accept: text/xml,text/html;q=0.7,text/plain;q=0.5,*/*;q=0.3"
-H "Negotiate: vlist" http://localhost:8890/DAV/TCN/page
HTTP/1.1 300 Multiple Choices
Server: Virtuoso/05.00.3021 (Linux) i686-pc-linux-gnu VDB
Connection: close
Content-Type: text/html; charset=ISO-8859-1
Date: Wed, 3 Feb 2009 15:44:35 GMT
Accept-Ranges: bytes
TCN: list
Vary: negotiate,accept
Alternates: {"page.html" 0.900000 {type text/html}}, {"page.txt" 0.500000 {type
text/plain}}, {"page.xml" 1.000000 {type text/xml}}
Content-Length: 368
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head><title>300 Multiple Choices</title></head>
<body><h1>Multiple Choices</h1>Available variants:<ul>
<li><a href="page.html">HTML variant</a>, type text/html</li>
<li><a href="page.txt">Text document</a>, type text/plain</li>
<li><a href="page.xml">XML variant</a>, type text/xml</li>
</ul></body></html>
© 2009 OpenLink Software, All rights reserved
TCN Configuration – Variant Description
 Variant descriptions held in SQL table HTTP_VARIANT_MAP
 Added/updated/removed through Virtuoso/PL or Conductor UI
create table DB.DBA.HTTP_VARIANT_MAP (
VM_ID integer identity, -- unique ID
VM_RULELIST varchar, -- HTTP rule list name
VM_URI varchar, -- name of requested resource e.g. 'page'
VM_VARIANT_URI varchar, -- name of variant e.g. 'page.xml','page.de.html' etc.
VM_QS float, -- Source quality, number in the range 0.001-1.000, with 3 digit precision
VM_TYPE varchar, -- Content type of the variant e.g. text/xml
VM_LANG varchar, -- Content language e.g. 'en', 'de' etc.
VM_ENC varchar, -- Content encoding e.g. 'utf-8', 'ISO-8892‘ etc.
VM_DESCRIPTION long varchar, -- human readable variant description
e.g. 'Profile in RDF format'
VM_ALGO int default 0, -- reserved for future use
primary key (VM_RULELIST, VM_URI, VM_VARIANT_URI)
)
create unique index HTTP_VARIANT_MAP_ID on DB.DBA.HTTP_VARIANT_MAP (VM_ID)
© 2009 OpenLink Software, All rights reserved
TCN Configuration - via Conductor UI
© 2009 OpenLink Software, All rights reserved
TCN Configuration - via Virtuoso/PL
 Adding or Updating a Resource Variant
DB.DBA.HTTP_VARIANT_ADD (
in rulelist_uri varchar, -- HTTP rule list name
in uri varchar, -- Requested resource name e.g. 'page'
in variant_uri varchar,
-- Variant name e.g. 'page.xml', 'page.de.html' etc.
in mime varchar, -- Content type of the variant e.g. text/xml
in qs float := 1.0, -- Source quality, a floating point number with 3
digit precision in 0.001-1.000 range
in description varchar := null, -- a human readable description of the
variant e.g. 'Profile in RDF format'
in lang varchar := null, -- Content language e.g. 'en', 'bg'. 'de' etc.
in enc varchar := null -- Content encoding e.g. 'utf-8', 'ISO-8892' etc.
)
 Removing a Resource Variant
DB.DBA.HTTP_VARIANT_REMOVE (
in rulelist_uri varchar, -- HTTP rule list name
in uri varchar, -- Name of requested resource e.g. 'page'
in variant_uri varchar := '%' -- Variant name filter
)
© 2009 OpenLink Software, All rights reserved
TCN Configuration - via Virtuoso/PL
Adding resource variant descriptions
 Define variant descriptions & associate them with a rule list
DB.DBA.HTTP_VARIANT_ADD ('http_rule_list_1', 'page', 'page.html', 'text/html',
0.900000, 'HTML variant');
DB.DBA.HTTP_VARIANT_ADD ('http_rule_list_1', 'page', 'page.txt', 'text/plain',
0.500000, 'Text document');
DB.DBA.HTTP_VARIANT_ADD ('http_rule_list_1', 'page', 'page.xml', 'text/xml',
1.000000, 'XML variant');
 Define a virtual directory & associate the rule list with it
DB.DBA.VHOST_DEFINE (lpath=>'/DAV/TCN/', ppath=>'/DAV/TCN/', is_dav=>1,
vsp_user=>'dba', opts=>vector ('url_rewrite', 'http_rule_list_1'));
© 2009 OpenLink Software, All rights reserved