Re: Review and next steps on PROV-CONSTRAINTS

James,

My apologies for doing this at the last moment, and somewhat rushed ...  my 
anticipated spare time this week kind of "evaporated".

I still haven;'t been able to give this the full reading it deserves, but I'll 
try to respond to your specific questions.

On 10/05/2012 17:26, James Cheney wrote:
> Q1.  [to Tim and Graham specifically] Does the FPWD of PROV-C address your blocking issues?

I'm pretty sure it does.  This document is such a revision from the previous in 
the respects that I've commented about that I'd consider previous comments 
closed and leave it to me to raise new ones if I feel the need.

> Q2.  Is the rationale for the existence of PROV-C (a) clear, and (b) something that seems worth doing?  If not, how to improve?

(a) does it really introduce new concepts?

(b) Looking at the abstract, I'd be inclined to re-state slightly:

This document describes some /validity constraints/ to which the provenance data 
model is intended to confirm, and some /inferences/ that may be drawn over 
provenance data that conforms to those constraints.

Rationale:  I'm trying to phrase this in a way that doesn't rule out naive use 
of provenance that doesn't fully conform, to the constraints, but that there are 
possible additional advantages to be had if provenance information does so conform.

> Q3.  Is the structure of PROV-C clear and appropriate?  If not, how to improve?

Yes.  The style and presentation appears to be quite appropriate to the nature 
of the material and my perception of thge likely intended audience.

> Q4.  Are the instructions regarding compliance clear and appropriate (modulo several clearly-marked TODOs)?  If not, how to improve?

Without reading in more detail, I have a question (which relates to my commet 
above):  compliance condition 1 says a processor MAY apply the inferences - 
should this qualified regarding the *validity* of the PROV instance (cf. item 3).

Apart from that, I like the approach, and would like to see it reflected 
informally in the introduction (cf. comments on abstract).

#g
--

Received on Thursday, 24 May 2012 15:03:39 UTC