W3C home > Mailing lists > Public > public-prov-wg@w3.org > August 2012

PROV-ISSUE-490 (prov-constraints-lc-editorial): PROV-CONSTRAINTS pre-Last Call editorial issues [prov-dm-constraints]

From: Provenance Working Group Issue Tracker <sysbot+tracker@w3.org>
Date: Thu, 30 Aug 2012 18:15:56 +0000
Message-Id: <E1T79HY-0001Cj-VY@tibor.w3.org>
To: public-prov-wg@w3.org
PROV-ISSUE-490 (prov-constraints-lc-editorial): PROV-CONSTRAINTS pre-Last Call editorial issues [prov-dm-constraints]

http://www.w3.org/2011/prov/track/issues/490

Raised by: James Cheney
On product: prov-dm-constraints

This issue collects remaining editorial issues in PROV-CONSTRAINTS to remind editors to fix them before last call release.

Some of these may already be done; they were listed as needing work in the reviews, though.

1.  Make rule names uniform, as suggested by Paul.

2.  Tim's suggestions about the figures. 

3.  Stian's concern about the summary table and figures.

-- Details --


1. Make rule names uniform, as suggested by Paul:

  > 
   > Minor Notes:
   > 
   > - PROV objects or prov constructs - check the consistency on this
   > - inconsistency with naming. Do you always want to end inference with
   > "-inference". See Inference 11 (derivation-generation-use) and
   > Inference 10 (wasEndedBy-inference)
   > 

The terminology 'prov construct'  is not present (anymore) in the document.

I updated some of the names, but still:
TODO: make rule names more uniform.

2.  Update figures following suggestions from Tim:

   > 
   > 
   > 37)
   > 
   > Figure 1
   > I would think that the label numbering on the activities would be
   > reversed: a1 starts before a2 starts before a3. 
   > 
   > suggest changing labeling for more natural order.
   > 
   > 
   > 

  > 
   > 52)
   > 
   > The visual style in Figure 2(a), where the orange constraint triangle
   >    > extends to touch the events that it orders, is not used in the
   >    > remaining portions of the figure. 
   > 
   > suggest to carry this convention into the rest of the subfigures.
   > 

  > 53)
   > 
   > Figure 2
   > 
   > 
   > "are represented by vertical dotted lines (…, or intersecting usage and generation edges)"
   > 
   > 
   > There seems to be visual ambiguity in the visual style convention. Is
   > the time of the usage/generation at the location the (Activity,Entity)
   > arrow crosses the vertical line? How does that intersection point
   > differ from the point that the line connects to the activity (for
   > generation) or entity (for usage)? If these two points were made one
   > in the same, would there be any loss of information? Eliminating any
   > visual distinctions that are not encoding the underlying model will
   > help avoid confusion and distraction while reading the figures. 
   > 
   > 
   > 54)
   > 
   > 
   > Figure2
   > 
   > A note on my note: "Miscellanous suggestions about figures (originally from Tim Lebo):"
   > 
   > The suggestion is to make the diagonal solid arrow be dotted, like the vertical "usage" line.
   > 
   > 
   > Further, I'd suggest to make the timeline a solid line, to distinguish from the event style.
   > 
   > What is the purpose of the dotted horizontal line on the bottom of each subfigure?
   > 
   > 
   > 
   > 
   > Suggest to make the start and end vertical lines BLUE to match the activity.
   > 
   > 


3.  Stian's concern about the summary table:

   > 
   > 2.3 Summary of constraints..
   > 
   > 
   > This table is utterly confusing to me as it is not a summary, it does
   > not tell me anything, and I don't understand the columns. (Not helped
   > by the lack of colours and borders on a print out!)
   > 
   > I can see it is useful to have a kind of index of all the constraints,
   > but the table needs some work to be understandable. In the web version
   > it is kind-of OK, since the constraints have human readable names -
   > but is there a reason to keep the third column rather than simple
   > horisontal headers? Perhaps even the Type/Relation column could be
   > done as headers?
   > 

   > 
   > 
   > > 5.2.2 Entity constraints
   > 
   > Figure 3b) implies that the deriving activity starts *after* usage and
   > finishes *before* generation. extend blue box to extend beyond both
   > dotted vertical lines.
   > 
   > I don't understand 3c), something seems to be missing. The lower arrow
   > from e2 has no label (was derived from?), and there are no activities.
   > 


   > Constraint 38 and 40 are not shown in Figure 3.
   > 
   > 


   > 
   > Figure 5a) is very difficult to understand, as the extent of the two
   > triangles is not shown. Could this be added, such as in 2a)?
   > 
Received on Thursday, 30 August 2012 18:15:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:19 UTC