Proposed response to PROV-AQ comments from James Anderson (updated)

Dear James,

Thank you for your comments and observations about PROV-AQ 
Our response, interleaved with your original comments follows:


upon reading prov-aq with the goal to implement access to provenance
information for repositories in the dydra triple store, i observe
inconsistent intentions with respect to that document's role in the
specification. the document suggests, that it is intended to become a
recommendation, while the overview states, that prov-aq is to be
published as a note. should the latter be the true intent, some of
the its exposition should be removed to a normative document before
they are final. implementors will not be well-served if prov-aq
remains a note, but is written in terms of concepts which are
introduced there, without mention in either prov-o or prov-dm.

>>> Response:
Our apologies, there was an error in the status section of which gives rise to this 
confusion.  This document has always been targeted to be just a note.  (We've 
used specification language in places to try and make things clear for 
implementers, but there is no intent to claim that the document is intended to 
have recommendation status.)

The charter of the working group does not include the preparation of a 
recommendation-track specification for access and query.  Also, while the 
representation of provenance is backed up by considerable experience to be the 
basis of standardization, there is much less experience of how this might be 
used and accessed at web-scale, so at this stage a non-normative NOTE is 
considered to be an appropriate precursor to possible future standardization 
activity when there is greater operational experience to guide it.

The text in the latest version of this document has been revised to better align 
with concepts covered in the normative documents of the PROV series, so this 
will hopefully address some part of your comment.

in "1.1 Concepts", the term "constrained resource" appears, with
reference to prov-dm and to webarch, but the term fails to appear in
either of those documents. the latter absence does not surprise. but
one would expect it to have been introduced and defined in some other
prov document which is more central than a "note".  the same
situation applies to "target-uri".

>>> Response:
The text here has been re-worked, with explicit references to "entity" and 
"specialization" in PROV-DM.  See

in "1.2 Provenance and resources" the concepts are sufficiently
central to the notion of provenance, that a reader could expect the
passage to have appeared, for example, in prov-dm, section 2.1 rather
than prov-aq.  central concepts should be defined completely in a
nomative document - for example, some combination of -o and -dm, with
the -aq document restricted to how access is to be provided to
already defined entities.  as the documents stand, the reader must
rely on the content of a non-normative note for their understanding
of basic concepts required to implement access to provenance

>>> Response:
We hope and expect that the PROV-DM and other documents contain sufficient 
information to fully explain the concepts they introduce, and are not in any way 
dependent on PROV-AQ.  Beyond that, the purpose of this document is different 
from the provenance model and representaton documents, so I think it's 
reasonable that some of the explanatory material here is not really suitable for 
inclusion in those documents.

The content text in PROV-AQ is intended to build on these ideas to put the 
access and query in a context of retrieving stable information about dynamic 
resources, in a way that was difficult to achieve just by reference to the other 
documents.  The text has now been updated to make more explicit reference to the 
relevant PROV-DM concepts.

the document would be improved, if some diagram were present to
illustrate how the respective entities are made available in a
concrete case by a service - or by distinct services, which afford
access to  versioned and or derived resources and respective
provenance information.

>>> Response:
This bears thinking about - I've added this to a list of things to be 
considered, if time permits.

in section 3, the paragraph which begins "we start by" includes a
list which describes three situations regarding the requester's
knowledge of a resource uri. it is not evident, which "resource uri"
is here the object? is it the provenance, the service, a target, or
the about resource itself?\

>>> Response:
This text has been re-worked in a way that hopefully makes the intent clearer.

Further change to the first bullet to read "The resource whose provenance is 
required is accessible using HTTP, and the provenance consumer knows its URI" is 
under consideration.

from appendix b, the several terms which are to be added to the prov
namespace, should appear in a normative document, rather than in a
note: hasProvenance, hasProvenanceService, hasAnchor,
ProvenanceService, and provenanceUriTemplate.

>>> Response:
The WG had extensive discussion of this point.  The namespace itself is not 
normatively constrained, but the use of certain terms within the namespace is.

Per WG charter and consensus, these terms related to access and query are not to 
be normatively defined.  This is not a problem for the normative aspects of 
PROV, provided that care is taken to ensure that non-normative specifications 
like PROV-AQ do not create term definitions that conflict with normative 
specifications, which we have done.

Thank you again for your feedback.

Graham Klyne
(for PROV working group.)

Received on Wednesday, 20 March 2013 12:30:31 UTC