- From: Graham Klyne <GK@ninebynine.org>
- Date: Thu, 28 Jul 2011 13:40:20 +0100
- To: Provenance Working Group WG <public-prov-wg@w3.org>
I believe this is addressed by section 3.4 (http://dvcs.w3.org/hg/prov/raw-file/tip/paq/provenance-access.html#third-party-services), which addresses precisely the use-case described by this issue. Specifically, if I have the URI of a third party provenance service, and a URI or identifying information about the target resource, a SPARQL query can be constructed to locate the required provenance URI and/or data from that third party. I think availability of such information is pretty much a prerequisite for creating any kind of third party provenance service - I can't see how it might work without that. I think this may have more to do with discussion around ISSUE 46 (http://www.w3.org/2011/prov/track/issues/46) - the extent to which the provenance information itself identifies the entity whose provenance it describes. #g -- Provenance Working Group Issue Tracker wrote: > PROV-ISSUE-47 (third-party-provenance): How to obtain provenance from a third party known by the user [Accessing and Querying Provenance] > > http://www.w3.org/2011/prov/track/issues/47 > > Raised by: Luc Moreau > On product: Accessing and Querying Provenance > > I don't understand how the proposal allows us to address http://www.w3.org/2011/prov/wiki/ProvenanceAccessScenario. > > Specifically, I consider the case where the user wants to access provenance from a third-party they know (e.g. a favorite consumer group). > > Using section 3, I can obtain one or more provenance-uris, which are known from the responding server or the document creator. > > If my third-party is not known by the responding server or document creator, I have no mechanism to obtain a provenance-uri since I don't have have an identifier for the document I currently hold. > > A solution could be: we need a BOB-identifier to be passed around (as suggested in ISSUE-46) and a mechanism that resolves a BOB-identifier to provenance-uri. > > > >
Received on Thursday, 28 July 2011 12:59:11 UTC