RE: PROV-ISSUE-385 (haProvenanceIn-complexity): The hasProvenbanceIn relation is over-complicated [prov-dm]

I tend to agree with Graham and Jim.

The hasProvenanceIn relation is not a description of provenance, it is about locations of provenance data. It seems unnecessary to apply the same rules as for relations describing the past.

In particular, I'm not clear how attributes should be interpreted for hasProvenanceIn: attributes of what? If we mean metadata about the bundle pointed to, e.g. its format, I think this goes beyond provenance and would ideally be left to serialisations to appropriately address.

Having an ID makes sense for entity(), activity(), agent() etc. because we are giving an identifier to something referred to in other PROV descriptions. I'd argue we don't need a general rule of identifying every description, because it's not obviously about provenance and any given serialisation could easily do that where required.

I agree with Jim that it seems important to use alternateOf here: this seems like the situation that specialisationOf/alternateOf were really designed for. Linked bundles with different IDs for the same entity seem most likely where different asserters provide provenance on the same entity or one asserter provides different accounts of the provenance of an entity. Each bundle then takes a particular perspective on the entity. Where we can be more precise and say one bundle's perspective is a specialisationOf the other, that is even better.

thanks,
Simon

Dr Simon Miles
Senior Lecturer, Department of Informatics
Kings College London, WC2R 2LS, UK
+44 (0)20 7848 1166

accounting for the reasons behind contractual violations:
http://eprints.dcs.kcl.ac.uk/1283/

________________________________
From: Jim McCusker [mccusj@rpi.edu]
Sent: 28 May 2012 21:59
To: Luc Moreau
Cc: public-prov-wg@w3.org
Subject: Re: PROV-ISSUE-385 (haProvenanceIn-complexity): The hasProvenbanceIn relation is over-complicated [prov-dm]

Can't that be decomposed into:

hasProvenanceIn(ex:report1,bob:bundle4)
alternateOf(alice:report1, ex:report1)

?

We should focus on re-using constructs rather than implicitly re-introducing them into relations like this. Especially since the idea of a target is entirely optional, as bob and alice may already be using the same URIs.

Jim

On Mon, May 28, 2012 at 4:26 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk<mailto:L.Moreau@ecs.soton.ac.uk>> wrote:
Hi Graham,

Like PROV-AQ, we need a target.
Example 47 illustrates the need for it:

 hasProvenanceIn(alice:report1, bob:bundle4, ex:report1)

In the current bundle, there is a description for alice:report1.
More provenance can be found for it in bundle bob:bundle4, under the name ex:report1.


The presence of attributes and id follow the pattern of other qualified relations.

Luc


On 28/05/12 20:01, Provenance Working Group Issue Tracker wrote:
PROV-ISSUE-385 (haProvenanceIn-complexity): The hasProvenbanceIn relation is over-complicated [prov-dm]

http://www.w3.org/2011/prov/track/issues/385

Raised by: Graham Klyne
On product: prov-dm

I'm raising this issue as a placeholder and for discussion.  I didn't notice the arrival of prov:hasProvenanceIn, but based on its appearance in http://dvcs.w3.org/hg/prov/raw-file/default/model/releases/ED-prov-dm-20120525/prov-dm.html (which AFAIK is not a currently active draft, but a proposal) is rather over-complicated and a bit obscure.

My sense is that, especially as this is motivated by PROV-AQ, there are just too many identifiers floating around.

Instead of:

  hasProvenanceIn(id, subject, bundle, target, attrs)

Why not just:

  hasProvenanceIn(subject, bundle)

Where subject is based on the URI of an entity, and bundle is based on the URI of a provenance bundle with information about that entity.

I would like to understand what  real scenario justifies all the added machinery that has been included with this relation.









--
Jim McCusker
Programmer Analyst
Krauthammer Lab, Pathology Informatics
Yale School of Medicine
james.mccusker@yale.edu<mailto:james.mccusker@yale.edu> | (203) 785-6330
http://krauthammerlab.med.yale.edu

PhD Student
Tetherless World Constellation
Rensselaer Polytechnic Institute
mccusj@cs.rpi.edu<mailto:mccusj@cs.rpi.edu>
http://tw.rpi.edu