Re: PROV-ISSUE-454 (key across relations/objectss): can the same identifier be used for different relations objects [prov-dm-constraints]

I created ISSUE-458 to track this specific concern.

Luc


On 07/20/2012 08:44 AM, James Cheney wrote:
> OK.  The irreflexivity constraint was an attempt to address Tim and Tom's concerns, so they should comment on whether your example persuades them that it is not irreflexive.
>
> My inclination would be that influence and communication should be irreflexive, so this is no problem.
>
> But if we also allow the generation-use-communication inference, then from the totally reasonable:
>
> wasGeneratedBy(e,a)
> used(a,e)
>
> we could infer wasInformedBy(a,a) and then wasInfluencedBy(a,a), which would be invalid if influence has to be irreflexive.
>
> Overall, I think this makes a persuasive argument for dropping generation-use-communication and keeping irreflexivity of influence (and all this entails).
>
> However, my suggestion is to leave all of these potential inferences in for review and see if there are clear directions from reviewers as to which ones are intuitive.  If there is debate about this, drop it.
>
> It is also clear that this has nothing to do with the original issue (about keys/uniqueness of ids within relations).  So perhaps a new issue should be raised against impossible-influence-reflexive.
>
> --James
>
> On Jul 20, 2012, at 6:19 AM, Luc Moreau wrote:
>
>> Hi James
>>
>> I don't think impossible-influence-reflexive holds.
>>
>> wasInformedBy(a,a)
>> wasGeneratedBy(e,a)
>> used(a,e)
>>
>> Implies
>>
>> wasInfluencedBy(a,a)
>>
>> The irreflexivity of derivation comes from the strict precedes on the generation of entities. As flagged before, I am not sure we want this.
>>
>>
>>
>> Professor Luc Moreau
>> Electronics and Computer Science
>> University of Southampton
>> Southampton SO17 1BJ
>> United Kingdom
>>
>> On 19 Jul 2012, at 18:33, "James Cheney" <jcheney@inf.ed.ac.uk<mailto:jcheney@inf.ed.ac.uk>> wrote:
>>
>> OK, reflecting on the discussion, there are really two underlying issues:
>>
>> 1.  Can entities, agents, and activities, or relations overlap with each other?
>>
>> Proposed fixes:
>>
>> - Allow overlap between entity and agent and between entity and activity; forbid overlap between entity and activity ids.  (entity-activity-disjoint)
>>
>> [Tim, this is stated in PROV-DM and apparently enforced in PROV-O already; even so, I think it should be explicit in PROV-CONSTRAINTS for completeness.]
>>
>> - Forbid overlap of id's between {entity, agent, activity} and {all other identified relations} (impossible-object-property-overlap).
>>
>> - Forbid overlap of id's between the strict subproperties of wasInfluencedBy.  That is, an id can appear in (e.g.) used and wasInfluencedBY, but not used and wasGeneratedBy.  (impossible-property-overlap)
>>
>>
>> 2.  Can something that happens to be both an entity (or activity) and an agent influence itself?  (In fact this is somewhat orthogonal to disjointness).  (This is actually unrelated to disjointness because it is already possible to assert entity(e) and wasInfluencedBy(e,e).)
>>
>> Proposed fix: Assert that influence is irreflexive. (impossible-influence-reflexive)
>>
>>
>> These constraints have been gathered in a new subsection of the Constraints section, called Impossibility Constraints.
>>
>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#impossibility-constraints
>>
>>
>> This issue is (still) marked pending review; I will ask about it in the review questions rather than try to close it now.
>>
>> --James
>>
>> Does this resolve the issue?
>> On Jul 19, 2012, at 5:46 PM, Timothy Lebo wrote:
>>
>> Tom,
>>
>> On Jul 19, 2012, at 5:57 AM, Tom De Nies wrote:
>>
>>
>> We (I thought) want to allow for the possibility that something is both an agent and an entity, or both an agent or an activity, or other combinations.  One could then state that something influences, generates, uses itself etc., but this will just violate ordering constraints that we already have.
>>
>> Seems fair enough to me, but then we are implicitly assuming that when an agent and an entity have the same id, they are the same thing, no?
>>
>> Yes, and this would be true for anything you've given an identifier.
>>
>> Then what happens when an activity and entity have the same id?
>>
>> Bad things.
>>
>> Or an agent and an activity?
>>
>> Nothing.
>>
>>
>> Again, my concern lies with the fact that we can assert
>>
>> entity(a1)
>> agent(a1)
>>
>> ^^ these two are disjoint.
>>
>> activity(a1)
>>
>> ^^ no problems as long as one of the above is removed.
>>
>> influencedBy(a1,a1)
>>
>> ^^ perhaps this should be irreflexive?
>>
>> -Tim
>>
>>
>> which is ambiguous to say the least...
>>
>> - Tom
>>
>>
>> 2012/7/18 James Cheney <jcheney@inf.ed.ac.uk<mailto:jcheney@inf.ed.ac.uk>>
>> HI,
>>
>> Again, I don't see the need for an explicit issue about this.
>>
>> There is currently no constraint enforcing disjointness among different kinds of things/relations.  I see no particular reason to add one (and make implementation harder), unless there is clear consensus that violating such constraints is always nonsensical (and that this isn't detected by other constraints).
>>
>> We (I thought) want to allow for the possibility that something is both an agent and an entity, or both an agent or an activity, or other combinations.  One could then state that something influences, generates, uses itself etc., but this will just violate ordering constraints that we already have.
>>
>> I agree it seems nonsensical to allow overlap between different relations, and if so then someone needs to write constraints that do this.
>>
>> Constraints of the form "if hyp1 .... hypn then FALSE" (i.e., a given conjunctive pattern is impossible" are straightforward to handle: we just handle all the other inferences and constraints first, then check that the normal form does not have any of the forbidden patterns.  (The irreflexivity and asymmetry inferences for specialization already do this implicitly.)
>>
>> --James
>>
>> On Jul 18, 2012, at 10:39 AM, Tom De Nies wrote:
>>
>> The only problem I see with allowing it, is when using influencedBy.
>>
>> With influence you'd be allowed to assert this:
>>
>> agent(a1)
>> activity(a1)
>> influencedBy(a1,a1)
>>
>> - Tom
>>
>> 2012/7/18 Provenance Working Group Issue Tracker <sysbot+tracker@w3.org<mailto:sysbot+tracker@w3.org>>
>> PROV-ISSUE-454 (key across relations/objectss): can the  same identifier be used for  different relations objects [prov-dm-constraints]
>>
>> http://www.w3.org/2011/prov/track/issues/454
>>
>> Raised by: Luc Moreau
>> On product: prov-dm-constraints
>>
>>
>> We have the following two uniqueness constraints.
>>
>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#key-object
>> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-constraints.html#key-relation
>>
>> It is not clear to me if
>>
>> entity(e123)
>> agent(e123)
>>
>> are acceptable. (To me, they should be, since we don't state the set of agents to be disjoint from any other set)
>>
>> Likewise, can we write
>>
>> used(event1234,a1,e1,attrs1)
>> and
>> wasGeneratedBy(event1234,e2,a2,attrs2)
>>
>> Probably not.
>> Note: if we allow the two above, then I am not sure that strict ordering is wise in ordering constraints.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>>
>>
>>
>> The University of Edinburgh is a charitable body, registered in
>> Scotland, with registration number SC005336.
>>
>

-- 
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 Friday, 20 July 2012 08:09:29 UTC