Re: PROV-ISSUE-382 (jzhao): Qualification patters in prov-o section 3.3 [PROV-O HTML]

Jun,

May we close this issue? I believe we have worked through the largest point as we worked toward LC over the past weeks.
Anything left can be raised as new issues?

Thanks,
Tim

On Jul 6, 2012, at 3:51 PM, Timothy Lebo wrote:

> Jun,
> 
> My response to this issue is poorly overdue. I apologize.
> 
> Although a couple of your points have been addressed already, many others would be very valuable to include.
> 
> I've provided responses (and some requests) within your text below.
> 
> The latest draft is at http://aquarius.tw.rpi.edu/prov-wg/prov-o and I will be responding to your comments based on that.
> 
> I've also extracted the main points to our agenda for Monday:
> 
> http://www.w3.org/2011/prov/wiki/PIL_OWL_Ontology_Meeting_2012-07-09#Jun
> 
> 
> 
> 
> 
> On May 23, 2012, at 7:42 AM, Provenance Working Group Issue Tracker wrote:
> 
>> PROV-ISSUE-382 (jzhao): Qualification patters in prov-o section 3.3 [PROV-O HTML]
>> 
>> http://www.w3.org/2011/prov/track/issues/382
>> 
>> Raised by: Jun Zhao
>> On product: PROV-O HTML
>> 
>> 
>> Dear prov-o team and all,
>> 
>> This is related to issue ISSUE-381, based on my reading of https://dvcs.w3.org/hg/prov/raw-file/default/ontology/Overview.html, yesterday afternoon.
>> 
>> Again, please do not take my feedback as a criticism to the excellent by whoever worked on this section. I went out to look for some "qualification patterns" as we agreed on Monday's call, and here are some of my findings.:)
>> 
>> Cheers,
>> 
>> Jun
>> 
>> == Housekeeping ==
>> 
>> 1) we don't have a table to summarize qualification patterns for Dictionary terms. We have that for starting-point and expanded terms.
> 
> OBE since Dictionary moved to notes.
> 
>> 
>> 2) We need to add qualification pattern for property prov:wasInvalidatedBy to the starting-point terms table.
> 
> By "table", do you mean listing?
> 
> http://aquarius.tw.rpi.edu/prov-wg/prov-o#prov-o-at-a-glance
> 
> currently lists the following (which includes wasInvalidedBy)
> prov:alternateOf
> prov:asInBundle
> prov:atLocation
> prov:generated
> prov:generatedAtTime
> prov:hadMember
> prov:hadPrimarySource
> prov:influenced
> prov:invalidated
> prov:invalidatedAtTime
> prov:mentionOf
> prov:specializationOf
> prov:value
> prov:wasEndedBy
> prov:wasInvalidatedBy
> prov:wasQuotedFrom
> prov:wasRevisionOf
> prov:wasStartedBy
> 
> It is also in http://aquarius.tw.rpi.edu/prov-wg/prov-o#qualified-forms-expanded
> 
> 
>> 
>> 3) The first example cannot be simpler, can it?:) I guess whoever put it there in the first place was trying to make it simple for readers, but I think it does not hold enough substance to even support the text around it.
>> 
> 
> The first example (immediately after Figure 1) is longer than you describe. Perhaps it grew?
> http://aquarius.tw.rpi.edu/prov-wg/prov-o#starting-points-figure
> 
> 
>> == Refactoring suggestions ==
>> 
>> === The "cheat-sheet" tables ===
>> 
>> I set out to look for the "patterns" people have been telling me about. I still think the "cheatsheet-like" tables towards the end of the section are most helpful, to tell me the patterns that are very hard indeed to explain in words.
>> 
>> So can we move those two tables, (maybe 3 after adding one for collections) to the front of the section, to support the patterns described in the 1st paragraph?
> 
> 
> The tables have been moved up:
> 
> http://aquarius.tw.rpi.edu/prov-wg/prov-o#description-qualified-terms
> 
> after the tables, a small example, then graphical illustrations of the same material in the tables.
> 
> Does this flow help?
> 
> 
> 
>> 
>> === The "qualification patterns" ===
>> 
>> I got the patterns easily enough by reading the first 3 columns of these tables, and if I work my brain just a bit hard, I can follow where any of 4th column property should be use.
> 
> 
> Well, the tables are up to 6 columns now, so if your head spun at 4, then we might have a bigger problem on our hands.
> Any suggestions that you may have for what to cut would be greatly appreciated.
> 
> 
> 
>> But I am really struggling with these two groups of terms in the current qualification terms category:
>> 
>> Group 1: activity, entity, agent, dictionary
>> 
>> Group 2: hadActivity, hadGeneration, hadUsage ( I am fine with hadPlan and hadRole, because they are named so differently from those in group 1)
>> 
>> They made my head spin, and I think this is a sign that we should have a dedicate paragraph to say something about them.
> 
> 
> I agree, and this is not done yet.
> We need a paragraph for "what to do once you've qualified" that cites "activity, entity, agent, dictionary" and lists the options "hadActivity, hadGeneration, hadUsage"
> 
> 
> 
>> 
>> I think group 1 are used to point to the objects being qualified, and group 2 are used to provide the additional statements about the can-be-qualifeid properties, via their corresponding qualify classes or an involvement class. Does this summary make sense?
> 
> 
> Yes. We should write that up.
> 
> 
>> 
>> For me, it will better if:
>> 1) we make an explanation of the above sort right at the beginning of the section, after or before the cheat-sheet tables; if you all do agree to move those tables forward.
> 
> 
> Good place as any. Once we have a sketch of the paragraph, it'll go there.
> 
> 
>> 
>> 2) name group 1 terms to involvedActivity, involvedXXX. I know I am being provocative again. You might have already been there, and sorry if I am bringing back the old wound:)
> 
> 
> since involvee was renamed to influencer, I think this would not be a suggestion to rename:
> 
> activity, entity, activity 
> 
> to:
> 
> influencingActivity, influencingEntity, influencingActivity
> 
> the former are shorter, the latter are more self-describing.
> 
> 
> 
>> 
>> 3) Another cheat-sheet table, to show which classes SHOULD/CAN/MAY be used together with group 2 terms. Choose your normative word, whoever really understands what's going on there. Again, some of our offline discussions already touched this. I think adding restrictions using OWL constructs are not as straightforward as tables :)
> 
> 
> This kind of "cheat sheet" is available in the cross reference, but I really like the idea of pulling it all together into a table.
> Could you mock up some tables that you would like to see?
> 
> 
> 
>> 
>> === Refactoring the examples ===
>> 
>> After we agree on how to move forward with the above two refactoring, we should reconsider the current examples in the section.
>> - Some of them could be moved?
>> - We should make better use of the nice Figure 2?
>> - Rewrite some of the examples to explain the usage of group 1 v.s 2 terms?
> 
> Any suggestions here welcome.
> 
> 
> Thanks,
> Tim
> 
> 
> 
> 
> 
>> 
>> 
>> 
>> 
>> 
>