W3C home > Mailing lists > Public > public-prov-wg@w3.org > November 2011

SPARQL endpoint discovery (was: Comments on PAQ)

From: Graham Klyne <GK@ninebynine.org>
Date: Sat, 19 Nov 2011 09:52:39 +0000
Message-ID: <4EC77C67.7070202@ninebynine.org>
To: "Cresswell, Stephen" <stephen.cresswell@tso.co.uk>
CC: Paul Groth <p.t.groth@vu.nl>, Provenance Working Group WG <public-prov-wg@w3.org>
I did a little digging, and came up with the following (in no particular order).

http://webofdata.wordpress.com/2009/03/10/sparql-endpoint-discovery/

http://semanticweb.org/wiki/VoiD
-- http://vocab.deri.ie/void#sparqlEndpoint

http://www.w3.org/wiki/SweoIG/TaskForces/CommunityProjects/LinkingOpenDataGoodPractice

http://www.iana.org/assignments/link-relations/link-relations.xml (not seeing 
anything that looks like a SPARQL endpoint)

http://www.floop.org.uk/eagle/discovering-sparql

http://lists.w3.org/Archives/Public/semantic-web/2011Apr/0019.html (why semantic 
sitemaps don't work)

http://www.w3.org/wiki/SparqlEndpointDescription - defers to VoID

http://www.w3.org/TR/sparql11-service-description/ (seems overkill for our 
needs, and doesn't address discovery AFAICT)

...

In summary, I'm not yet seeing anything that specifically addresses the need for 
resource metadata SPARQL endpoint discovery.  The nearest I spotted is 
void:sparqlEndpoint (maybe).

I'm thinking that the most broadly useful approach might be a separate document 
that introduces a new link relation and RDF property, along the lines of 
provenance-service, but not specific to provenance.  This, of course, is not 
covered by the current charter - I don't know if that's a problem.  But first, 
we'd need to confirm there isn't already a suitably defined facility.

#g
--

On 18/11/2011 12:59, Cresswell, Stephen wrote:
>
>
> Graham, Paul,
>
>
>
> I have a few comments on PAQ document (not obstructing its release).  I
> read it from the perspective of needing to decide on some solution to
> deploy.  I think the document works and I learned quite a lot reading
> from it.  The biggest question I had was why some possibilities seem to
> be missing, which I think Luc already flagged. I just wanted to
> emphasise this because (unless I misunderstand it) the missing
> possibilities are (from my perspective) some of the most important ones.
>
>
>
> I got these:
>
> If a resource is published by HTTP, or it is HTML or XHTML, then we can
> link to provenance by provenance-uri or provenance-service-uri.
>
> If a resource is some form of RDF, then we can give provenance-uri (but
> apparently not a provenance-service-uri?).
>
>
>
> Despite the coverage of querying provenance in SPARQL, the document
> doesn't tell us how to publish a resource and indicate that its
> provenance can be retrieved from a particular SPARQL endpoint (using a
> given entity-uri and/or a given named graph).  Neither does there seem
> to be a way for a provenance service to give back a link to a SPARQL
> endpoint.  SPARQL endpoints can be self-describing through SPARQL
> service descriptions, but surely we still need to be able to indicate
> that a URI provided for provenance is a SPARQL endpoint.  That seems to
> be a conspicuous gap.
>
>
>
> Minor points:
>
> Section 5.3 - Did you consider using "DESCRIBE
> <http://example.org/resource>  {}" instead of the CONSTRUCT query?
>
> C.1 Gap Analysis - drops into 1st person (not in an annotation).
>
>
>
> Stephen Cresswell
>
>
>
>
> ***********************************************************************************************
> This email, including any attachment, is confidential and may be legally privileged.  If you are not the intended recipient or if you have received this email in error, please inform the sender immediately by reply and delete all copies from your system. Do not retain, copy, disclose, distribute or otherwise use any of its contents.
>
> Whilst we have taken reasonable precautions to ensure that this email has been swept for computer viruses, we cannot guarantee that this email does not contain such material and we therefore advise you to carry out your own virus checks. We do not accept liability for any damage or losses sustained as a result of such material.
>
> Please note that incoming and outgoing email communications passing through our IT systems may be monitored and/or intercepted by us solely to determine whether the content is business related and compliant with company standards.
> ***********************************************************************************************
>
> The Stationery Office Limited is registered in England No. 3049649 at 10 Eastbourne Terrace, London, W2 6LG
>
>
>
Received on Saturday, 19 November 2011 09:59:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:04 UTC