W3C home > Mailing lists > Public > public-prov-wg@w3.org > March 2013

Proposed response to PROV-AQ comments from James Anderson

From: Graham Klyne <graham.klyne@zoo.ox.ac.uk>
Date: Mon, 11 Mar 2013 11:53:14 +0000
Message-ID: <513DC5AA.7010901@zoo.ox.ac.uk>
To: W3C provenance WG <public-prov-wg@w3.org>
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
(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 

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:
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.

Received on Monday, 11 March 2013 11:53:46 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:51:32 UTC