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

Hi Graham

Response sinterleaved.

On 05/29/2012 10:53 AM, Graham Klyne wrote:
> OK, I'm looking more closely at the examples.
>
> In example 45, you introduce prov:service-uri as an attribute.  If the 
> PROV-N is supposed to be a domain neutral way of representing 
> provenance information, I'm not sure that it's appropriate to 
> introduce structures that are specific to access mechanisms.  To me, 
> it feels like a layer violation and scope creep in the purpose of 
> PROV-N, as it starts to tie it to specific technology (PROV-AQ in this 
> case).
>
I guess you mean PROV-DM and not the notation.

But I believe the PROV-AQ introduces properties such as  prov:hasProvenance.
If this is to be in the ontology, we also need it in other 
representations, and therefore, in the conceptual model.



> Example 46: looks sensible to me.  I note that this makes perfect 
> sense without using the type=prov:Bundle annotation.  I question 
> whether we really need this type annotation.  (I think I commented on 
> this in my review email to you.)

I still have to respond to this separately.
prov:Collection, prov:Plan, Prov:Dictionary, prov:Bundle are type 
information that can be inferred I believe.


>
> Example 47:  The only justification I see in in this use-case is that 
> "Alice may have decided to use a different identifier for 
> ex:report1".  The implication is that there may be some name-aliasing 
> permitted.  If this is a desired feature of PROV-N, I think it should 
> be treated separately as a first class feature, not snuck in an 
> obscure feature of prov:hasProvenanceIn.
>
> Actually, I suspect that's not really what you meant.  To make further 
> progress on this, I have to make an assumption (based on the appeal to 
> PROV-AQ).  In PROV-AQ, a provenance link may also indicate a different 
> target-URI from the original request URI.  The use case for this is 
> when the actual resource returned is a specialization of the resource 
> requested; e.g.
>
>    C: GET http://example.org/weather-in-london/today
>
>    S: 200 OK
>    S: Link: <http://example.org/LWP-20120529>;
>             rel=prov:Provenance;
>             anchor=<http://example.org/weather-in-london/20120529>
>
> If this is indeed the kind of scenario you intend to support, then I 
> thimnk the proper way to address this in example 47 would be:
>
> Original (included for reference, and in case the document changed):
>
>   bundle alice:bundle6
>     entity(alice:report1)
>     hasProvenanceIn(alice:report1, bob:bundle4, ex:report1)
>     entity(ex:report2, [ prov:type="report", ex:version=2 ])
>     wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
>     wasDerivedFrom(ex:report2, alice:report1)
>   endBundle
>
> Proposed revision:
>
>   bundle alice:bundle6
>     entity(alice:report1)
>     hasProvenanceIn(alice:report1, bob:bundle4, -)
>     specializationOf(alice:report1, ex:report1)
>     entity(ex:report2, [ prov:type="report", ex:version=2 ])
>     wasGeneratedBy(ex:report2, -, 2012-05-25T11:00:01)
>     wasDerivedFrom(ex:report2, alice:report1)
>   endBundle
>

Did you really mean
  hasProvenanceIn(alice:report1, bob:bundle4, -)
and not
     hasProvenanceIn(ex:report1, bob:bundle4, -) ?

This is equivalent to the suggestion that Simon  made in the same thread 
(example with tool rating agent performance).

The reason for introducing
     hasProvenanceIn(alice:report1, bob:bundle4, ex:report1)
was that alice:report1 was a dead end in the current bundle.
I needed to know where to go next in my incremental navigation.

By adding,
     specializationOf(alice:report1, ex:report1)
alice:report1 is no longer the end of the graph, but ex:report1 is.
So how do I know where to go next?

 > The thrust of what I'm saying here is that I think it's inappropriate 
for PROV-N to just mimic PROV-AQ - they operate at different levels - 
but (if >using PROV-AQ as a motivating guide) to represent the scenarios 
that might be addressed using PROV-AQ capabilities.

But if the information of where to go next has not been recorded 
somewhere in a provenance repository,
how can I make use of PROV-AQ?  I won't be able to indicate which 
provenance-uri/target-uri/etc to use.
The asserter of provenance descriptions has got the possibility of 
recording such a kind of information.

>
> This is what I meant when I posed the original question: "I would like 
> to understand what real scenario justifies all the added  machinery 
> that has been included with this relation."  Note the *real scenario* 
> here.
>
>


See tool rating agent performance example in the same thread.


> Example 48:
>
> I'm not sure what useful purpose is served by:
>
>   hasProvenanceIn(tool:r2, obs:bundle7, ex:report2)
>
> This says that provenance information about tool:r2 can be found in 
> obs:bundle7 under the name ex:report2.  But what *is* tool:r2 - all I 
> can see is a comment that it's a new identifier.  I really can't 
> figure what going on  here.  What I really need to know is what is the 
> relationship between tool:r2 and ex:report2.

It's funny how we get conflicting messages here.
Some group members were suggesting it was NOT right to reuse the same 
identifier ex:report2
to add the viz attributes.  Now, are you suggesting that I shouldn't use 
a different one?

The point is some users will mint new identifiers, others won't, and we 
need to be able to support this.


>
> My best guess here is that you are using the aliasing to fake a kind 
> of bundle import mechanism.  If that's what you are doing, and need, I 
> think that should be addressed as a separate, comprehensible feature.  
> This all feels a bit like Jensen's device 
> (http://en.wikipedia.org/wiki/Jensen%27s_Device) - very clever, but 
> ultimately obscure and unusable for almost all practical purposes.
>

The reference to Jensen's device is simply not relevant here.

Nowhere I suggested this is an import mechanism, though some may choose 
to see it as such, but
PROV will not say how to merge bundles.


Luc


> #g
> -- 
>
>
> On 28/05/2012 21:26, Luc Moreau 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.
>>>
>>>
>>>
>>>
>>
>

-- 
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 Tuesday, 29 May 2012 11:20:21 UTC