- From: Graham Klyne <gklyne@googlemail.com>
- Date: Sun, 10 Feb 2013 16:40:08 +0000
- To: Paul Groth <p.t.groth@vu.nl>,Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>
- CC: Timothy Lebo <lebot@rpi.edu>,Graham Klyne <gklyne@googlemail.com>,"public-prov-wg@w3.org" <public-prov-wg@w3.org>
- Message-ID: <60800ea5-bedc-4614-abd5-9c43f3eaff85@email.android.com>
Paul, I think that we need one for at least the services we define. But I take your point that if someone else defines a different service, or even an alternative description for the same services they don't have to use the same approach. #g. Paul Groth <p.t.groth@vu.nl> wrote: >From the discussion below, I'm wondering if we should require a >particular >service description format or not? > >Thanks >Paul > > >On Fri, Feb 8, 2013 at 7:32 PM, Graham Klyne ><Graham.Klyne@zoo.ox.ac.uk>wrote: > >> >> >> On 08/02/2013 18:14, Timothy Lebo wrote: >> > Graham, >> > >> > On Feb 8, 2013, at 1:07 PM, Graham Klyne ><graham.klyne@zoo.ox.ac.uk> >> wrote: >> > >> >> On 08/02/2013 14:47, Timothy Lebo wrote: >> >>> 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. >> >> That's not what I said. >> >> >> >> What I claim is that it's harder (not impossible) to use content >> negotiation to select between alternative processing models all >expressed >> using RDF. This topic is explored at some length in the discussion >between >> myself and Erik Wilde that took place here and on the LDP WG >discussion >> lists. >> >> >> >> Links in http://www.w3.org/2011/prov/track/issues/425 >> >> >> >> Discussion at: >> >> http://lists.w3.org/Archives/Public/public-ldp/2012Nov/0036.html >> >> then continued at: >> >> http://lists.w3.org/Archives/Public/public-ldp/2012Dec/0003.html >> > >> > My understanding of those conversations is that you were wrestling >> between "Encode it in the RDF returned" vs. "Encode it in the HTTP >Links". >> >> Yes. And I was persuaded of the merits of "encoded it in RDF". >> >> > So, I don't understand how "it's harder (not impossible) to use >content >> negotiation to select between alternative processing models all >expressed >> using RDF" is difficult. You ask for RDF, and you get back different >> vocabularies that you do, or do not, understand and thus respond >> appropriately to. >> >> Indeed. But it's not the content-type that changes to reflect the >different >> options, but the RDF vocabulary received. The historical REST model >used >> with >> XML-based representations is to use a different content-type for >different >> service description structures. To do that in RDF would be clumsy, >because >> you'd have to either: >> >> (a) settle on a particular RDF syntax, or >> (b) introduce multiple new content-types for the service documents >> different RDF >> syntaxes. >> >> What's more, because it's RDF, which supports arbitrary document >merging, >> we >> don't have to distinguish at the point of requesting the service >> description. >> >> The disadvantage of this (compared with the XML+conneg) is that the >> clienbt has >> to pick through the received RDF and figure out what service >descriptions >> it has >> to choose between. I don't think that's a big deal, but it might be >a >> consideration. >> >> And it is *still* possible to use content negotiation to regtrieve >service >> descriptions in formats other that RDF. So the common REST >mechanisms can >> still >> be used if someone defines appropriate service description document >> formats and >> MIME types. >> >> >>>> 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 ^^. >> >> See above discussion thread. In particular, about: >> >> http://lists.w3.org/Archives/Public/public-ldp/2012Dec/0013.html >> >> http://lists.w3.org/Archives/Public/public-ldp/2012Dec/0018.html >> >> >> >> The subsequent discussion is mainly about whether this approach is >> incompatible with the more traditional content-type based negotiation >at >> the destination of a link. I think I showed they are compatible. >> > >> > Then, we're good? :-) >> >> I believe so, but a consequence is that we drop the specified URI >form from >> PROV-AQ (other than as an example) and use the URI-template in the >service >> description as definitive. That is what I thought you were arguing >> against. If >> you're OM with this, then we're good :-) >> >> > >> >> >> >>> >> >>>> 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). >> >> The intent is that the URI template is indicated in the RDF data >as >> part of the service description. >> >> >> >> My point (and Ivan's, I believe) in all this is that PROV-AQ as a >> specification SHOULD NOT specify the URI pattern: the service itself >can >> do that, and in a way that is discoverable and usable by a service >client. >> > >> > That makes sense. In that case, they'd all use the same >prov:uriTemplate >> property, but have different values that are interpreted in different >ways? >> >> Yes - that's the general idea (though I would prefer to say the >template is >> always interpreted in the same way but yielding different URIs). >> >> #g >> -- >> > > > >-- >-- >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 -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.
Received on Sunday, 10 February 2013 16:40:42 UTC