Re: PROV-ISSUE-627 (URI-specified-or-REST): Should PROV-AQ specify PROV service URI or always use template?

>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