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

Luc,

I'm finding this discussion is becoming too spread out, so I'm going to try and 
collect together the salient points.

 >> In my approach, retrieve bob:bundle4 to access provenance about alice:report1,
 >
 > But how can you, since alice:report1 is not in bob:bundle4?
 >
>> *then* use the specializationOf information to infer that provenance for ex:report1 is also true for alice:report1.

OK, I should have said "retrieve bob:bundle4 to access provenance about 
ex:report1" there.  The rest stands.

 > I don't think that I do any inference. I just use a mechanism to retrieve
 > bundles (i.e. graphs), navigate within graphs,
 > and jump across graphs (using the proposed hasProvenanceIn relation, and
 > target). This is exactly incremental navigation
 > described in the PAQ and provided by some provenance stores (e.g. pasoa).

I think the objection to my use of "inference" is a separate issue.  Let me try 
and restate my basic position without using the dreaded "i"-word.

To my mind, the provenance data model is just that - a *data model* for 
organizing provenance information.  It is not describing an operational platform 
for processing provenance information.  As such, I think that describing 
incremental navigation is out of scope for DM.  (By contrast, PROV-AQ *is* a 
description of operational processes on provenance, and takes considerable care 
to *not* try and describe the provenance model itself.)

You have presented a case in which the operational process could be guided by 
information in the provenance model, by adding an extra field to the 
prov:hasProvenenceIn relation.  I argue that it's inappropriate to add structure 
to PROV-DM simply to match a feature in an operational description of provenance 
processing; I think one of the following holds:

(a) the provenance data model already contains information that can be used to 
guide the incremental discovery process.  If so, that's all well-and-good.  I 
was suggesting that the prov:specializationOf relation could provide such 
information - maybe that wasn't the right line to take, but I still think the 
mechanisms I outlined are reasonable.

OR

(b) the issue of incremental discovery is out of scope for PROV-DM.

What I think we should *not* do is add things to PROV-DM purely to support 
operational concerns (like incremental discovery).  That would be to have the 
tail wagging the dog.

#g
--

Received on Wednesday, 30 May 2012 09:00:53 UTC