W3C home > Mailing lists > Public > public-prov-wg@w3.org > February 2013

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

From: Timothy Lebo <lebot@rpi.edu>
Date: Mon, 11 Feb 2013 08:48:22 -0500
Cc: Graham Klyne <gklyne@googlemail.com>, Paul Groth <p.t.groth@vu.nl>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Message-Id: <4404FCCE-5A7F-4BC7-80A7-750D2136B6B0@rpi.edu>
To: Graham Klyne <Graham.Klyne@zoo.ox.ac.uk>

On Feb 8, 2013, at 1: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,

It's clumsy when done in XML, too. If one wants to align with this odd "content-type defines the vocab" paradigm, then they can spam the IANA with one mime type for each RDF vocabulary (or, XML schema). I'm fine with the client determining what they understand from the representation they receive. All representations returned should be equivalent, according to AWWW.


> 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 :-)

Yes, I'm against making the URI-template the definitive way to describe a service.
But I don't have any more energy on this front. It's just a note, and I'll follow semweb practices in my applications.

-Tim



> 
>> 
>>> 
>>>> 
>>>>> 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
> --
> 
Received on Monday, 11 February 2013 13:48:48 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:30 UTC