Re: PROV-O telcon

Hi all,
I don't know if I'll be able to join today's telecon.

Luc, what Tim crossed out in the big picture is about adding Annotations.
We didn't understand why do we have to introduce a new relationship instead
of reusing owl:AnnotationProperty.

Best,
Daniel

2011/11/7 Stephan Zednik <zednis@rpi.edu>

> ** **
>
> ** **
>
> *From:* Luc Moreau [mailto:L.Moreau@ecs.soton.ac.uk]
> *Sent:* Monday, November 07, 2011 1:43 AM
> *To:* Timothy Lebo
> *Cc:* Satya Sahoo; Stian Soiland-Reyes; Khalid Belhajjame; Daniel Garijo;
> James Cheney; Deborah L. McGuinness; Paolo Missier; Provenance Working
> Group WG
> *Subject:* Re: PROV-O telcon****
>
> ** **
>
> Thanks Tim and Team for the hard work over the WE.
>
> I won't be able to join the call today, but I think my technical
> concerns are now addressed by your proposal.
>
> A few questions comments:
> 1.  There is an outstanding issue (raised by Paul) that we should be able
>    to have time associated with derivation. If adopted, this may require
>    a derivation qualifier. Would your approach still work? In this case,
> which
>    is the prov:entity?****
>
> ** **
>
> I think the same modeling could work.  We may need to re-visit the name of
> prov:entity (which is currently a non-final name, we decided to not put too
> much effort into the naming of this property on Friday and focus on the
> general modeling).  The goal was to keep the property intent clear for
> qualified relations between process executions and entities.  Entity to
> entity qualified relations may expose deficiencies in the current names. J
> ****
>
> ** **
>
> I think it would make sense for the derived entity to assert the qualified
> Derivation relation and for the prov:entity to refer to the entity that the
> derived entity was derived from.
>
>
> 2. You have introduced a qualifier in participation, there is none in
> prov-dm.
>    Why is it required here, since it seems to just link entity and pe. (no
> time here, for instance)
>    Should it be introduced in prov-dm? What else do we want to have?****
>
> ** **
>
> I believe it is natural to want to associate a role and time with
> Participation.  Participation seems a natural fit along with Control for
> qualifiers.****
>
>
>
> 3. It's the same for revision, there is no qualifier in prov-dm.
>     But here, the Revision qualifier you introduce is of different nature,
> it is there
>     to capture a ternary relation between entities (while before, it was
> binary relation between
>     pe/entity, with a hook for "extra stuff").
>
> 4. I understand why Generation "points to the future", but it makes it the
> odd one.
>     It also seems that you can't write provenance "linearly" from future
> to past.
>     Are you satisfied with this?****
>
> ** **
>
> We discussed being able to reference a Generation from an entity or a
> process execution.  This added complexity that we were not sure of the best
> way to deal with.  Any QualifiedInvolvement only makes sense in the context
> of both the Entity and the ProcessExecution in the qualified relation.  All
> the major QualifiedInvolvement types we discussed were directed from the
> process execution to an entity, except for Generation (we did not discuss
> Quotation or Revision on Friday).  This meant that a Generation would need
> a prov:processExecution property to refer to the process execution if it
> was a relation from an entity to a process execution and a prov:entity if
> it was a relation from a process execution to an entity.  To be safe you
> could force a Generation to refer to both prov:entity and
> prov:processExecution, so you understand its context no matter where it was
> asserted.  This was not a restriction we had been putting on Usage,
> Control, and Participation and we were not sure it made sense to add it.
> We did not want to have two qualified Generation classes, one for each
> direction on the relation.****
>
> ** **
>
> There is also another question on what is the role in Generation.****
>
> ** **
>
> Is it the role of the process execution in generating the entity or the
> role of the generated entity in the process execution?  We thought it made
> the most sense if the role was on the generated entity rather than the
> process execution, which does not play a role in any other qualified
> relation.  The entity playing the role in Usage, Control, Participation is
> referenced using prov:entity, and is not the source of the qualified
> assertion.  If we have entity the source of the qualified generation and
> the role in the qualification is about the entity, that breaks this
> convention.****
>
> ** **
>
> I think on Friday we felt that having a qualified generation asserted from
> an entity to a process execution broke too many conventions established
> with qualified usage, control, and participation and created a great deal
> of additional complexity.****
>
> ** **
>
> As for writing provenance linearly, we still have the prov:wasGeneratedBy
> property to trace back in time, you just have to use the process execution
> to entity directed qualified Generation to get/set qualifiers on the
> generation.****
>
> ** **
>
> I hope this makes sense…  this was by far the biggest issue we grappled
> with during the Friday call.****
>
>
> 5. prov-dm introduces a relation "precedes" between events to give some
> interpretation to the data model.
>     Potentially, it becomes possible to express it in the ontology. I am
> not suggesting that it should be encoded in the core
>     ontology!
>
> 6. It would be good to write that unqualified involvement is "unprecise".
>     When we assert used(pe,e),
>     it could be because of QualifiedUse(pe,e,t1,role=r1)  and
> QualifiedUse(pe,e,t2,role=r2).
>     So, used(pe,e) gives a *lower bound* on the number of actual uses.
>
>
> 7. Your picture (which BTW, I like very much, and we could adopt in
> prov-dm!) has a Use and a Usage.
>     BTW, what is it you crossed out? can you explain?****
>
> ** **
>
> I suspect that is a typo and the Use should be Usage.****
>
>
>
> 8. I like the fact you use nouns for properties of qualified involvement.
>     There seems to be an exception, which is hadQuotee/hadQuoter (which is
> in the picture but not described below).
>
> 9. On the choice of term: "Involvement". Is this appropriate to use this
> term in the case of revision and quotation
>     (BTW, there was a suggestion that complementOf could indicate time
> intervals, so the same technique coudl be used here),
>     where there doesn't seem to be a
>     process execution at all. You seem to have introduced "Qualified
> Relations" really.
>    ****
>
> We discussed calling them QualifiedRelations, but I think we felt that
> ‘relation’ was too general a term.  Also, all the qualified relations we
> discussed were between a process execution and an entity, so ‘involvement’
> seemed natural.  It looks like Quotation and Revision were added to the
> diagram to show potential additional uses of qualified relations that we
> did not focus on on Friday, and entity to entity relations may reduce the
> sense the term ‘involvement’.****
>
> ** **
>
> --Stephan****
>
> ** **
>
>
> That's it for now,
> Thanks again for your work!
>
> Cheers,
> Luc
>
> On 11/06/2011 10:07 PM, Timothy Lebo wrote: ****
>
> ** **
>
> On Nov 6, 2011, at 4:00 PM, Satya Sahoo wrote:****
>
>
>
> ****
>
> Hi all, ****
>
> The following is the agenda for our ontology telcon tomorrow at 12:00noon
> US EST (please note the corresponding time in Europe):****
>
> ** **
>
> 1. Review the OPMO-based solution for modeling role information in PROV-O
> OWL and the instantiation as RDF using James's "division example" (Tim,
> Daniel, Stephan)****
>
> ** **
>
> ** **
>
> Writeup is at
> http://www.w3.org/2011/prov/wiki/Qualifed_Involvements_in_PROV-O****
>
> ** **
>
>
>
> ****
>
> ** **
>
> 2. Review the modified html document - (a) examples for wasRevisionOf,
> Recipe etc. (b) classes in "holding section", (c) properties in "holding
> section"****
>
> ** **
>
> 3. Review new section in html document - Mapping PROV-DM to PROV-O****
>
> ** **
>
> 4. Discuss proposal for simplifying the PROV-O for readers/users by
> re-structuring some of the properties in a "core" and an "extended" model*
> ***
>
> ** **
>
> For this, I'd like to remind the group about
> http://www.w3.org/2011/prov/wiki/PROV_OWL_ontology_components****
>
> I'd also like to get acknowledgement that this can or will be used as we
> move forward.****
>
>
>
> ****
>
> ** **
>
> 5. Discuss addition of diagrams for some of the object properties****
>
> ** **
>
> We will use the Zakim bridge for the call +1.617.761.6200, conference 695
> ("OWL") and the titanpad for taking notes (Tim, can you please send out the
> link to the titanpad?)****
>
> ** **
>
> -Tim****
>
> ** **
>
>
>
> ****
>
> -- ****
>
> Professor Luc Moreau               ****
>
> Electronics and Computer Science   tel:   +44 23 8059 4487         ****
>
> University of Southampton          fax:   +44 23 8059 2865         ****
>
> Southampton SO17 1BJ               email: l.moreau@ecs.soton.ac.uk  ****
>
> United Kingdom                     http://www.ecs.soton.ac.uk/~lavm****
>
>