W3C home > Mailing lists > Public > public-egov-ig@w3.org > April 2010

RE: SPARQL best practice for egov?

From: Cory Casanave <cory-c@modeldriven.com>
Date: Tue, 27 Apr 2010 16:50:18 -0400
Message-ID: <4F65F8D37DEBFC459F5A7228E5052044A03E50@DATCENTRALSRV.datcentral.local>
To: "Richard Cyganiak" <richard@cyganiak.de>
Cc: "public-egov-ig IG" <public-egov-ig@w3.org>
Richard,
Re: I don't think that you would arrive at such a conclusion after a
neutral evaluation of both approaches, to be honest.

[cbc] That may be - we have to have a coherent architecture for how all
these parts and pieces fit together to provide the fundamental user
capability of queriable linked global data projected onto user-focused
viewpoints.  Without that coherent architecture it is a bit hard to say
what the tradeoffs are for a particular issue such as this.  

-Cory
-----Original Message-----
From: Richard Cyganiak [mailto:richard@cyganiak.de] 
Sent: Tuesday, April 27, 2010 4:27 PM
To: Cory Casanave
Cc: public-egov-ig IG
Subject: Re: SPARQL best practice for egov?

Hi Cory,

On 27 Apr 2010, at 15:30, Cory Casanave wrote:
> 2- Community: We are proposing a supposedly simple approach to a  
> global
> data grid.  Such a proposal will only be accepted if it works well, is
> very simple to use and does not have major usability holes (such as  
> the
> poor relationship between a URI and a query point).  The user
> perspective must take priority over legacy implementation patterns and
> sunk investment of vendors.  This technology is at its infancy and  
> must
> not be crippled by a such a tactical perspective, least it fail - and
> currently failure is an option.  Complex and expensive algorithms to
> follow a link are unacceptable.

So the two options were:

a) make every URI respond to the SPARQL Protocol,

b) add a link to every document, and follow that link to another  
document that tells you where the SPARQL endpoint is.

You suggest above that b) has the following problems:

- it wouldn't work well,
- it has usability holes,
- it doesn't take the user perspective into account,
- it cripples linked data technology,
- it is expensive.

I don't think that you would arrive at such a conclusion after a  
neutral evaluation of both approaches, to be honest.

Best,
Richard




>
> -Cory
>
> -----Original Message-----
> From: Richard Cyganiak [mailto:richard@cyganiak.de]
> Sent: Monday, April 26, 2010 12:29 PM
> To: Cory Casanave
> Cc: public-egov-ig IG
> Subject: Re: SPARQL best practice for egov?
>
> Hi Cory,
>
> On 23 Apr 2010, at 09:16, Cory Casanave wrote:
>> We had some discussion about the relationship between a RDF URL and a
>> SPARQL endpoint as well as other resources such as graph metadata.
>> The
>> conclusion seemed to be that there are various vocabularies where a
>> triple in the graph could point to the endpoint that points to
>> metadata.
>> The issue with this is that you would then have to get the entire
>> graph
>> to get this one triple - which kind of missed the point if you have a
>> large dataset that you want to query instead of download.
>>
>> I can imagine two conventions that could help solve this:
>>
>> 1) That every resource should respond to a SPARQL endpoint.  This
>> would
>> then allow you to query that one resource directly to subset the data
>> and/or to get the triple that points to metadata.
>
> This option is not feasible IMO because it requires a major revamp of
> the organization's web publishing infrastructure. Typically, a SPARQL
> endpoint, if provided at all, is located on a different server and is
> architecturally separate from the rest of the web server. What you are
> asking for requires completely new server software, and I'm not aware
> of a single product that currently implements this.
>
>> 2) That a standard manipulation is done on a URI to get metadata  
>> about
>> resources, which would include the query point.  For example:
>> http://www.example.com/rdf/people.rfd#cory could have metadata at
>> http://www.example.com/rdf/metadata.rdf.  There are some existing
>> solutions that use this approach.
>
> The voiD [1] solution is to have a triple:
>
> <http://www.example.com/rdf/people.rdf> void:inDataset
> <http://www.example.com/rdf/metadata.rdf#Dataset
>> .
>
> Resolving <http://www.example.com/rdf/metadata.rdf> would yield a
> description of the datset, perhaps including a triple:
>
> <http://www.example.com/rdf/metadata.rdf#Dataset> void:sparqlEndpoint
> <http://www.example.com/sparql
>> .
>
> This exact problem is one of the use cases we had in mind when
> creating voiD. Implementation is reasonably straightforward, it
> requires publication of the <metadata.rdf> (or <void.ttl>) file, and
> one extra link in each RDF file.
>
> Best,
> Richard
>
> [1] http://rdfs.org/ns/void-guide
>
>
>>
>>
>>
>> Can we set a "best practice" for open government data?  My preference
>> would be the first.  Thoughts?
>>
>>
>>
>> -Cory
>>
>
>
Received on Tuesday, 27 April 2010 20:50:43 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 April 2010 20:50:44 GMT