PIL OWL Ontology Meeting 2012-01-09
- 1 Meeting Information
- 2 Agenda
- 3 Attendees
- 4 Discussions
- 4.1 Agenda
- 4.2 Review rest of list
- 4.2.1 Issue 6. wasStartedBy and wasEndedBy relationships missing in prov-o.
- 4.2.2 7. Note (Daniel G): should wasAssociatedWith, wasStartedBy and wasEndedBy have qualified involvements?
- 4.2.3 8. actedOnBehalfOf relationship missing.
- 4.2.4 9. prov:steps property (to qualify derivations) is missing.
- 4.2.5 wasControlledBy, wasEventuallyDerivedFrom, dependedOn, hadParticipant and wasScheduledAfter properties should be removed from prov-o.
- 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
- rest of list
- review list that we coveredP
- points from Luc
Last week's minutes: http://www.w3.org/2011/prov/wiki/PIL_OWL_Ontology_Meeting_2012-01-04
- 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
"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
Stian: There are *two* versions of wasStartedBy in PROV-DM - one between activity and agent (188.8.131.52), 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 (184.108.40.206) 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
220.127.116.11 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 )
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.
pretty busy this week :|