W3C home > Mailing lists > Public > public-prov-comments@w3.org > July 2012

Re: PROV feedback

From: Paul Groth <p.t.groth@vu.nl>
Date: Wed, 25 Jul 2012 17:07:23 +0200
Message-ID: <CAJCyKRqM8viS0JagmN3_tbU0LUOGUgGwPs6_bOW3yMwO=K==CQ@mail.gmail.com>
To: "Freimuth, Robert, Ph.D." <Freimuth.Robert@mayo.edu>
Cc: "public-prov-comments@w3.org" <public-prov-comments@w3.org>
Thanks Bob for the follow-up.


On Wed, Jul 25, 2012 at 4:33 PM, Freimuth, Robert, Ph.D.
<Freimuth.Robert@mayo.edu> wrote:
> Hi Paul,
> Yes - I did find the UML diagrams within the DM spec to be helpful, overall.
> In fact, I thought using class associations to model the attributes that are
> part of each PROV statement was a good way to include that information in
> the diagram so I mirrored that approach when I created my diagrams.
> In particular, the examples (e.g., figures 2 and 3) were great and could be
> interpreted with little reference to the supporting text.  I was a little
> confused by others (e.g., figures 5-8) and had to reconcile what I
> interpreted from the diagram with what I read in the text.  Some of this
> might be due to personal preferences regarding modeling style.
> The majority of my confusion was resolved when I made the distinction
> between terms that were used to reference Activities (an actual process)
> from those that were used to describe information about a relationship
> (e.g., "generation" does not describe an Activity).  Once that occurred it
> was much easier to generate a model that looked simimlar to the diagrams in
> the DM spec.  Personally, I find the way I illustrated relationships and
> their associated classes to be more intuitive in part because the associated
> classes mirror the notation for each relationship (all attributes are shown;
> again, might be a style preference).  This made it easier for me to tie the
> text to the diagram and mentally separate the "syntax classes" from the
> "things" in the model.
> Also note that while I modeled roles as explicit classes, this was done to
> more clearly define the associated relationship and it is not something that
> I think needs to be included within PROV-N.  They were important for me to
> fully understand PROV but others may think the extra information is
> unnecessary.  I use role classes frequently and, if I adopt PROV to use with
> my project, will include PROV role classes when I pull elements of PROV into
> my model.
> Thanks,
> Bob
> ________________________________
> From: pgroth@gmail.com on behalf of Paul Groth
> Sent: Wed 7/25/2012 2:29 AM
> To: Freimuth, Robert, Ph.D.
> Cc: public-prov-comments@w3.org
> Subject: Re: PROV feedback
> Dear Robert,
> Thanks for your extensive review! We have created ISSUE-463 for your
> comment which you can find at:
> https://www.w3.org/2011/prov/track/issues/463
> We will now discuss in the Working Group how to address your comment.
> To not swamp you with email, we'll do this on our internal mailing
> list and get back to you with either a resolution, an update on
> progress or clarification questions.
> You can always check where we are at by looking at the issue above.
> One quick question I had, was whether the UML diagrams with the
> PROV-DM were useful to you? Did you base your diagrams on those?
> Thanks,
> Paul
> On Tue, Jul 24, 2012 at 8:38 PM, Freimuth, Robert, Ph.D.
> <Freimuth.Robert@mayo.edu> wrote:
>> To the W3C PROV working group:
>> This email is in response to the call for comment and feedback on the
>> current working draft of the PROV model.  I reviewed the PROV
>> documentation
>> following a recommendation from Jim McCusker.
>> I am impressed with the volume of PROV documentation.  I did not have time
>> to thoroughly review all of the documents that comprise the PROV spec, but
>> I
>> was able to review the Primer, Notation, and Data Model.  I found PROV to
>> be
>> relatively complete and well-documented.  Thank you for all of the effort
>> the working group has put into this.
>> I have attached a document that contains my detailed comments and
>> feedback.
>> Thanks to Tim Lebo and Jim McCusker for answering some of my early
>> questions
>> via email.
>> As part of my review and learning process, I also created a UML model of
>> PROV.  This allowed me to actively understand the model and see the
>> effects
>> of change proposals.  I attached a document that summarizes my proposed
>> changes and a series of images from the model that I created (which
>> incorporates the proposed changes), which I hope will help make the
>> proposed
>> changes more clear to the work group.  This is done in the spirit of
>> offering ideas and solutions, not just complaints.
>> I would be happy to discuss these documents with the work group if my
>> comments are unclear (which is likely).  I am interested in your response
>> to
>> these suggestions and I look forward to seeing the final PROV spec.
>> Finally, some context for my interest in this work.  I am looking for a
>> provenance model to use for pharmacogenomics.  Now that I feel like I have
>> a
>> decent understanding of the model I will evaluate it for use in this
>> scenario.  I suspect I will need to extend the model to capture more
>> information about why changes were made, not just when and how they were
>> made.  This may be outside the scope of PROV.
>> Regards,
>> Robert R. Freimuth, Ph.D.
>> Associate Consultant
>> Division of Biomedical Statistics and Informatics
>> Assistant Professor of Medical Informatics
>> _______________________________
>> Mayo Clinic
>> 200 First Street SW
>> Rochester, MN 55905
>> www.mayoclinic.org
>> <<PROV_Feedback.zip>>
> --
> --
> Dr. Paul Groth (p.t.groth@vu.nl)
> http://www.few.vu.nl/~pgroth/
> Assistant Professor
> - Knowledge Representation & Reasoning Group |
>   Artificial Intelligence Section | Department of Computer Science
> - The Network Institute
> VU University Amsterdam

Dr. Paul Groth (p.t.groth@vu.nl)
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam
Received on Wednesday, 25 July 2012 15:07:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:50:03 UTC