- From: Paul Groth <p.t.groth@vu.nl>
- Date: Wed, 2 Jan 2013 16:04:35 +0100
- To: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- Cc: Timothy Lebo <lebot@rpi.edu>, "Cresswell, Stephen" <stephen.cresswell@tso.co.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <CAJCyKRos_JVg6H6w+YJBZQyOMfk7457oJOKyS7oUbyDNC006Bw@mail.gmail.com>
This seems like the only option, in particular, if we ensure that that the
template that needs to be returned is ligh-weight....
regards
Paul
On Wed, Jan 2, 2013 at 3:49 PM, Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>wrote:
> Tim,
> Paul,
>
> Following an extended discussion with Erik Wilde, I'm now persuaded that
> an new
> link relation is not the best way to go for SPARQL endpoints.
>
> I the absence of a clear alternative proposal, I propose to stick with RDF
> (in
> any of its syntaxes) for the service description.
>
> I do think we want an easy way to distinguish different service
> implementations
> in an RDF service description, and my preference for this would be the
> rdf:type
> of the described service resource.
>
> Thus, if we have a provenance service that supports both the templated and
> SPARQL interfaces, I would anticipate a service description along these
> lines:
>
> [[
> <#template> a prov:ProvenanceService ;
> prov:provenanceUriTemplate "http://www.example.net/prov?target={+uri}
> "
> .
>
> <#sparql> a sd:Service ;
> # (description per http://www.w3.org/TR/sparql11-service-description/
> )
> sd:endpoint <http://www.example.net/sparql/> ;
> sd:supportedLanguage sd:SPARQL11Query ;
> sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML> ,
> <http://www.w3.org/ns/formats/Turtle> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_XML> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_JSON> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_CSV> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_TSV>
> .
> ]]
>
> I think it's easy to see how this can generalize to accommodate alternative
> services if such are introduced later.
>
> In practice, I anticipate that different service URIs (indicated by
> multiple
> provenance service link headers) would each implement a single access
> mechanism,
> so the multiple options within a single service description as shown above
> are
> not a requirement.
>
> Tim: you indicated previously that prov:ProvenanceService should apply to
> *all*
> forms of provenance service. I haven't proposed that above, but it would
> be
> possible to have this as a generic class for all provenance services, with
> the
> above example then becoming, say:
>
> [[
> <#template> a prov:TemplatedService, prov:ProvenanceService ;
> prov:provenanceUriTemplate "http://www.example.net/prov?target={+uri}
> "
> .
>
> <#sparql> a sd:Service, prov:ProvenanceService ;
> # (description per http://www.w3.org/TR/sparql11-service-description/
> )
> sd:endpoint <http://www.example.net/sparql/> ;
> sd:supportedLanguage sd:SPARQL11Query ;
> sd:resultFormat <http://www.w3.org/ns/formats/RDF_XML> ,
> <http://www.w3.org/ns/formats/Turtle> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_XML> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_JSON> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_CSV> ,
> <http://www.w3.org/ns/formats/SPARQL_Results_TSV>
> .
> ]]
>
> If you're OK with this, I'll plan to update PROV-AQ accordingly (but I
> can't
> guarantee to have it done until after next week, as I'm travelling to a
> meeting
> then.)
>
> #g
> --
>
> On 29/11/2012 18:53, Timothy Lebo wrote:
> > all,
> >
> > On Nov 29, 2012, at 1:36 PM, Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
> wrote:
> >
> >> We decided to drop the merely advisory material about how to use
> SPARQL, and leave that to the FAQ. But discovery of a SPARQL endpoint got
> forgotten in the change (I think it was never really specified previously).
> >>
> >> I think the cleanest solution would to to introduce another link
> relation
> >
> > 1)
> >
> > I'm not fond of another link relation just to point to one specific
> service technology.
> >
> > To handle "discovery of SPARQL endpoints" I think we should instead
> combine:
> > A) GET on service gives RDF description. (as already stated)
> > B) http://www.w3.org/TR/sparql11-service-description/
> >
> > to return:
> >
> > <service-URI> a prov:ProvenanceService, sd:Service ;
> > additional vocabulary from B should be used further describe the service.
> > The fact that <service-URI> is a sd:Service indicates that it is a
> SPARQL endpoint.
> >
> >
> > 2)
> >
> > The following citation seems to be inconsistent.
> >
> > [SPARQL-HTTP]
> > Chimezie Ogbuji. SPARQL 1.1 Service Description. 2011, Work in progress.
> URL: http://www.w3.org/TR/sparql11-http-rdf-update/
> >
> > 3)
> >
> > In
> http://dvcs.w3.org/hg/prov/raw-file/tip/paq/prov-aq.html#provenance-service-description
> > I do not think the prov:provenanceUriTemplate property should be so
> prominent.
> >
> > The first example:
> >
> > <service-URI> a prov:ProvenanceService ;
> > prov:provenanceUriTemplate "service-URI?target={+uri}" .
> > should be trimmed to:
> >
> > <service-URI> a prov:ProvenanceService ;
> >
> > with prov:provenanceUriTemplate being described as an OPTIONAL
> description in subsequent discussion (as it stands now, it appears to be
> required).
> > This, too, is an assumption on how a service could be accessed.
> >
> > -Tim
> >
> >
> >
> >
> >
> >
> >> for a SPARQL query endpoint (but to not get into details of how to
> formulate the queries, other than to say that they are presented via SPARQL
> HTTP protocol, and executed over provenance formulated as RDF according to
> PROV-O).
> >>
> >> I'll raise an issue for this.
> >>
> >> #g
> >> --
> >>
> >> Tracker, this is issue 609
> >>
> >>
> >> On 29/11/2012 15:59, Paul Groth wrote:
> >>> It's a good question. I wonder if we can somehow role this into
> >>> provenance-service url?
> >>>
> >>> Paul
> >>>
> >>>
> >>> On Thu, Nov 29, 2012 at 4:30 PM, Cresswell, Stephen <
> stephen.cresswell@tso.co.uk
> >>> <mailto:stephen.cresswell@tso.co.uk>> wrote:
> >>>
> >>> Hi,____
> >>>
> >>> __ __
> >>>
> >>> It still seems to me appropriate for PROV-AQ to include some
> method by which
> >>> publishers of a resource can indicate a SPARQL endpoint for
> provenance
> >>> queries.____
> >>>
> >>> There was some discussion on this about a year ago, but it got
> stuck on
> >>> unresolved questions about named graphs, and doesn’t seem to have
> made it
> >>> into the document.____
> >>>
> >>> __ __
> >>>
> >>> Has there been a decision not to accommodate this, or is it still a
> >>> possibility?____
> >>>
> >>> __ __
> >>>
> >>>
> http://lists.w3.org/Archives/Public/public-prov-wg/2011Dec/0067.html____
> >>>
> >>>
> http://lists.w3.org/Archives/Public/public-prov-wg/2011Dec/0040.html____
> >>>
> >>>
> http://lists.w3.org/Archives/Public/public-prov-wg/2011Dec/0039.html____
> >>>
> >>> __ __
> >>>
> >>> Stephen Cresswell____
> >>>
> >>> __ __
> >>>
> >>> This email is confidential and may also be privileged and/or
> proprietary to
> >>> The Stationery Office Limited. It may be read, copied and used
> only by the
> >>> intended recipient(s). Any unauthorised use of this email is
> strictly
> >>> prohibited. If you have received this email in error please
> contact us
> >>> immediately and delete it and any copies you have made. Thank you
> for your
> >>> cooperation.
> >>>
> >>> The Stationery Office Limited is registered in England under
> Company No.
> >>> 3049649 at 1-5 Poland Street, London, W1F 8PR
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>> --
> >>> Dr. Paul Groth (p.t.groth@vu.nl <mailto:p.t.groth@vu.nl>)
> >>> http://www.few.vu.nl/~pgroth/ <http://www.few.vu.nl/%7Epgroth/>
> >>> Assistant Professor
> >>> - Knowledge Representation & Reasoning Group |
> >>> Artificial Intelligence Section | Department of Computer Science
> >>> - The Network Institute
> >>> VU University Amsterdam
> >>
> >>
> >
> >
>
--
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam
Received on Wednesday, 2 January 2013 15:05:03 UTC