- From: Luc Moreau <L.Moreau@ecs.soton.ac.uk>
- Date: Tue, 29 May 2012 12:19:41 +0100
- To: public-prov-wg@w3.org
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