W3C home > Mailing lists > Public > public-prov-wg@w3.org > April 2012

Re: Review prov-aq document

From: Graham Klyne <GK@ninebynine.org>
Date: Thu, 26 Apr 2012 14:52:48 +0100
Message-ID: <4F995330.1040608@ninebynine.org>
To: Curt Tilmes <Curt.Tilmes@nasa.gov>
CC: public-prov-wg@w3.org
Curt, thanks for your comments.  I've actioned most of them, hopefully 
addressing the issues you raise, with a couple of exceptions.  More details below:

On 23/04/2012 20:07, Curt Tilmes wrote:
> The latest PROV-AQ reads nicely and is ready for publication
> as a public working draft. I like the service specification.
>
> Here are some minor editorial points:
>
> --------------------------------------------------------------------
> General:
>
> Inconsistent capitalization "service-URI" vs. "Service-URI",
> and "target-uri" vs. "target-URI". "provenance-uri"
>
> Might just do a global search/replace "-uri" -> "-URI"?

Done.

>
> Status of This Document
> -----------------------
>
> "This document is part of a set of specifications produced by the W3C
> provenance working group aiming to define interoperable interchange of
> provenance information in heterogeneous environments such as the Web."
>
> take out "aiming to"
>
> Just say "...working group defining interoperable interchange..."
>
>
> Copy the edits from the "PROV Family" overview stuff from the
> DM document.

I've taken out "aiming"... but I think this should be treated in coordinated 
fashion across the set, rather than piecemeal for this document.  I also expect 
it will be updated as part of the publication process, so I'll leave it at that 
for now.


> 1.2 Provenance and resources
> ----------------------------
>
> "...as denoting the specification through its lifetime."
>
> I might prefer 'throughout'

Yes, that's better.  Done.

>
> 1.2 or 1.3 should probably discuss multiple provenance accounts about
> the same resource?
>

Can we raise this as an issue for the next round?  I think it needs careful 
treatment to avoid getting into describing what is not required (or prohibited), 
which tends not to be helpful in a specification document.  So while I would 
accept that a statement could be helpful, I think it should be carefully crafted 
to not raise more questions than it answers, so don't want to try and do it in a 
rush this close to publication.

>
> 3.1 mentions "may include multiple provenance link header fields",
> maybe mention accounts more explicitly here? You could have a
> different account describing different provenance for the same
> resource.

See above.  (I thought we had converged from earlier discussions to a reasonable 
balance here.)

(Aside:  I think discussing "Accounts" here would be confusing - that's a DM 
concept.)

What I do see, and note that it is somewhat buried, is the final para in 3.1:

[[
Provenance resources indicated in this way are not guaranteed to be 
authoritative. Trust in the linked provenance information must be determined 
separately from trust in the original resource. Just as in the web at large, it 
is a user's responsibility to determine an appropriate level of trust in any 
other linked resource; e.g. based on the domain that serves it, or an associated 
digital signature. (See also section 7. Security considerations.)
]]

I think this bears on the issue you raise, and should be stated more up-front. 
I've added a variation of this paragraph to section 1.3.

>
> 3.2 "<Link>"
>
> just for consistency with the other fields, I wouldn't capitalize
> just use "<link>"

Good catch!  Done.

>
> 3.3 "..are defined in the following."
>
> "defined as follows.", or "defined in the following way."

Done.

>
>
> "...specifies a service-URIs associated with..."
>
> extraneous plural service-URIs?
>

Fixed.

>
>
> 3.4 Might include a specific reference to ISO19115-2 in the examples
> here. I'm not expert enough to recommend specific wording for that,
> but I'll check with Hook Hua -- he may recommend something to put
> here.

I'm not sure how that applies... AFAICT from a cursury Google query, it's a 
geo-referencing standard.

This shouldn't be a big deal; the examples are meant to be indicative, not 
exhaustive, so mentioning things that are (more) widely recognized is more 
helpful, IMO.

>
> 4. Provenance services
>
> one of the references to "target-uri" is not linked to the definition
> (perhaps that is by design?)

My general approach has been to link first occurrences in each section, to avoid 
making the document look totally cluttered with hyperlink indications.  And not 
always that.  I've been aiming for balance and utility rather than consistency 
here (though without guarantee of success at that :) )


>
> 5.1 "... information for an resource is not...
>
> for a resource

Fixed.

>
>
> 7. Since this is a "considerations" section, maybe include a mention
> of "provenance of provenance":
>
> Just as provenance information can help determine trust of the
> information content of a resource, provenance information related
> to the provenance itself ("provenance of provenance") can help
> determine trust of the provenance.

I've added a TODO with that suggestion.  (The whole "Security considerations" 
section needs to be updated, but I didn't want to spend cycles on that until we 
were reasonably confident of the base document.)

>
> ------------------------------------------------------------------------
>
Received on Thursday, 26 April 2012 14:03:34 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 26 April 2012 14:03:36 GMT