Re: PROV-DICTIONARY internal review for first public working draft (ISSUE-614)

Hello Stian,

wow, and just when I thought I was done for the day... ;)
Thanks for the extensive review though, I'm sure the document will be
almost flawless after this revision.

Now, I do have one immediate question concerning your "No" to answer "Can
the document be published as a FPWD?".
I've gone over the issues. Some are already addressed, and most seem
addressable in the document itself, which can certainly be done by next
week.
However, some of your blocking issues (8b, 39) are to include links to the
downloadable extension grammar and xml schema. Is this really necessary for
a first working draft of a document on Note track? Because these files
still need to be created, which will consume some time, and additional
review. This seems strange to me, especially since the previous
(problematic) iteration of Dictionary made it to WD5 of PROV-DM...

Best regards,
Tom

2013/1/24 Stian Soiland-Reyes <soiland-reyes@cs.manchester.ac.uk>

> Forgot to respond to these:
>
> On Thu, Jan 24, 2013 at 3:05 PM, Stian Soiland-Reyes
> <soiland-reyes@cs.manchester.ac.uk> wrote:
>
> >> - Are the constraints acceptable, or are they too loose/too strict?
>
> They are almost perfect! This level of strictness is very appropriate
> for this specialization of prov:Collections.
>
>
> >> -- In particular, can the constraint "IF derivedByRemovalFrom(d2, d1,
> >> {"k1"}) THEN hadDictionaryMember(d1, e1, "k1") " be dropped, or do you
> >> strongly support it?
>
> I would have liked for this to be in as it is quite a nice constraint
> - but I can see supporting 'empty' removals is like a mirroring of
> allowing 'overwriting inserts' - and so I'm OK with removing this
> constraint. If had we kept it, there would also be a stronger case for
> explicitly mentioning e1 in derivedByRemovalFrom.
>
>
> --
> Stian Soiland-Reyes, myGrid team
> School of Computer Science
> The University of Manchester
>