Re: PROV-O telcon

On Nov 7, 2011, at 3:42 AM, Luc Moreau wrote:

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


Don't tell anybody, but prov:entity (now called prov:qualifiedEntity) is used just like rdf:object.
So, the pattern that QualifiedInvolvements (shhhhhh; an rdf:Statement) uses would make prov:qualifiedEntity point to the earlier Entity.

I'm still chewing on Paul's example, which was left open [1]. I'm trying to reconcile the continuum of elaboration while letting them meet in the middle and avoiding proliferation of constructs.

[1] http://www.w3.org/mid/EMEW3|b145b1dab9471401ccf1899659ff3c15nAAGQL08l.moreau|ecs.soton.ac.uk|4EBD4CA9.80303@ecs.soton.ac.uk


> 
> 2. You have introduced a qualifier in participation, there is none in prov-dm.

It falls out from applying the QualifiedInvolvements pattern to prov:hadParticipant.


>    Why is it required here, since it seems to just link entity and pe. (no time here, for instance)

This affords the same ability as the others -- to allow third-party qualification about the relationship.
Time is just one of the specified qualifiers that an asserter can use.


>    Should it be introduced in prov-dm?

If it "falls out" of applying the same principles, then I'd say so.


> What else do we want to have?


With respect to what falls from this pattern, a qualified complementOf found its way as a stub but was not elaborated.
Probably needs motivation to warrant the work.



> 
> 3. It's the same for revision, there is no qualifier in prov-dm.  

Like with Participation, I stubbed that in because the pattern fit.
Though, I'd rather Revision be modeled as a specialization of Activity with a controlling again (as I mentioned yesterday afternoon).

qualified Derivation falls into this same contortion that I'm hoping to unravel.
Perhaps b/c we're Entity-to-Entity.
I'm really hoping that Activity is used to fill that gap, not qualifiers.


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


Ternary = Binary + 1.
QualifiedInvolvement lets you add whatever you want to the (shhhhhh reified) binary relation.
The "revision asserter" would be another "reserved role" in DM.

(But, note my concerns about this - and preference for reusing Activity to associate them; wasRevisionOf is a special form of wasDerivedFrom and should reduce into some highly or tersely described Activity).

> 
> 4. I understand why Generation "points to the future",


We really need a better phrase for this. It really is a lightning rod for the wrong reasons.


> but it makes it the odd one.

It's just like the others. It (shhhhh reifies) a triple from something (in the cases we are looking at, Activity) to an Entity - and is used to provide further description about that relationship and the Entity in that relationship.

So, the only thing "odd", is that to GET to it from the generated Entity, you need to follow the prov:wasGeneratedBy to the Activity and ask the activity for how the entity was contextualized.

Fortunately, I think this pattern suits the nature of the problem. The entity in isolation doesn't know how it was contextualized; the Activity inherently provides that contextualization.


>     It also seems that you can't write provenance "linearly" from future to past.



You can, using prov:wasGeneratedBy.
Further, you may now let the Activity "record" the provenance as it is "doing it":

"Hi, I'm DownLoadingFileActivity, I used URL :url_1 and generated File :file_3." - all of that is known when capturing the Activity.

:activity
	prov:used :url_1;
        prov:generated :file_3;
.

And, if you want to reach from :file_3 back, add:

:file_3 prov:wasGeneratedBy :activity.


In general, proliferating inverses is poor modeling, but prov:generated and prov:wasGeneratedBy afford "writing' provenance from either of the TWO main foci of PROV - Activity and Entity.





>     Are you satisfied with this?

Very much so.




> 
> 5. prov-dm introduces a relation "precedes" between events to give some interpretation to the data model.

I don't see this in http://dvcs.w3.org/hg/prov/raw-file/308f9e30cc7e/model/ProvenanceModel.html#record-Revision

Could you provide a pointer?


>     Potentially, it becomes possible to express it in the ontology.


Very much so.

> I am not suggesting that it should be encoded in the core
>     ontology!  


Whichever, the component aggregation framework can let us mix and match the modules that we (or anybody) wants.
http://www.w3.org/2011/prov/wiki/PROV_OWL_ontology_components


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



I just ran into this "precision" yesterday. Your description here is the best I've read so far, but I still do not understand it enough to know why we need it.
I hope this will be an area of focus in upcoming revisions.


> 
> 
> 7. Your picture (which BTW, I like very much, and we could adopt in prov-dm!)


Thanks. I drew it while reading DM, so I hope it reflects it.


> has a Use and a Usage.


Typo; fixed. It's Usage.


>     BTW, what is it you crossed out? can you explain?



I  crossed off the current DM approach to annotations because it advocates a level of indirection that is not natural in RDF modeling.

:color "blue" would hang off of the annotated thing directly, eliminating the need for hadAnnotation and Annotation.

This would be more appropriately modeled as owl:AnnotationProperties or hasValue restrictions for data/object properties.


> 
> 8. I like the fact you use nouns for properties of qualified involvement.


Which properties, exactly? 

Recently. many properties were renamed without group review.



>     There seems to be an exception, which is hadQuotee/hadQuoter (which is in the picture but not described below).

Just a stub.

I'm hoping the QualifedInvolvement modeling will fade away in preference for a specialization of an Activity with Roles. wasQuoteof would be a subproperty of wasDerivedFrom, roles :quoter and :quotee would replace the predicates you point out.

> 
> 9. On the choice of term: "Involvement". Is this appropriate to use this term in the case of revision and quotation

I hold a very loose notion of "involvement", but recognize that some desire an Activity to associate involved Entities.
I see the current pattern of QualifiedInvolvement to be more broadly applicable; we're quietly using reification.


>     (BTW, there was a suggestion that complementOf could indicate time intervals, so the same technique coudl be used here), 


Yes, the general pattern applies.


>     where there doesn't seem to be a 
>     process execution at all. You seem to have introduced "Qualified Relations" really.


I'd still say that two Entities were "involved" - I think "relation" is MUCH too broad for a provenance group to be addressing (I think we should constrain ourselves to involvements).

But again, Activities should be used (no matter HOW tersely described) instead of proliferating a 3rd construct that is adequalty handled by the two principle constructs (Activity and Entity).


>    
> That's it for now,
> Thanks again for your work!


Thank you for your comments. Apologies for the delay.

Regards,
Tim



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

Received on Tuesday, 22 November 2011 15:26:36 UTC