Re: Proposed response to PROV-AQ comments from James Anderson

Really nice Graham.

Paul


On Mon, Mar 11, 2013 at 12:53 PM, Graham Klyne <graham.klyne@zoo.ox.ac.uk>wrote:

> In the telecon, I mentioned one public comment to which there has not yet
> been a
> response.  The comment was slightly tricky for me to deal with as an
> editor of
> PROV-AQ, as some elements of it seem to call for changes to documents
> other than
> PROV-AQ.  Here is a proposed response.
>
> ...
>
> From: James Anderson
> (
> http://lists.w3.org/Archives/Public/public-prov-comments/2013Jan/0033.html
> )
> (james anderson <james@dydra.com>)
>
> ...
>
> 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:
> 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 the
> basis of standardization, there is much less experience of how this might
> be
> used 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.
>
> I don't know why you think "the document suggests that it is intended to
> become
> a recommendation".  This document has always been targeted as being just a
> note,
> and I had thought it makes that intent quite clear.  We've used
> specification
> language in places to try and make things clear for implementers, but I'm
> not
> aware of any claim that the document is intended to have recommendation
> status.
>
> 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
> http://www.w3.org/TR/2013/WD-prov-aq-20130312/#provenance-and-resources
> <<<
>
>
> 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
> information.
>
>  >>> Response:
> I 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 is not really suitable for
> inclusion in those documents.
>
> The content text here 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 I couldn't really 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.
> See
> http://www.w3.org/TR/2013/WD-prov-aq-20130312/#locating-provenance-records
>
> I'm considering a 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"
> <<<
>
>
> 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.  Non-normative specifications like PROV-AQ must take care
> not to
> create term definitions that conflict with normative specifications, which
> we
> have done.
> <<<
>
> #g
> --
>
>
>


-- 
--
Dr. Paul Groth (p.t.groth@vu.nl)
http://www.few.vu.nl/~pgroth/
Assistant Professor
- Knowledge Representation & Reasoning Group |
  Artificial Intelligence Section | Department of Computer Science
- The Network Institute
VU University Amsterdam