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

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