W3C home > Mailing lists > Public > public-prov-wg@w3.org > September 2011

Re: PROV-ISSUE-75 (provenance-service-and-provenance-uri): What do we do when we get both provenance service and provenance-uri? [Accessing and Querying Provenance]

From: Graham Klyne <GK@ninebynine.org>
Date: Thu, 01 Sep 2011 14:55:01 +0100
Message-ID: <4E5F8EB5.5050308@ninebynine.org>
To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
CC: public-prov-wg@w3.org
See:

http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html#provenance-services

#g
--


On 26/08/2011 09:46, Luc Moreau wrote:
> Hi Graham,
>
> OK, let's see what you write about alternatives.
>
> Luc
>
> On 26/08/11 08:08, Graham Klyne wrote:
>> On 26/08/2011 00:01, Luc Moreau wrote:
>>> Hi Graham,
>>>
>>> On 25/08/11 13:55, Graham Klyne wrote:
>>>> On 22/08/2011 23:01, Provenance Working Group Issue Tracker wrote:
>>>>>
>>>>> PROV-ISSUE-75 (provenance-service-and-provenance-uri): What do we do when we
>>>>> get both provenance service and provenance-uri? [Accessing and Querying
>>>>> Provenance]
>>>>>
>>>>> http://www.w3.org/2011/prov/track/issues/75
>>>>>
>>>>> Raised by: Luc Moreau
>>>>> On product: Accessing and Querying Provenance
>>>>>
>>>>> Do we need to specify what a client should do, when it obtains both a
>>>>> provenance service uri and a provenance-uri? I don't think the specification
>>>>> disallows this case.
>>>>>
>>>>> It's probably like getting multiple provenance-uris. It's worth stating it
>>>>> explicitly.
>>>>
>>>> You're right, that case is not disallowed.
>>>>
>>>> The client can pick either option, or maybe even try both. It's an application
>>>> choice. I'd prefer there weren't two options here, but I can't see how to
>>>> otherwise satisfy the scenario requirements without imposing undue constraints
>>>> on application design.
>>>>
>>>
>>> To say it's an application choice is a cop out, since the PAQ does not offer any
>>> information to the application to make an intelligent choice.
>>
>> I don't think it's a cop out. Application designers know far more about their
>> particular applications than we can possibly do.
>> However, I could add a sentence or two suggesting the kinds of criteria that
>> might come into play (though I don't see it adding much that an application
>> designer wouldn't know anyway).
>>
>>> Isn't there as a minimum, a placeholder for metadata (itself out of scope of
>>> this spec), which gives
>>> publishers the opportunity to distinguish the two options, which in turn helps
>>> applications
>>> to make decisions?
>>>
>>>
>>>> In practice, I would expect most discovery services to provide one or the
>>>> other, not both.
>>>>
>>>
>>> If it's really the case, then why not mandate it?
>>
>> Because it's not necessary to make that constraint, and to do so might well
>> exclude some possibilities that we haven't thought about yet.
>>
>> I shall add some text saying a little more about the alternatives, and the
>> circumstances under which they might be useful.
>>
>> #g
>
Received on Thursday, 1 September 2011 13:55:55 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 13:06:41 GMT