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