Re: Kickstarting the Provenance Access and Query Task Force

Olaf,

I'm a little puzzled by your response.  I accept that you may not intend to 
carry forward aspects of the provenance XG report relating to web architecture 
about which I have concern.  That's fine, and having indicated my view I'm happy 
to wait to see how things develop.

But I'm surprised that you don't regard the Powder work as addressing the 
problem.  Maybe I misunderstand the problem.  The provenance XG report section 6 
says:

"This section discusses possibilities to integrate provenance into the Web 
architecture. It focuses on how provenance information about Web resources could 
be exposed as part of the HTTP based message exchange with which these resources 
can be accessed."

Which I take to be exactly the kind of problem that the POWDER work addresses, 
and the point of this group's work on provenance access.

...

To my mind, accessing provenance information on the Web should be simple:  just 
use HTTP (or, more broadly, just use web resource retrieval).  The remaining 
issues, then, are (a) how to know that provenance information is available, and 
(b) what URI to use to retrieve it.  (And POWDER seems to address these concerns.)

So it seems to me that either I'm not properly understanding the problem to be 
addressed, or the XG discussion is making it over-complicated.

If I'm missing something here, I'd really like to know what it is.

Maybe what we really need here is a clear statement (and consensus) of the 
problem to be addressed?

#g
--


Olaf Hartig wrote:
> Hey Graham,
> 
> On Wednesday 18 May 2011 12:49:56 Graham Klyne wrote:
>> Olaf Hartig wrote:
>>  > Proposal 1: The final report [2] of the W3C provenance incubator group
>> contains > a section on "Provenance in Web Architecture", Sec.6. The PAQ
>> TF uses this > section as foundation for the draft that we want to have
>> for the F2F meeting. > By "foundation" I mean as a first incomplete (and
>> inofficial) draft.
>> -- 
>> http://www.w3.org/2005/Incubator/prov/XGR-prov-20101214/#Provenance_in_Web_
>> Architecture
>>
>> ...
>>
>> Short answer:
>>
>> -- http://www.w3.org/TR/powder-dr/#assoc-linking
>>
>> ...
>>
>> Longer answer:
> 
> First, neither your short answer nor your long answer are directly related to 
> my Proposal 1 that you cite above. Just to clarify: Proposal 1 only suggests 
> to use Sec.6 of the prov-xg final report as a very first starting point (i.e. 
> initial, incomplete draft) for the work on a text about how provenance fits in 
> the Web architecture. If we agree on this proposal we can start arguing about 
> what is missing from that initial draft. If we don't agree, we have to come up 
> with another way of bootstrapping the work.
> 
>> I've just re-reviewed the Web Architecture section from Prov XG, and have
>> some  possible concerns with it.
> 
> I understand these concerns but I don't think they serve as reasons against 
> Proposal 1. In fact, it seems you already agreed to that proposal and started 
> doing what I suggested in Proposal 2, action 2.d   ;-)
> 
>> 1. The Web architecture considerations stated by the XG are veru narrowly
>> stated  in terms of a web of documents served by HTTP.  HTTP may be the
>> main Web protocol but it's not the only one; others can be used:
>> [...]
> 
> Okay. What do you suggest? Should we consider all possible protocols ? (no 
> offence ;-)  I think we should focus on HTTP because it is -as you write- the 
> main protocol.
>  
>> With RDF, URIs are often used to refer to things that cannot be retrieved
>> on the  Web; yet I think it may be important to be able to assign
>> provenance to such resources. Yet the XG report seems to say that
>> resources are those things for which representations can be retrieved
>> using HTTP.
> 
> For anything that cannot be retrieved on the Web (e.g. the Mona Lisa painting) 
> I don't see any difference between provenance information about that thing 
> (e.g. information about who draw the Mona Lisa painting or who brought it to 
> the Louvre) and any other kind of information about it. Furthermore, for these 
> things you can provide (or refer to) provenance information only in the same 
> way as you can do for other information about it on the Web. Hence, I don't 
> see a need to describe these possibilities in detail. That's why the XG report 
> focuses on the more interesting case of Web resources (things that can be 
> retrieved on the Web) where we have additional options to provide and refer
> to provenance information. However, I agree that the XG report is not very 
> clear about this.
>  
>> 2. I think that treating provenance as something that can be accessed via 
>> content negotiation on a resource URI, of that's what is being proposed,
>> is  plain wrong.
> 
> I agree. But that's not what the XG report argues for. It is not what we 
> wanted to imply with Sec.6.5 (which, I guess, is the part you are referring to 
> here).
> 
>> "By design, a URI identifies one resource. Using the same URI to directly 
>> identify different resources produces a URI collision."
>> -- http://www.w3.org/TR/webarch/#URI-collision:
>>
>> In this case, I would argue that provenance is a different resource from
>> the  entity to which it applies.
> 
> Absolutely.
> 
>> There was a vaguely similar issue raised by the IETF WebDAV working group,
>> who  introduced new HTTP methods for retrieving properties of
>> resources.  This became standardized despite some discussion about the
>> "URI collision" problem in the web architecture - two different resources
>> accessible only via a common URI. Digging for more background, I found
>> this:
>> -- http://lists.w3.org/Archives/Public/w3c-dist-auth/1998OctDec/0074.html
>>
>> I'm a bit hazy about how this played out, but there was some discussion of
>> this,  e.g.
>> -- http://lists.w3.org/Archives/Public/ietf-http-wg/2007JulSep/0184.html
>>
>> But rather than focus on the problems, I think there's something we can use
>> to  avoid these problems:
>> -- http://www.w3.org/TR/powder-dr/#assoc-linking
>> suggests several possible mechanisms;  I'm particularly thinking of the
>> HTTP  Link: header option, though the others might have a place too.
> 
> The four methods described in the POWDER document are possible implementations 
> of some of the options in the XG report: In the "Provenance Passing" dimension 
> all four methods fall under the category "Passing by Reference". In the 
> "Embedding Provenance" dimension the HTTP Link Headers method is in the 
> category "Embedded at the HTTP Level" and the three other methods are 
> "Embedded in the Representations".
> 
> Greetings,
> Olaf
>

Received on Wednesday, 18 May 2011 21:51:10 UTC