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


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.


Paul Groth <> wrote:

>From the discussion below, I'm wondering if we should require a
>service description format or not?
>On Fri, Feb 8, 2013 at 7:32 PM, Graham Klyne
>> On 08/02/2013 18:14, Timothy Lebo wrote:
>> > Graham,
>> >
>> > On Feb 8, 2013, at 1:07 PM, Graham Klyne
>> wrote:
>> >
>> >> On 08/02/2013 14:47, Timothy Lebo wrote:
>> >>> Graham,
>> >>>
>> >>> On Feb 7, 2013, at 3:58 PM, Graham Klyne <>
>> wrote:
>> >>>
>> >>>> A key element of the current design is that it permits (but does
>> require) conneg as a mechanism to select alternative service
>> semantics. Using RDF raises some challenges because it has multiple
>> types corresponding to syntactic variations, so using conneg for
>> alternatives in RDF is less easy. (e.g. A different "+xyz" suffix for
>> RDF syntax seems cumbersome.)
>> >>>
>> >>> This is not true.
>> >>> If I want "application/rdf+xml", then I ask for it (and might get
>> if the server is nice).
>> >>> If I want "text/turtle", then I ask for it (and might get it if
>> server is nice).
>> >>> If I want "application/pdf", then I ask for it (and might get it
>> the server is nice).
>> >>>
>> >>> If I have a preference on which of those I get, then I can set
>> priorities (and might get it if the server is nice).
>> >>>
>> >>> The fact that here are a few syntaxes for RDF is hardly a reason
>> say it's "harder to get RDF", because conneg is built to handle
>> 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
>> using RDF.  This topic is explored at some length in the discussion
>> myself and Erik Wilde that took place here and on the LDP WG
>> lists.
>> >>
>> >> Links in
>> >>
>> >> Discussion at:
>> >>
>> >> then continued at:
>> >>
>> >
>> > My understanding of those conversations is that you were wrestling
>> between "Encode it in the RDF returned" vs. "Encode it in the HTTP
>> 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
>> negotiation to select between alternative processing models all
>> 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
>> options, but the RDF vocabulary received.  The historical REST model
>> with
>> XML-based representations is to use a different content-type for
>> service description structures.  To do that in RDF would be clumsy,
>> 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
>> 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
>> it has
>> to choose between.  I don't think that's a big deal, but it might be
>> consideration.
>> And it is *still* possible to use content negotiation to regtrieve
>> 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:
>> >>
>> >>
>> >>
>> >> The subsequent discussion is mainly about whether this approach is
>> incompatible with the more traditional content-type based negotiation
>> 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
>> 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
>> description (in any format), and then within that description a URI
>> is specified.
>> >>> At that point, I don't have any insights to how the prov-aq
>> 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
>> 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
>> do that, and in a way that is discoverable and usable by a service
>> >
>> > That makes sense. In that case, they'd all use the same
>> property, but have different values that are interpreted in different
>> 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 (
>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