Re: Access and query TF - actions for WG

Luc,

Thanks for the further comments: I think they help me to understand why we are 
not fully connecting.  I'm going to bring the discussion from the wiki back to 
the mailing list, because it is still a discussion...

Your use case/problem statement is helpful:
"Problem: The client / user has a representation of a Web resource without any 
indication of provenance and it wants to obtain provenance information about the 
representation (or about the represented Web resource)."
-- http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal#Comments_3

I'll return to this later, but first I need to try and clear your comment about 
provenance URIs.


== Provenance URIs ==

"Your notion of provenance-uri is not clearly defined. Is it a URI indicating 
where provenance can be found, or is it a URI assigned to the entity for the 
purpose of tracking its provenance. If the latter, your own email 
http://lists.w3.org/Archives/Public/public-prov-wg/2011May/0131.html makes it 
clear that it could be a non-dereferenceable URI (e.g. a UUID URN)"
-- http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal#Comments_2

My position here is not precisely either of the cases you mention, though it is 
closer to the first (it is not "assigned to the entity" in any sense that I 
would claim).

I claim simply that a provenance URI identifies a provenance resource in the 
same way that any web URI identifies a resource.

Then, in the same way that web architecture encourages (but does not require), 
the provenance URI may directly dereferencable to obtain a copy of that 
resource.  I am suggesting that this is the default model for accessing 
provenance.  If the URI is not directly dereferencable (a UUID URN, or 
whatever), then additional mechanisms may be required - but these are problems 
for the web at large, not for provenance alone, and a variety of solutions have 
already been proposed; I don't think we should invent any more, of make choices 
until we have a clearer view of where lie the important gaps in what we propose.


== Accessing provenance from representation of resource ==

"Problem: The client / user has a representation of a Web resource without any 
indication of provenance and it wants to obtain provenance information about the 
representation (or about the represented Web resource)."

There are two cases to consider:
(a) one has a representation *and* a URI for the resource (i.e. the view whose 
provenance is required)
(b) one has a representation *and* no URI for the resource

Per my proposals, the problem reduces to that of finding a URI for the provenance.

(a) In the former case, my proposal as stated is simply to use HTTP HEAD to 
obtain the provenance link information, then access the provenance.

(b) in the latter case, my proposal as stated covers your problem for an HTML 
resource.  This problem inherently requires a problem for each format (though a 
generic wrapper format such as MIME multipart/related or might be considered). 
Here we are in risk from straying from web standardization to application 
specification.  To the extent that we standardize format-specific solutions, 
they should be *web* formats; e.g. HTML and RDF (and maybe XML, but I see 
difficulties there as XML is not so much *a* format as a framework for creating 
formats).


There is a third case, which you may have in mind: having a URI for a dynamic 
resource, not an IVP (noting that it doesn't make sense to talk about a 
representation of anything other than an IVP)...  To solve this problem, you 
need a web history machine, and I think that's somewhat out of scope for this 
group.  (But see work on Memento, etc.)

...

So that's it, I think my proposals cover the common cases.  I recognize that I 
have not solved the case of a non-dereferenceable provenance URI, of where the 
original server does not provide a provenance URI, or where the server needs to 
know if provenance may be required later when serving a resource.  But I see 
these as orthogonal problems whose solutions we can better craft when we have a 
basic common-case framework in place, and I can imagine possible solutions for 
both of these (both essentially third-party information services that do not 
need to be provenance-specific).  I was always clear that my proposals were not 
exhaustive, but I do think they form a sufficient basis for initial work.

#g
--

Luc Moreau wrote:
> and further comments from me.
> Luc
> 
> On 17/06/11 21:53, Graham Klyne wrote:
>> I've added some responses.
>>
>> #g
>> -- 
>>
>> Luc Moreau wrote:
>>> I added some responses, questions and comments.
>>> Luc
>>>
>>> On 06/16/2011 04:52 PM, Simon Miles wrote:
>>>> Hello all,
>>>>
>>>> This was said in the teleconference, but not everyone was there.
>>>>
>>>> We would really like comments on the proposals currently made for the
>>>> F2F access and query document.
>>>>    http://www.w3.org/2011/prov/wiki/F2F1_Access_and_Query_Proposal
>>>>
>>>> Can we ask everyone who said they would help with this task force to
>>>> send some comment on them to the mailing list (or on the Wiki page)
>>>> before the next telecon?  At minimum, this could be just to say "All
>>>> the proposals are clear and are equally acceptable to me."  We of
>>>> course welcome comment from all other members of the WG too.
>>>>
>>>> We would also like to ask Graham and Luc to say why they believe their
>>>> proposals are preferable to each others.
>>>>
>>>> Thanks,
>>>> Simon and Yogesh
>>>>
>>>
>>
>

Received on Monday, 20 June 2011 07:44:20 UTC