W3C home > Mailing lists > Public > public-prov-wg@w3.org > June 2012

Re: ISSUE-385: hasProvenanceIn: finding a solution

From: Paul Groth <p.t.groth@vu.nl>
Date: Sun, 3 Jun 2012 19:43:45 +0300
Message-ID: <CAJCyKRpayfaXJGfYjtKrnoKGt36zW8AfFNcXpgnhP2DCVhsEwg@mail.gmail.com>
To: Jun Zhao <jun.zhao@zoo.ox.ac.uk>
Cc: Luc Moreau <L.Moreau@ecs.soton.ac.uk>, "public-prov-wg@w3.org" <public-prov-wg@w3.org>
Jun,

My idea was that the provenance recorded at in the bundle for that
entity would be for a specific period of time For example, I might use
a series of bundles to capture progressively larger chucks as for
example my program executed. So I could find provenance for the entity
from time t1 -> t2 in bundle1 and from t2 -> t3 in bundle2

It's not a completely fleshed out idea but I can imagine wanting to
qualify locatedin for a number of reasons.

cheers
Paul

On Sun, Jun 3, 2012 at 12:36 AM, Jun Zhao <jun.zhao@zoo.ox.ac.uk> wrote:
> Paul,
>
> At first sight, I loved your proposal. But after reading into it, I got less sure.
>
> This property is to allow locating the bundle in which the provenance of an entity is described. To qualify this, would it mean that, e.g, there is a time period during which you can find provenance of that entity in the bundle and after that you can't?
>
> Although the pattern you propose makes sense, I can't see when people need to qualify this relation. If you have a more concrete example in mind, I am ready to be convinced!
>
> Cheers,
>
> Jun
>
> Sent from my iPad (sorry for the brevity)
>
> On 1 Jun 2012, at 17:03, Paul Groth <p.t.groth@vu.nl> wrote:
>
>> Hi All,
>>
>> It seems that a one approach would be to define an extensible version
>> of hasProvenanceIn and leave it at that.
>>
>> hasProvenanceIn(id, entity, bundle, attrs).
>>
>> Like all our extensible relations, we would also have the straight
>> binary version
>>
>> hasProvenanceIn(entity,bundle)
>>
>> This would allow for the extensibility to cater for Luc's use case but
>> also for other use cases where extension is nice. For example, I can
>> imagine a system wanting to put a time constraint on the applicability
>> of provenance in a bundle to an entity.
>>
>> This would leave it up to people to define specialization, alternate
>> and derivation relations between entities as they want.
>>
>> Would this be acceptable to the group?
>>
>> Thanks
>> Paul
>>
>>
>>
>> On Fri, Jun 1, 2012 at 5:33 PM, Luc Moreau <L.Moreau@ecs.soton.ac.uk> wrote:
>>> Hi Simon,
>>>
>>> Thanks for your message. I feel you don't directly respond to the points
>>> that I raised,
>>> and therefore all my comments stand.
>>>
>>> I respond to your points below.
>>>
>>> On 06/01/2012 03:39 PM, Miles, Simon wrote:
>>>> Hi Luc,
>>>>
>>>> I will try to articulate the points which I think back up the binary relations proposal.
>>>>
>>>> 1. As I understood, there is currently no semantics to a bundle. A querier can choose to consider the descriptions in the bundle or not (based on the bundle's provenance), but whether there are one or many bundles, the querier just has a set of PROV descriptions. The bundles need to be found and known to be relevant, which is why hasProvenanceIn (or isTopicOf) is needed. After that, which bundle a description is in is irrelevant and the bundling can be ignored. A specific extension of PROV may change this by adding semantics to bundles, but this is not in the current specification.
>>>>
>>>>
>>>
>>> A close notion to bundle in prior provenance art is opm:Account, and
>>> there is plenty of evidence
>>> that merging accounts may lead to contradictions.  PROV, rightly so,
>>> does not define a union operator
>>> over bundles, and is silent about merging or not bundles.
>>>
>>> Therefore,  there is nothing in PROV that backs this statement "which
>>> bundle a description is in is
>>> irrelevant and the bundling can be ignored".
>>>
>>> You are suggesting that an extension of PROV may add semantics to
>>> bundles: that's exactly what you
>>> have done, by implying they are mergeable.
>>>
>>>> Taking the statements from the three bundles below, a querier would end up with:
>>>>
>>>>  activity(ex:a1, 2011-11-16T16:00:00,2011-11-16T17:0:00)
>>>>  wasAssociatedWith(ex:a1,ex:Bob,[prov:role="controller"])
>>>>  activity(ex:a2, 2011-11-17T10:00:00,2011-11-17T17:0:00)
>>>>  wasAssociatedWith(ex:a2,ex:Bob,[prov:role="controller"])
>>>>  agent(tool:Bob1, [perf:rating="good"])
>>>>  agent(tool:Bob2, [perf:rating="bad"])
>>>>
>>>> I can see nothing in the current specification to suggest this means anything different to when these descriptions are separated into multiple bundles. Do you agree?
>>>>
>>>>
>>>
>>> PROV does not specify whether they mean something different or not.
>>>
>>>> 2. If there are two entity identifiers relating to the same thing/entity, we need to say how they are connected: either alternateOf, specializationOf, or possibly some external relation such as owl:sameAs. While the example below happens to imply a specialisation relation between tool:Bob1 and ex:Bob, there is no reason to believe this is true in all cases: alternateOf is just as possible. So, hasProvenanceIn cannot imply or be a sub-type of either specializationOf or alternateOf, the appropriate one must be asserted separately.
>>>>
>>>
>>> I agree that being able to assert subtypes for hasProvenanceIn is
>>> important: that why I am
>>> in favour of having hasProvenanceIn a n-ary relation that includes
>>> attributes so that prov:type can be
>>> used for what you suggest.
>>>> 3. The same thing described from different perspectives has multiple identifiers regardless of bundles, i.e. at least one for each entity. When a bundle is newly read by a querier interested in the provenance of entity E, they should consider every entity E is a specialisation of, and look for those identifiers as well. If they don't, they will miss information about the provenance of E described at a coarser granularity.
>>>>
>>>> For example, ex:Bob may be a specialisation of ex:GeneralBob, and bundle ex:run1 might describe something about ex:GeneralBob's provenance. This makes "hasProvenanceIn(tool:Bob1, ex:run1, ex:Bob)" strange, because it is not only ex:Bob that is relevant to look for in ex:run1.
>>>>
>>>> Separating concerns, I'd argue it is preferable to say:
>>>>  hasProvenanceIn(tool:Bob1, ex:run1)
>>>>  specializationOf(tool:Bob1, ex:Bob)
>>>>  specializationOf(tool:Bob, ex:GeneralBob)
>>>>
>>> But this latter statement would belong to the ex:run1 bundle I assume.
>>> It is not going to be known to be relevant to me until I have correctly
>>> been able to link tool:Bob1 to ex:Bob in run1.
>>>
>>>
>>>> and let the que



-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
Knowledge Representation & Reasoning Group
Artificial Intelligence Section
Department of Computer Science
VU University Amsterdam
Received on Sunday, 3 June 2012 16:44:16 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:15 UTC