- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 28 Jul 2011 14:15:11 +0100
- To: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- CC: public-prov-wg@w3.org
In the general case, if you don't control the generation of the HTML, it's the same problem as an image. There's nothing more we can do. If you do control generation of the HTML, then <link> can give you the provenance resource. But I see that you may also need an identifier for the HTML to interpret that provenance (and the rest of this response addresses just that issue). ... I see two, maybe three possibilities: (a) rely on some unspecified mechanism here - i.e. don't specify a specific mechanism for this case. (b) add something to the HTML to identify the resource it represents. (Off the top of my head, this could be <meta>, <link>, or RDFa - I'm sure there are other options.) (c) adopt a packaging mechanism that can combine arbitrary data and metadata. (d) ... maybe something else. I think the scenario alone isn't enough information to make a sensible choice here - which to be useful has to be one that developers will actually implement. If I were forced to make a choice now, I'd go with (a) or maybe (b) with a <link> element and a new link relation roughly for "self". The packaging approach would solve more problems generally, but I don't think we know enough to make a call on a specific mechanism that would effectively promote interoperability, and there's enough defined mechanism (cf. http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html#gap-analysis) for developers to do something that would work right now. #g -- Luc Moreau wrote: > > > Hi Graham, > > I guess that D7 is the case I was after. > Note that D7 is not an image but an html file. Where do I find its > identifier? > > Luc > > On 07/28/2011 11:26 AM, Graham Klyne wrote: >> I've added a scenario analysis appendix to the PAQ document at >> http://dvcs.w3.org/hg/prov/raw-file/be3b7e1f2518/paq/provenance-access.html >> >> >> The short answer to this issue is that I believe there are some >> matters that are beyond the scope of a W3C specification document. >> The mechanisms described (or with placeholders for fuller description) >> could form the basis for applications that need to deal with, say, >> data provided on a USB drive, but a complete specification would IMO >> be inappropriate. >> >> e.g. >> [[ >> S: this scenario effectively calls for this: given an arbitrary data >> resource, implement a general purpose application to discover, >> retrieve and analyze provenance about that resource. At the present >> time, this is a matter for experimental development, which could be >> based substantially on the mechanisms described for provenance >> discovery and access via third party services. >> ]] >
Received on Thursday, 28 July 2011 13:36:05 UTC