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

Hi Graham,

Responses interleaved.

On 05/30/2012 08:47 AM, Graham Klyne wrote:
> 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.

But again, how do you know where to find provenance for ex:report1.

You seem to have
hasProvenanceIn(alice:report1, bob:bundle4, -)
specializationOf(alice:report1, ex:report1)

This does not say which bundle I can find provenance for ex:report1.

>
> > 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.

I think we may put to much emphasis on 'incremental discovery' as per PAQ.

The PROV data model in effect specifies a distributed graph structure 
(distributed across bundles I mean here, services are a side issue).
To me, it is essential for the model to provide accurate linking across 
bundles so that the data structure can be navigated.
By accurate, I mean that I want to be able to link an entity in a bundle 
with another entity in another specific bundle.

Without it, bundles are effectively not usable, and very quickly we will 
see constructs like the one I suggest, to aid this navigation
of the graph, and we will have failed in achieving interoperability.



Luc





>
> #g
> -- 
>

-- 
Professor Luc Moreau
Electronics and Computer Science   tel:   +44 23 8059 4487
University of Southampton          fax:   +44 23 8059 2865
Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk
United Kingdom                     http://www.ecs.soton.ac.uk/~lavm

Received on Wednesday, 30 May 2012 09:42:03 UTC