Re: Tim's approach on Involvement

Bundle: This construct does not exist in prov-dm W3. We need to replace 
it by RecordContainer, or Container.


Collection is missing, but I think Stian is working on it.


There is a property involved that seems to be used to create a 
hierarchichal structure at the level of object properties. The name of 
the property is misleading. Given the name "involved", I was expecting 
to find sub-properties that are defined in the context of involvement, 
but it seems to have as sub-properties binary properties that are 
defined outside involvement, like wasGeneratedBy. I think this can be 
misleading.


The ontology was modified since this morning, there is a new class 
AgentInvolvement. It seems to make sense. The class Start is not defined 
as sub-class of AgentInvolvement. Both Daniel and don't understand why.


The characteristics of the object properties are missing for most 
properties. Here I am trying to see if we can come to a consensus. 
Please see below the first 5 properties, and the characteristics of each 
one. These characteristics are not necessarily taken from prov-dm w3, so 
we should identify the ones that may be controversial and possibly avoid 
them. If the prov-o teams that specifying these characteristics is 
mandatory for the version we release to the rest of the working group on 
Thursday, then we need to identify the characteristics of the rest of 
properties.


* actedOnBehalfOf

- Functional: No. I think an agent can act on behalf of one or more agents

- Inverse functional: No. An agent can delegate responsibility to one or 
more agents.

- Transitive: (maybe) No.

- Symmetric: No.

- Asymmetric: No. If agent a1 acts ob behalf of agent a2 in the context 
of an activity a, then there is no thing that forbid that a2 acts on 
behalf of a1 in the context of another activity a'

- Reflexive: No.

- Irreflexive: Yes. An agent cannot on behalf of himself, or can he?


* activity

- Functional: Yes.

- Inverse functional: No. An activity may not be involved in any 
generation for instance.

- Transitive: No.

- Symmetric: No.

- Asymmetric: Yes.

- Reflexive: No.

- Irreflexive: Yes.


* adoptedPlan

- Functional: ?. Given the discussion of yesterday's provo telecon, we 
don't know yet, if an association can involve more than one plan.

- Inverse functional: No.

- Transitive: No.

- Symmetric: No.

- Asymmetric: Yes.

- Reflexive: No.

- Irreflexive: Yes.


* alternateOf

- Functional: No

- Inverse functional: No

- Transitive: No. For the moment. There are still discussion to see if 
this property can be defined as transitive.

- Symmetric: Yes.

- Asymmetric: No.

- Reflexive: Yes.

- Irreflexive: No.


* endedAt

- Functional: Yes.

- Inverse functional: No.

- Transitive: No.

- Symmetric: No.

- Asymmetric: Yes.

- Reflexive: No.

- Irreflexive: Yes.


* entity

- Functional: Yes

- Inverse functional: No

- Transitive: No

- Symmetric: No

- Asymmetric: Yes

- Reflexive: No

- Irreflexive: Yes


Khalid




On 21/02/2012 10:51, Khalid Belhajjame wrote:
> On 21/02/2012 10:31, Stian Soiland-Reyes wrote:
>> On Tue, Feb 21, 2012 at 04:58, Timothy Lebo<lebot@rpi.edu>  wrote:
>>
>>> I'm adopting your naming of the new properties (activity, entity, 
>>> qualified)
>>> Based on your lead, I deleted the subprops of qualified, which trims 
>>> the ontology up nicely, but I'm wondering how one figures out the 
>>> pattern.
>> This looks pretty good. Thanks for also updating ProvRDF. I'll go
>> through it with  my changes from below.
>>
>>
>>
>> I changed some of the equivalent classes to subclasses to avoid
>> unwanted side-effects.
>>
>> For instance we don't want to have Involvement to be equivalent with
>> hadSpatialExtent min 0 Location - because then it is equivalent to
>> owl:Thing (!)
>>
>> Inform is also an ActivityInvolvement.
> Yes.
>
>>
>> I put equivalence on ActivityInvolvement and EntityInvolvement to have
>> "activity some Activity" and "entity some Entity". Start is not
>> defined as either ActivityInvolvement or EntityInvolvement as it can
>> play double-role and might not always be both. (However it should be
>> either, so this is incomplete!)
>>
>>
>> Association is not equivalent to an involvement having entity to an
>> agent - it could just accidentally be an agent.
> Do you mean that we may have an instance of EntityInvolvement  that 
> does not denote an agent association and in which the entity involved 
> happens to be an agent? For example, an activity that used as input an 
> agent?
>
>>
>> However I introduced AgentInvolvement that requires the subclass (not
>> equivalent!!) "entity only Agent" - we could lax this to require
>> "entity only Agent" - but none of the subclasses would allow a
>> non-agent entity by my view.  This contains Association, Attribution,
>> End, Responsibility.
>>
>> I notice Derivation is no longer a subclass of Trace - but
>> wasDerivedFrom is subproperty of tracedTo. Any reason for not keeping
>> the same hierarchy for the involvement here?
>>
>>
>> I moved hadQuoterAgent and hadQuotedAgent to be subproperties of
>> entity - this is a special case of Quotation as we basically need
>> 'roles' for the 'entity' - this should be looked at later.
>>
>> I moved so hadOriginalSource is not a subproperty of wasAssociatedWith
>> (the source is not necessarily an agent)
>
> Yes. Agreed.
>
> khalid
>>
>>
>>
>
>
>