W3C home > Mailing lists > Public > public-rdf-dawg@w3.org > July to September 2009

Queriable End Point Descriptions

From: Orri Erling <erling@xs4all.nl>
Date: Tue, 11 Aug 2009 17:22:30 +0200
Message-Id: <200908111523.n7BFN3Ms010769@smtp-vbr16.xs4all.nl>
To: <public-rdf-dawg@w3.org>
 

 

 

Hi

 

As concerns querying end point descriptions via SPARQL, I would note the
following.

 

1. OpenLink generally favors Having a document-style interface as the
primary means of getting to an end point description.  This has the
advantage of placing no discovery-related requirements on the content
exposed by an end point.

 

2. Even now, we expose end point related metadata  in the form of
automatically generated VOID  graphs containing statistics of data sets we
host.  The VOID graph is then stored as a separate graph.   Such graphs are
queriable as any other data.  The end points in question allow queries to
specify no graph, in which case the query is evaluated against the union  of
all quads on the end point.

 

 

Further, in the use case of query optimization for federated queries, we
find that  periodically retrieving the statistics and caching them locally
is preferrable to issuing queries for statistics as and when needed.  This
is justified by considerations of latency.

 

However, there is a point to making queries against data set descriptions in
diverse user-facing situations, e.g. 

answering questions  on what an end point is about.  For example, what are
the top contributors of content hosted at the site?.  Having queriable VOID
graphs meets this use case.

 

 

Therefore we suggest that  a document-style end point description contain a
field pointing to queriable forms of metadata, specifically VOID graphs.

 

For example, a triple of the form <end-point-uri> sparql:hasVoidGraph
<uri-of-void-graph> .  would indicate that specifying <uri-of-void-graph> as
a graph of a query would give VOID content describing a graph available at
this end point.

 

 

Orri

 

 

 

 

 

 

 

 
Received on Tuesday, 11 August 2009 15:23:38 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 16:15:39 GMT