- From: Timothy Lebo <lebot@rpi.edu>
- Date: Fri, 8 Feb 2013 09:47:42 -0500
- To: Graham Klyne <gklyne@googlemail.com>
- Cc: Paul Groth <p.t.groth@vu.nl>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-Id: <D9AAD386-89BA-4025-AE8A-413E78AE5146@rpi.edu>
Graham, On Feb 7, 2013, at 3:58 PM, Graham Klyne <gklyne@googlemail.com> wrote: > A key element of the current design is that it permits (but does not require) conneg as a mechanism to select alternative service description semantics. Using RDF raises some challenges because it has multiple content types corresponding to syntactic variations, so using conneg for semantic alternatives in RDF is less easy. (e.g. A different "+xyz" suffix for each RDF syntax seems cumbersome.) This is not true. If I want "application/rdf+xml", then I ask for it (and might get it if the server is nice). If I want "text/turtle", then I ask for it (and might get it if the server is nice). If I want "application/pdf", then I ask for it (and might get it if the server is nice). If I have a preference on which of those I get, then I can set the priorities (and might get it if the server is nice). The fact that here are a few syntaxes for RDF is hardly a reason to say it's "harder to get RDF", because conneg is built to handle multiple syntaxes. > > My view is that the nature of RDF allows an additional selection mechanism to be applied within the RDF data. Conneg is still usable, but in RDF vocabulary-driven mechanisms can be used. Like RDF types or the property-based approach Stian proposes. I have to admit that I don't understand these statements ^^. > > But using conneg or not seems to me to be somewhat orthogonal to whether we should be trying to fix the URI patterns that a provenance service responds to. I also think they are orthogonal, since one uses conneg to get some description (in any format), and then within that description a URI pattern is specified. At that point, I don't have any insights to how the prov-aq specifies the URI pattern, because I don't have experience with those kinds of systems (I'll be conneg'ing for the RDF and peeking through some SADI descriptions). -Tim > REST principles clearly say not. I think we've taken a clear step down the REST path, which seems appropriate to me for a Web specification, so I would urge sticking to those principles for maximum flexibility and evolvability. > > #g. > > > Paul Groth <p.t.groth@vu.nl> wrote: > Interestingly this impacts my view of the rdf syntax requirement of the service description. > > A key question for me is does the mandate for rdf for the service description hurt potential uptake from people who provide services using other very common techniques (e.g. Json web services) . My prior view was the definition of a best practice URL was a way of helping adoption. > > Hmmm - I will look again at service description formats. I think content negotiation may be the way out... > > Paul > > On Feb 7, 2013, at 20:27, Graham Klyne <graham.klyne@zoo.ox.ac.uk> wrote: > > Tim, > > Things have changed from last time, because the same link relation is being used > to access multiple query mechanisms (something you > argued for :^) ). This is a > design choice that is a large extent guided by REST principles. So now I shall > argue more strongly for sticking with a full-REST pattern. > > The client should not have any prior knowledge of how the server URI space is > used. That's a basic constraint of REST. Hence the client MUST learn about the > URI from the service (in this case from the servioce description). That's what > the template defines. > > #g > -- > > On 07/02/2013 16:18, Timothy Lebo wrote: > On Feb 7, 2013, at 9:52 AM, "Provenance Working Group Issue Tracker" <sysbot+tracker@w3.org> wrote: > > PROV-ISSUE-627 (URI-specified-or-REST): Should PROV-AQ specify PROV service URI > +1 > > or always use template? > -1 > > (just as in the last time we had this thread) > > -Tim > > > http://www.w3.org/2011/prov/track/issues/627 > > Raised by: Graham Klyne > On product: > > > > -- > Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Friday, 8 February 2013 14:48:10 UTC