PIL OWL Ontology Meeting 2012-01-09

Meeting Information

prov-wg - Modeling Task Force - OWL group telecon

• previous meeting
• date: 2012-01-09
• time: 8 PT, 11 ET, 5pm UK
• via Skype
• wiki page: http://www.w3.org/2011/prov/wiki/PIL_OWL_Ontology_Meeting_2012-01-09
• titan page: http://titanpad.com/GvPZTC3ZS5
• next meeting

Agenda

• rest of list
• review list that we coveredP
• points from Luc

Attendees

• Satya
• Tim
• James
• Daniel
• Stephan
• Khalid
• Stian

Last week's minutes: http://www.w3.org/2011/prov/wiki/PIL_OWL_Ontology_Meeting_2012-01-04

Discussions

Agenda

Luc's comments

• prov-o versus prov-o-constraints

Review rest of list

Issue 6. wasStartedBy and wasEndedBy relationships missing in prov-o.

(Daniel's list of outstanding points) Khalid: they should be subproperty of wasAssociatedWith

from PROV-DM

"Relations wasStartedBy and wasEndedBy are specializations of wasAssociatedWith that can optionally be used to carry additional meaning."

Satya: question of how specific or general constructs may be in PROV-DM.

Tim: "specific" constructs should be linked to generic/core constructs  in PROV-DM, PROV-O Tim: as long as the "specific" constructs are logically connected to the "core" or rest of the DM constructs, I'm less concerned about seeking and destroying "specific" constructs. i.e., I can know what wasEndedBy is in terms of something that I already know (wasAssociatedWith).

Tim: are both of these specialization of wasInformedBy? Khalid, Stian: No Tim: seems that they should.

Start and End records in PROV-DM

• http://dvcs.w3.org/hg/prov/raw-file/default/model/ProvenanceModel.html#record-Start-End

Stian: There are *two* versions of wasStartedBy in PROV-DM - one between activity and agent (5.3.2.2), and one between two activities (6.2) - are we doing both? (First is wasAssociatedWith specialisation - second one is a short-cut for the first, but with implicit agent which wasGeneratedBy the other activity)

Tim runs with "Activities are what Agents (or anything else) do" Stian: Activities should be able to be Agents (or vice versa) (PROV DM says NO at the moment.) I think it would make sense to have an Activity being an Entity too. (Daniel) It makes things difficult with phantom agents. True.. Example from Taverna: https://github.com/wf4ever/ro/blob/master/mapping/prov-o/test/helloworld.prov.rdf This discussion should be raised as an issue for discussion to the group. I am intending to - next week.

7. Note (Daniel G): should wasAssociatedWith, wasStartedBy and  wasEndedBy  have qualified involvements?

According to prov dm, they can  be  qualified with roles. In particular, wasAssociatedWith can be  qualified  with a plan: an agent executes an activity according to a  plan. Should  the plan be linked to the associatedwith or to the  activity? Can  activities have more than 1 plan? (To be discussed).  Stephan: Already discussed in email, plan is linked to the association, not the activity. Daniel:wasAssociatedWith   Tim: +1 for qualifying wasAssociatedWith,  it came up for Accounts.

Tim: I think we should apply the qualified pattren to all binary predicates between entities. Stephan: +1 Khalid:  Satya: we are not being consistent about qualifying properties versus using subproperties.

Tim: subproperties are a (less descriptive) shorthand for qualified relations. Stian: Can you then still attach attributes to only the wasStartedBy() assertion and not to the wasEndedBy() assertion? Are you asking the subproperty-ers or the qualified involvement-ers? on qi - if there is just one QI -- you can if there is a subproperty to associate the QI with the Activity - or a :qualifiedInvolvement prov:blah prov:wasStartedBy (annotation?) property (I think some early QualifiedInvolvement suggestion worked like #1 here)

Stephan: mode qualifier on wasStartedBy means we need QualifiedInvolements

from PROV-DM (5.3.2.2) wasStartedBy(a,ag,[ex:mode="manual"]) wasEndedby(a,ag,[ex:mode="manual"])

Stian:(I think it is a general issue with mapping DM is that every assertion seems to be getting , [attrs] added - so that we have to unpack everything in n-ary relations) It looks like. And now the derivation too with the "steps" attribute. steps is just a binary attribute though.. either it is a single activity, or "unknown/many". Not actual number - so probably just one of them is reflected through using a subclass/subproperty in PROV-O. Daniel: wasDerivedFrom(e2,e1,[prov:steps="1"] ∪ attrs means that there could be other attrs too-> qualified derivation.

satya reviews QI versus subproperties. Tim doesn't see why we can't do both.

8. actedOnBehalfOf relationship missing.

Tim: Stephan's concern about "global" can be handled by actedOnBehalfOf a characterized form of the agent. +1

so the agent can act for different people in different activities

5.3.3.1 http://dvcs.w3.org/hg/prov/raw-file/b873927af3be/model/ProvenanceModel.html#dfn-responsibility Given an activity association record wasAssociatedWith(a,ag2,attrs), a responsibility record, written actedOnBehalfOf(id,ag2,ag1,a,attrs) in PROV-ASN, has the following constituents: • id: an optional identifier id identifying the responsibility record; • subordinate: an identifier ag2 for an agent record, which represents an agent associated with an activity, acting on behalf of the responsible agent; • responsible: an identifier ag1 for an agent record, which represents the agent on behalf of which the subordinate agent ag2 acts; • activity: an optional identifier a of an activity record for which the responsibility record holds; • attributes: an optional set of attribute-value pairs attrs that describe the modalities of this relation.

responsibilityRecord ::= actedOnBehalfOf (  identifier, agIdentifier , agIdentifier , aIdentifier optional-attribute-values )

actedOnBehalfOf(ag1,ag2,a,[prov:type="delegation"]) actedOnBehalfOf(ag2,ag3,a,[prov:type="contract"])

Stian: Sounds like a QualifiedInvolvement where the activity might be unasserted.. ;)

Tim: doesn't sound like this modeling is taking advantage of the notion of being "characterized" - instead takes the easy (and less integrated) way out by making up yet another N-ary relation. specializationOf should be used, but isn't.

Tim: Feature of DM is characterisation, where you freeze some aspect. You can also specialise this with prov:spezialisationOf, etc. If we talk about two agents doing things within an activity, the characterisation of "me within this activity" is a specialisation of "me in lots of activities". This sounds like an essential concept, but then is not applied by DM when modelling specific relations like actedOnBehalfOf, instead brand new n-ary relationships appear. Now you need to understand each of these relationships. Daniel: So what I understood is that the caracterization of the entity gets lost in having to understand all these additional properties to relate it to other agents,

OUTSTANDING issue: If we consider this as an n-ary property, it needs to be discussed. If it can be a binary property, we can easily add it to PROV-O Stian: This is probably true for every unaddressed point.

9. prov:steps property (to qualify derivations) is missing.

 This implies to create a qualified involvement for the derivation too.   (It might just be a subproperty of wasDerivedBy (step=n) - wasDerivedBySingleActivity (step=1)) - but would need a QI to link to the activity (even if that activity is not asserted we will then know it exists) Satya: +1

Tim: perhaps keep one wasDerivedBy range Activity with subclasses SingleActivity and CompositeActivity?

10. alternateOf and specializationOf properties are missing in prov-o.  Each of e1 , e2 provide a more concrete characterization of Bob  than e3 does    -->specializationOf e1 and  e2 provide two different characterizations of the same entity. -->alternateOf

alternateOf - two different characterisations of same 'thing' (earlier: wasComplementOf) viewOf -> specializationOf -- means "more specific characterisation" of the entity (was renamed from viewOf)

• what about moreSpecificCharacterization ? (lets call it what we use to define it)
• moreCharacterizedThan (that works)

Yes, I like the proposal of replacing specializationOf with moreSpecificCharacterization Yes - we are talking about characterisations, after all - and it might not be 'specialized' - just more specific

do NOT try to reuse OO principles here. DM isn't using them (and isn't trying to)

Satya: Specialization is well-understood and widely term to mean something that is contrary to what is being proposed in the DM

James: (So is view, though! It means something very specific in databases.)  --- not sure we can avoid terms that have other common meanings. Not arguing that "specializationOf" is right either though. We've already had the "entity" fight..

Can the agenda have a list of the points remaining to be discissed (so we can look at relevant parts of DM or PROV-O?

Tim: We need to make more progess, so we can't postpone to next week's telecon. We need to get things done on email. I need to go. :D Daniel: I Agree.

+1 to focus more on ontology first - avoid wasted time on writing lots of documentation we then disagree on :) +1 (Daniel)

wasControlledBy, wasEventuallyDerivedFrom, dependedOn,  hadParticipant  and wasScheduledAfter properties should be removed from  prov-o.

Agree

pretty busy this week :|