RE: PROV-O telcon

 

 

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  <tel:+1.617.761.6200>
+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