Re: Tim's approach on Involvement

Hi Khalid!

2012/2/21 Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>

>
> Bundle: This construct does not exist in prov-dm W3. We need to replace it
> by RecordContainer, or Container.
>
I think we should leave Bundle. Why add RecordContainer if we are going to
replace it in the next version?

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

Yes, you seem to have sent this email when I was writting mine :)

>
> 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.
>
I'd say no. If I act in behalf of Khalid in an activity does not mean that
someone acting on behalf of me in another activity is acting on behalf of
Khalid!

> - 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.
>
What I understood is that we would have one plan per association, but we
could have more than one association with a plan per activity.
Thus, I'd mark it as functional.

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

> - 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> <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
>
>
>
>
>
>
>
> Thanks,
Daniel