Re: Tim's approach on Involvement

Hi all!,
I'm reviewing the last version modified by Stian, and now the ontology is
much easier to read. Here are my comments:

   - Where is the TimedInvolvement/Timed? We agreed yesterday about this
   term but I don't see it in the ontology.
   - Why the propery "tracedTo" is not a subproperty of "involved"? It
   relates an Element to an Element too.
   - Do we need "involved"? What is its use appart from creating a
   hierarchy?
   - @Stian: I don't see how Start could be an EntityInvolvement, could you
   please explain? It is weird to have "End" under
   activityInvolvement and not "Start" :)
   - I agree with Khalid in that "entity" and "activity" properties should
   be renamed. From a usability pov is confusing to use
   the same name for classes and properties (even if they are different
   URIs).
   - Are we going to delete the subproperties of "qualified"? On one hand,
   it leaves the ontology more simple, but on the other
   hand it may force us to do some filtering when querying the model.
   - Since qualified links an element to an Involvement, I think that we
   could use them wrong:
   :ent a prov:Entity;
         prov:qualified [ a prov:Usage;
                               prov:hadRole :role1]
   This is consistent according to our ontology (usage has some entities,
   but in the open world assumption it doesn't have to be asserted). Should we
   allow it?

Thanks,

Daniel

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

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