Re: PROV-O ready for internal WG review - due 9 April.

Hi prov-o team,

Just one more thoughts that came up when reading the primer.

Looking at the following snippet:

ex:correct prov:qualifiedAssociation [
                a Association ;
                prov:agent   ex:edith ;
                prov:hadPlan ex:corrections
            ] .

it is strange to see prov:hasPlan, why not simply prov:plan (and similarly
for other hadXXX properties).

Cheers,
Luc


On 04/03/2012 01:39 PM, Luc Moreau wrote:
> Hi prov-o team,
>
> Great piece of work!
>
> Luc
>
> ----------------------------------------------------------------------
> Answer to questions:
>
>
> * Does the HTML file provide an adequate overview of the OWL design 
> elements?
>
> Sections 1 to 3 are great. Section 4,  automatically generated I 
> believe, need more attention.
>
> * Do the different organizations of PROV-O HTML and DM complement each 
> other, or is it distracting?
>
> I am not against a different organization. It makes sense to discuss, 
> for instance, the qualified
> pattern in the context of the ontology.
>
> My only question is the apparent importance of collections. I would 
> tend to downplay them.
>
> References to the provdm:components are not explained. It linked to
> nowhere.  What were the colors for (beyond being the ones in dm)?
>
> * Would any additional comments (or attributes) help you read the 
> cross reference list in PROV-O HTML?
>
> Section 4 is arid, and not systematically handled. Suggestions below.
>
> * Are the comments within the OWL file adequate to familiarize with 
> the structure? If not, what kinds of comments would help?
>
> See suggestions below.
>
> * Should the OWL file contain any links to documentation (e.g., to the 
> DM, to examples, etc.)?
>
> I think it's a question that may also apply to other specs, including
> prov-dm. Is it worth linking to constraints?
>
> * Can the document be released as a next public working draft? If no, 
> what are the blocking issues?
>
> Yes, absolutely.  None of the issues I flagged here is blocking.
>
> ----------------------------------------------------------------------
>
> My comments:
>
> Great piece of work. Sections 1 to 3 read nicely.
> Section 4 is a bit arid, some improvement is desirable.
>
> 1. SOTD.
>   It must be clear to the reader what order documents need to be read in.
>   Suggest reusing SOTD from prov-dm.
>
> 2. section 1: remove reference to OWL semantics.
>
> 3. section 1: the prov-dm document no longer contains this example.
>     I suggest that you make your presentation self-contained.
>
> 4. When the ontology stabilizes, you need to manually layout the box 
> with all
>    classes and relations.  Alphabetical order is not useful here. I would
>    prefer to see a more logical ordering.
>
> 5. provo:Trace but provdm:Traceability.
>    We should adopt a single term. I don't mind which.
>
> 6. Section 3, text following figure 1 refers to wasStartedBy instead 
> of wasStartedByActivity
>
> 7. section 3: a picture (in PROV style!) would be desirable to 
> illustrate the example
>
> 8. section 3.1: the example includes prov:Organization which is a term 
> defined in section 3.2.
>
> 9. Is it necessary to see both foaf:Organization and prov:Organization?
>                                foaf:Person and prov:Person?
>
>
> 10. Section 3.2: example has not the correct namespace. Need to check 
> everywhere.
>
> 11. Section 3.3:
>      choice of name: you have prov:qualifiedUsage, etc
>                      why not simply prov:usage?
>
> 12. section 3.3. needs to explain why the qualified pattern is necessary.
>     It should say that:  a prov:used e means that there is *some* 
> usage of e by a
>         (possibly more than one!)
>     instances of prov:Usage allows usages to be distinguished and 
> counted.
>
>     Also, the pattern allows the expression of a given activity using 
> a given entity,
>     multiple times, at different moments.
>
> 13. section 3.3 last example: ex:usage, ex:generation, ex:activity are 
> not defined.
>     It would be good to see, in particular, ex:usage and ex:generation
>     Maybe the names are not great for these instances.
>
> 14. section 3.4: is the rdf correct?
>        :c1 a prov:Collection . <-
>             prov:derivedByInsertionFrom ...
>     Indentation is not clear either.
>
> 15. section 3.4: knownMembership
>      I don't think it's a good name for this property. It should be 
> membership,
>      since it may be known, inferred, or guessed.
>
> 16. Generally speaking, it's quite advanced to see an example on 
> collections so early.
>     It seems to give importance to this kind of concept that does not 
> reflect its real
>     importance. It's also one of the most speculative bit in the model.
>
> 17.  Section 4 is  quite arid to read from beginning to end.
>     But I appreciate it's designed mostly for online navigation.
>
>     Generally, section 4 should handle all terms systematically.
>     - use the prov-dm definition
>     - illustration with an example (generally, these need to be 
> formatted properly,
>       otherwise they are not readable)
>     - further comments,
>     - etc.
>     - characteristics do not seem to be expressed for all (see below)
>
>     some terms currently have no comment.
>
>
>
> 18. Definition of agent in section 4 is not the same as in 3.1
>
> 19. Text about properties should adopt a same style.
>
>     prov:wasGeneratedBy:  wasGeneratedBy links Entities ...
>     prov:used:  A prov:Entity that was used by ...
>
>
> 20. Account: is defined in terms of a mechanism?
>     In any case, that's an issue to solve for PROV
>
> 21. traceTo is supposed to link to and from Agents, but they are not 
> listed in domain/range.
>
> 22. prov:Start/prov:End/prov:Generation ... are defined in terms of 
> event as in part II, and not as in prov-dm part I.
>
> 23. Role is defined in the context of usage, generation, association, 
> start and end,
>    but hadRole has all involvments in its domain, including derivation 
> and collection-derivations.
>
> 23 prov:Source.  Do we need to introduce a class for this? Why not 
> just use Entity?
>
> 24  prov:agent, prov:entity, prov:activity must be made functional
>
> 25. prov:hadActivity, prov:hadGeneration, prov:hadUsage must be made 
> functional
>
> 26. prov:qualifiedInsertion and prov:qualifiedRemoval should be made 
> inverse functional
>
> 27. Delete appendix A since it is out of date.
>
>
> On 04/02/2012 09:12 PM, Timothy Lebo wrote:
>> Luc, Paul, Simon, Sam, and MacTed,
>>
>> Over the past couple telecons, you have accepted to review and 
>> provide feedback for the PROV-O documents.
>>
>> Please see ISSUE-336 for the information about reviewing PROV-O HTML 
>> and OWL.
>>
>> http://www.w3.org/2011/prov/track/issues/336
>>
>>
>> If you could reply to this message when providing feedback, we would 
>> greatly appreciate it.
>>
>> Regards,
>>
>> <Tim Lebo>
>>        prov:actedOnBehalfOf<PROV-O team>;
>> .
>

-- 
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 Wednesday, 4 April 2012 08:14:49 UTC