Re: PROV-ISSUE-447: subactivity relation [prov-dm]

Hi Stian,

This thread is just showing that there are lots of complex issues,
which will lead to long discussions on formalizing a set of constraints,
if we want to integrate a notion of subactivity in prov.

I agree it's a useful notion ... like probably lots of others, which we
have not included in prov.

I only see one reasonable outcome:

1. Keep our prov specifications unchanged
2. Suggest in our faq/response that dcterms:hasPart may be useful.

Luc


On 09/11/2012 03:55 PM, Stian Soiland-Reyes wrote:
> On Mon, Sep 10, 2012 at 12:12 PM, Luc Moreau <l.moreau@ecs.soton.ac.uk> wrote:
>
>> My point was to illustrate an issue with subactivity and event ordering .
>> An equivalent situation can be constructed without explicit reference
>> to time:
>>
>> wasGeneratedBy(gen1; e1,a2,-)
>> wasDerivedFrom(der; e2,e1,-)
>> wasGeneratedBy(gen2; e2,-,-)
>> wasStartedBy(start1; a1,e2,-,-)
>> wasStartedBy(start2; a2,-,-,-)
>> Constraints:
>>
>> start2 <= gen1 < gen2 <= start1
>>
>> subActivityOf(a2,a1)
>>
>> start1 <= start 2
> I understand; the above should not be allowed by the constraints - but
> to do that the constraint would need to add the start1<=start2 (and
> end1 >= end2) constraints.
>
> I don't think this is much different from the constraints
> specialization-generation-ordering and
> specialization-invalidation-ordering, so I think we just need the
> equivalent of that for subactivities. If we did not have those two
> constraints, I could do an equivalent impossibility loop:
>
> wasGeneratedBy(e2, a1)
> wasStartedBy(a1, e1)
> specializationOf(e1, e2)
>
>
>
>> That's a good question. I personally was opposed to memberOf
>> to be part of PROV ... but no need to come back to this decision.
> I did not mean memberOf, but specializationOf, which you suggested. :)
> (I don't view memberOf as containment or nesting).
>
>
>> The difference however is that I don't necessarily see these event
>> constraints to be necessary for memberOf. So, it's OK.
> No, but we do need specialization-generation-ordering and
> specialization-invalidation-ordering. For subActivityOf we would need
> the equivalent for activity specialisation.
>
> My argument is that we have recognized that entities can be described
> at different granularities and reflect this with specializationOf and
> alternateOf - but why do we not recognize that activities can be
> described at different granularities? Just because it's hard?
>
>
>> My view is that in our formal response to this issue (and potential in our
>> FAQ if we create one), the working group can *suggest* the use of
>> dcterms:hasPart.
> I think that if we agree to not have a concept of subactivities or
> activity specialization, this might be a workable solution; there
> should not be any implications on the PROV data model of such a
> dcterms:hasPart statement (unless you choose to interpret it that way
> - but then you will have to make your own constraints).
>
>
>
>>> It still raises the question about entities generated by both
>>> activities and the generation-uniqueness constraint.
> (long rant to be ignored as I had not understood the new
> generation-uniqueness constraint).
>
>

-- 
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, 12 September 2012 14:13:27 UTC