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

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

From: James Cheney <jcheney@inf.ed.ac.uk>
Date: Mon, 29 Oct 2012 11:01:22 +0000
Cc: Provenance Working Group <public-prov-wg@w3.org>
Message-Id: <6B0A2C96-7293-4A84-9F6D-AC2D82A1990D@inf.ed.ac.uk>
To: James Cheney <jcheney@inf.ed.ac.uk>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:58:20 UTC