Re: Access and query TF - actions for WG

Luc Moreau wrote:
> Hi Graham,
> But if you want to ask a third party (assuming you have found it by (a) 
> or (c)), how will you do it?
> Do you need a separate protocol?
> Regards,
> Luc

You don't need a separate protocol just because they're provided by a third 
party.  Once you have a URI for a provenance resource, web retrieval can be 
applied.  (In case it's not clear, in the model I envisage, multiple provenance 
resources can be associated with a target, each with different URIs.)

But please be clear that I'm not saying additional protocols will not be needed 
(*).  I'm not claiming the web retrieval mechanisms are the end of the story, 
just the start.  What I'm arguing for is to start on the simple cases first, and 
see how they pan out.

#g
--

(*)

For example, I'm very aware that the charter envisages a query service.  Such a 
query service might provide both discovery (per my previous case (a)) *and* 
retrieval (**).  But I think it will be easier to see what is needed when we've 
a clearer consensus view of how much is covered by the simple web-retrieval 
approach, and where the gaps are.  I also expect that when we consider a query 
service, we may need to be less agnostic about the actual provenance model and 
format, so it would may be better to consider that when we can see the provnance 
model taking shape.

BTW, I think the model is the area where this group's expertise most eeds to be 
directed.


(**)

I could probably sit down and write a spec for such a service now.  But to do 
so, I would need to make certain assumptions about other parts of the provenance 
standards family and the requirements on such a service.  But this is a 
consensus process, and any such assumptions would likely be invalidated as the 
standards are developed.  Hence the small steps.



> On 20/06/11 19:01, Graham Klyne wrote:
>> Luc Moreau wrote:
>>> OK, I can use HTTP HEAD in order to obtain provenance-URI for some 
>>> resource.
>>> This provenance-URI will be returned by the same service as the one 
>>> providing the resource.
>>
>> Correct.
>>
>>> How can I obtain an alternative provenance from another service?  I 
>>> don't understand I
>>> would get an alternative provenance-URI?
>>
>> I don't have a single immediate answer.  I can imagine several 
>> possible mechanisms (*), but I have no way to judge which is most 
>> appropriate.
>>
>> And in any case, it is not obvious to me that we need a *standard* for 
>> such a mechanism (not saying we don't, just not sure that we do).
>>
>> Therefore, in the spirit of earlier posts I would suggest this is a 
>> case for which we do not define a solution in a first draft, and then 
>> see what
>>
>> #g
>> -- 
>>
>> (*)
>>
>> Some possible mechanisms:
>>
>> (a) ask known third party service providers
>> (b) the content provider could specify alernative provennce sources in 
>> the content (I previously said something about not using HTTP Link: 
>> and HTML <Link> together:  this might be a reason to not discourage 
>> that).
>> (c) Google (or semantic web equivalent) for the resource URI plus 
>> "provenance" or similar
>> (d) ask the resource provider (server) for alternative provenance sources
>>
>> Without knowing more about a specific scenario, and in particular who 
>> in that scenario is expected to know what, it's not possible to 
>> recommend one of these over the others.  But my hunch is that (a) and 
>> (c) will prove most useful.
>>
>>
>>
>

Received on Tuesday, 21 June 2011 06:52:22 UTC