W3C home > Mailing lists > Public > public-prov-wg@w3.org > February 2012

Re: Tim's approach on Involvement

From: Timothy Lebo <lebot@rpi.edu>
Date: Tue, 21 Feb 2012 11:43:22 -0500
Cc: Khalid Belhajjame <Khalid.Belhajjame@cs.man.ac.uk>, Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>, "public-prov-wg@w3.org Group" <public-prov-wg@w3.org>
Message-Id: <D614A25A-9875-4E22-B478-CC40F129F9A5@rpi.edu>
To: Daniel Garijo <dgarijo@delicias.dia.fi.upm.es>

On Feb 21, 2012, at 6:46 AM, Daniel Garijo wrote:

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

I put it directly on Involvement to avoid clutter and confusion.

> Why the propery "tracedTo" is not a subproperty of "involved"? It relates an Element to an Element too.

I think you're correct.

> Do we need "involved"? What is its use appart from creating a hierarchy?

All subproperties of involved are qualifiable. Others are not.
The prov:involved property parallels the prov:Involvement class.

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

If you want it to be changed, I'd agree with prov:involvedEntity and prov:involvedActivity

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

I say keep the subproperties out. It makes modeling much simpler and more concise.
If your tools are too difficult to use, you need better tools. ;-)

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

Yes, we should allow the open world. Because it is an open world.


> 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
Received on Tuesday, 21 February 2012 16:50:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:12 UTC