Re: Revised PROV Overview

Hi James,

I've addressed all your comments, I hope except for the SOTD which I think
we are stuck with.

Here are the specific things

1. PROV-XG recommendations
I included the summaries as you suggested, I hope this covers what you were
asking for. I also agree with you that we do cover all the recommendations.
Luc disagreed with that but after rereading I think the fact that we
support extensibility covers this.

2. Coverage of required documents

You asked: "If we are providing evidence that the WG did its job here,
should we explain the relationship between the planned WG deliverables and
the actual ones?  I don't see why we should, just curious."

I think this is probably getting into the weeds. The reason we explained
the recommendations from the xg was that we wanted to address the question,
well what was your model based on?

3. Updated figure
Thanks for your updated figure. I pretty much adopted the approach
wholesale. Is it better?

Thanks
Paul


On Thu, Apr 11, 2013 at 7:27 PM, James Cheney <jcheney@inf.ed.ac.uk> wrote:

>  Hi Paul,
>
>  Here are some  review comments.
>
>  1. In my version of Firefox, just before appendix A a big chunk of text
> appears:
>
>       An entity is a physical, digital, conceptual, or other kind of
> thing with some fixed aspects; entities may be real or imaginary.
> An activity is something that occurs over a period of time and acts upon
> or with entities; it may include consuming, processing, transforming,
> modifying, relocating, using, or generating entities. An agent is
> something that bears some form of responsibility for an activity taking
> place, for the existence of an ... Something that is a contextualizationof another presents all aspects of the latter as per its description in a
> bundle, and therefore constitutes a specialization of the latter.
>
>
> This appears to be a respec/firefox bug, it doesn't appear elsewhere.  The
> HTML shows that there is a glossary element in the HTML source.  Perhaps
> removing that will fix this.  In any case, it seems to go away when the
> HTML document is rendered properly by Javascript.
>
>  2. Rereading the boilerplate under "PROV Family of Documents" for the
> millionth time, it seems to me that the sentence
>
>   This document is part of the PROV family of documents, a set of
> documents defining various aspects that are necessary to achieve the vision
> of inter-operable interchange of provenance information in heterogeneous
> environments such as the Web.
>
>
>  is quite vague - what are "various aspects"?  I guess it is too late to
> change this, but I wish we could say something more specific than "various
> aspects".  Also, "necessary" seems a little strong, though I don't have a
> constructive suggestion.
>
>  3.  In the SOTD line for prov-dc, "Dublic" should be "Dublin".  This
> typo seems to be present in many documents (including other staged RECs!)
>  I sent a separate email...
>
>  4.  In the SOTD line for prov-links, extra period before [PROV-LINKS].
>
>  5. Under "Implementations Encouraged", "errata or and" has an extra word.
>
>  6.  In the paragraph on the PROV-XG recommendations, could you list them
> (or at least summarize them)?  You could just copy the text from the
> PROV-FAQ.
>
>  6a.  Recommendation 2 only requires that PROV provides extensibility
> points so that information addressed in other standards can be linked.  I
> think we do this (if only by allowing just about anything to be linked to
> just about anything else, using attributes in prov-n/prov-xml or using
> direct linkage in prov-o).  Isn't this addressed (at least partially) by
> prov-aq and existing extensibiity points?  If we don't address it,
>
>  6b. Recommendation 5 says that it a provenance framework should include
> a representation that is detailed enough information to allow
> reproducibility.  I agree that we do this, in principle, but we do not
> specify anywhere how to ensure that a given chunk of PROV is "enough" for
> reproducibility  (and I would argue this is out of scope since it would
> require getting into the details of specific applications, which we decided
> not to do for e.g. workflows).  Again not a big deal, but I think that we
> satisfy rec 2 at least as well as rec 5 here.
>
>  7.  If we are providing evidence that the WG did its job here, should we
> explain the relationship between the planned WG deliverables and the actual
> ones?  I don't see why we should, just curious.
>
>  8.  The box diagram:
>
>  8a. ... has no number/caption, and isn't mentioned in the text.  I
> suggest referring to it from the Document Roadmap paragraph, especially if
> you wind up using similar conventions to the table.
>
>  8b. ... employs unclear conventions: on the LHS, it seems that one box
> being above another indicates a dependency from the lower to the upper
> component.  But on the RHS, prov-links, prov-dictionart y and prov-aq are
> free-standing, which suggests that they don't depend on prov-dm.  I would
> suggest making prov-dm wider and making prov-links and prov-dictionary
> "over"
>
>   It also isn't clear whether the relative heights of boxes are
> meaningful, or what nesting of boxes means.  I guess having
> prov-constraints and prov-sem inside prov-dm means prov-constraints and
> prov-sem are conceptually "part of" or refinements of prov-dm.  But since
> prov-sem is not a recommendation, and not prerequisite for anything else,
> this may convey a misleading impression about its importance to other
> components.  On the other hand, both prov-links and prov-dictionary build
> on prov-dm in a sense.
>
>  I guess what I am saying is: if the relative positioning / size /
> nesting means something, please explain what.
>
>  Also, prov-primer isn't in the figure, not sure why.
>
>  8c. ... could be made more informative by using colors to flag
> user/developer/advanced (just as in the subsequent table) and, perhaps,
> using bold (or heavier line weight) for the components that are
> recommendations vs. lighter weight text/lines for notes.
>
>  I've attached an alternative suggested layout (feel free to ignore).  It
> isn't perfect either, e.g. it doesn't reflect that prov-dictionary builds
> on prov-o & prov-xml as well as prov-dm+constraints, or that
> prov-constraints in some sense depends on prov-n (and is relevant in some
> other sense to prov-o), but horizontal positioning roughly corresponds to
> "depends primarily on".
>
>  9. "In addition, to" - remove comma
>
>  10.  "continually update" -> "will continue to be updated after the
> publication of this Note and other PROV documents"
>
>  11. "exercises, these" -> "exercises, and these"
>
>  Overall it is in good shape, but even though it is short I think a few
> of these suggestions will help make it more informative as a roadmap.
>
>  --James
>
>
>  On Apr 10, 2013, at 10:13 AM, Paul Groth <p.t.groth@vu.nl> wrote:
>
>  Hi All,
>
>  I've made available an updated version of prov-overview at
>
>  https://dvcs.w3.org/hg/prov/raw-file/default/overview/prov-overview.html
>
>  Let me know if your happy with it.
>
>  Important updates:
> - changed the figure
> - added a section on our namespace
> - added a paragraph about how we meet the recommendations of the incubator
> group
>
>  Thanks
> Paul
>
>  --
>
> -----------------------------------------------------------------------------------
> Dr. Paul Groth (p.t.groth@vu.nl)
> http://www.few.vu.nl/~pgroth/
> Assistant Professor
> - Web & Media Group | Department of Computer Science
> - The Network Institute
> VU University Amsterdam
>
>
>


-- 
-----------------------------------------------------------------------------------
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Web & Media Group | Department of Computer Science
- The Network Institute
VU University Amsterdam