- From: James Cheney <jcheney@inf.ed.ac.uk>
- Date: Mon, 29 Oct 2012 11:01:22 +0000
- To: James Cheney <jcheney@inf.ed.ac.uk>
- Cc: Provenance Working Group <public-prov-wg@w3.org>
I've closed this now. --James On Oct 25, 2012, at 5:57 PM, James Cheney wrote: > Hi, > > This pre-LC issue seems to still be open. It seems to now be addressed, except for some suggestions/comments about figures that remain in the LC working draft as "notes". I propose to close it if there is no objection in the next 24 hours. > > --James > > On Aug 30, 2012, at 7:15 PM, Provenance Working Group Issue Tracker wrote: > >> 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)? >>> >> >> >> >> >> > > > -- > The University of Edinburgh is a charitable body, registered in > Scotland, with registration number SC005336. > > > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.
Received on Monday, 29 October 2012 11:01:51 UTC