Re: PROV-ISSUE-29 (mutual-iVP-of): can two bobs be mutually "IVP of" each other [Conceptual Model]

Hi,

Your suggestion of specifying as little as possible in the constraints documents is fine with me.

I think we should have the discussion about what things mean and whether transitivity etc. hold later, as I update the semantics.

Detailed comments below.


On Apr 2, 2012, at 10:32 AM, Luc Moreau wrote:

> Hi James,
> 
> To be specific, I am not trying to start yet another debate on this, I am
> looking for guidance on how to complete/edit:
> 
> http://dvcs.w3.org/hg/prov/raw-file/default/model/prov-dm-constraints.html#component4
> 
> Concrete suggestions welcome.
> 
> Thanks,
> Luc
> 
> On 04/02/2012 10:27 AM, Luc Moreau wrote:
>> 
>> Hi James,
>> 
>> I am not trying to defend one point of view or the other, but I seek some guidance
>> about what to write in part II, which should be released by end of the day.
>> 
>> Taking my editor's hat off: my view is that we should not specify any of these properties
>> in our documents, and we should see what the community does with the relations.
>> 
>> Editor's hat on, further comments below:
>> 
>> 
>> On 04/02/2012 09:58 AM, James Cheney wrote:
>>> 
>>> Hi Luc,
>>> 
>>> The point of having each Entity mapped to a (unique) Thing in the semantics is to avoid this kind of confusion.  
>>> 
>>> I did it this way precisely because of examples like this, and because of I thought there was a rough consensus that specialization 
>>> 
>> ... that specialization ...?? is transitive you mean?
>> 

Sorry, yes.  Email before coffee.  From Graham's and Paolo's discussion (and from the reaction to my attempt to formalize this at F2F2.)

>> 
>>> If you think the formal semantics as is mismatches the data model/constraints and should not do this, please raise an issue on it and we can discuss it.
>> 
>> I have no view about it. The english definition does not disallow for my interpretation.  So, something
>> needs to be changed somewhere.
>> 
>> My reading of Jim and Stian's messages is that transitivity does not hold, but apologies if I have misread.
>> 

This is why I have been asking people who think it isn't transitive to read the semantics and comment.  I think the belief that it may not be transitive arises from confusion between things and entities (which I think is the same confusion Ted has been enunciating).

It's important to point out that this is inherently confusing; I think whatever terminology we use there is danger for confusion.  The English words we use are vague, and IMO the best way to fight this is by introducing a formalism that makes precise what we are talking about.


>>> 
>>> Considering your (brief) example (I think I am restating Stian's response in more formal terms):
>>> 
>>> So there are two things:
>>> 
>>> thing1 = woman in red
>>> thing2 = man in black
>>> 
>>> I'll assume their lifetimes both include t1,t2.  From t0 to t1, thing1 is in the chair, then thing1 leaves and thing2 gets in the chair at t2.
>>> 
>>> If you have one "entity"
>>> 
>>> ent0 = person on chair at times [t1,t2]
>>> 
>>> then there can't be a single thing that the entity maps to, i.e., it's not allowed in the semantics.
>> 
>> is it the consensus?  
>> how do we modify the english definition to reflect this?

I see no reason to stipulate this prematurely.  I should have said that my statements reflected the view taken in the semantics (which I thought reflected a reasonable interpretation of what was in WD3), not that I expect everyone to agree.  It is, however, frustrating that we only find out about these differences of opinion at the last minute, when the draft of the semantics has been up for over a month now.  I guess I haven't been insistent enough about asking people to point to it and attention has been elsewhere.

>>> 
>>> You need two entities 
>>> 
>>> ent1 = person on chair at time t1
>>> ent2 = person on chair at time t2
>>> 
>>> Note that officially, we are not required to give ent1 and ent2 different attributes (or any attributes at all), but if we intend them to denote different things
>>> 
>>> Incidentally, the example you gave has nothing at all to do with specialization: specialization is a relation on entities, not things, and the two entities ent1 and ent2 are not specializations of each other, nor is ent1 or ent2 a specialization of ent0 (or vice versa).  Ent0 is not even a sensible entity anyway.  So, in my view your example is not a use case for allowing entities to refer to multiple things.
>> 
>> I am not sure which example you refer to.

The example of people in chairs.  I don't see how it has anything to say about transitivity of specialization (or at least, it doesn't give me a reason to believe it shouldn't be transitive).


>> But surely, thing1 and thing2 can also be regarded as entities!
>> 

The formal semantics distinguishes between entities, as time-bounded snapshots of things where some properties are fixed, vs. things whose properties can change.

Suppose the man in black is called Jack and the woman is Jill.  We could then have two entities

ent1' = Jill over her whole lifetime
ent2' = Jack over his whole lifetimr

Then ent1 is a specialization of ent1' and ent2 is a specialization of ent2'.

BUT, ent1' is not a *substitute* for thing1 and ent2' is not a substitute for thing2.  The reason is that the entities can only give us attribute values that are fixed over the whole lifetime of the respective things. A single entity can't represent changing attribute values.

In principle (assuming that times and attribute values are discrete), we can represent a thing by a (potentially infinite) set of entities that describe the value of each attribute at each time point or sub interval of the thing's existence.  We could, if we want, regard this collection of entities (linked by the transitive closure of alternateOf and specializationOf) as a thing.  That is, the thing "Jane" is the collection of all entities that describe some aspect of Jane over some interval, linked by appropriate specialization and alternate relations.  (This is essentially Paolo's lattice idea.)  Since I don't say what Things are in the semantics, they could be such collections.

I find the approach with explicit Things clearer (and it provides a more direct rationalization of why specialization would be transitive) but perhaps we should give both views since I think some people are uncomfortable with Thing.

However, the fact that one can use a sufficiently general entity as a "placeholder" for a thing does not mean we can do without things entirely.  We need some way to rationalize the fact that two people can be in the same chair at different times.

>>> 
>>> I see absolutely no point to or motivation for allowing an entity to refer to more than (or less than) one thing.  
>>> 
>> So, still trying to understand, if it's the case, what is the point of talking about things?
>> Shouldn't the English definition of these concepts be expressed without the term 'thing'?

The point is that (we agreed that) entities have to have fixed attribute values, so that we can describe them using data, but we want to describe "things that can change over time".  Thing is meant to capture this.

However, at F2F2 when this issue arose I thought the resolution was that the DM documents would confine attention to entities, activities etc. and at most give informal intuitions, leaving any formal discussion of things (and maybe related properties) to the semantics.  

That is what I thought you were going to do, and that would be fine with me.  In my opinion that makes it difficult to offer an argument for why the relations should/shouldn't have various properties.  

To be clear, I would also be fine with saying "Intuitively, an entity refers to a unique thing, and the attributes of the entity describe the attributes of the thing over the lifetime of the entity.  Two entities are alternates if, intuitively, they refer to the same thing at overlapping times, whereas an entity is a specialization of another if they refer to the same thing and one provides more information than the other." 

I think we will probably need to iterate the semantics and constraints document to make sure the properties and terminology in both are consistent.

--James