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

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


-- 
Stian Soiland-Reyes, myGrid team
School of Computer Science
The University of Manchester

Received on Tuesday, 11 September 2012 14:56:41 UTC