Re: Kickstarting the Provenance Access and Query Task Force

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 15:16:52 UTC