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

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

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

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

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.

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.


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.

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.

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

Received on Tuesday, 29 May 2012 09:57:58 UTC