Re: Updates on BP Provide data up to date and BP Make feedback available

Hi Bernadette,
Thanks for working on improving these two BPs. I took a look at what 
you've done so far, and I still have some concerns about them. I'll 
address the Up to Date BP first.

Intended Outcome
" New or updated data will be published to coincide with the update 
frequency". It's not clear that you're talking about two different 
things getting updated(the newly available data offline and the copy on 
the web).

What do you think about this? "Data on the web will be updated in a 
timely manner so that the most recent data available online generally 
reflects the most recent data released via any other channel. When new 
data becomes available, it will be published on the Web as soon as 
practical thereafter."

Implementation
This needs a little editing. The differences between bulk access and an 
API don't really work, because data can be provided in bulk through an 
API, and the requirements are essentially the same for both. Here's a 
suggestion:
" New versions of the dataset can be posted to the web on a regular 
schedule, following the Best Practices for Data Versioning 
<http://w3c.github.io/dwbp/bp.html#dataVersioning>. Posting to the web 
can be made a part of the release process for new versions of the data. 
Making web publication a deliverable item in the process and assigning 
an individual person as responsible for the task can help prevent data 
becoming out of date. To set consumer expectations for updates going 
forward, you can include human-readable text stating the expected 
publication frequency, and you can provide machine-readable metadata 
indicating the frequency as well."

Example
I like the example, but there is some new text that is problematic. " 
The issue date (|dct:issued|) of the dataset can be used as the basis 
for the creation of new versions." I don't know what you mean to say 
with that. If you are making a new version, the original version will of 
course be used as the basis of the new one, but that has little to do 
with the issue date or with making sure the update frequency is 
adequate. "It is important to note that new versions can be created when 
necessary, however the publisher must ensure that the dataset will be 
updated according to the predefined update frequency." This is another 
example of the confusion between updating the available data and 
updating the web publication. In the example RDF, the date for the 
previous version is later than the date for the new version. I think you 
mean to say "It is important to note that new versions can be created 
sooner than the schedule calls for, but the publisher should ensure that 
extra versions are published to the web as quickly as their scheduled 
counterparts."

Test
The issue date would be the date the data are made available, but there 
may be inordinate delay between issuing the data and posting it on the 
web. I think you have to check that the update frequency is stated and 
that the most recently published copy on the Web is no older than the 
date predicted by the stated update frequency.

For the Feedback BP,

Subtitle
I think keeping the word "consumer" in there would be good.

Why
I think it should include the idea that publishers benefit from avoiding 
duplicate bug reports, and that it also helps consumers understand any 
issues that may affect their ability to use the data. For me, supporting 
a collaborative environment or a feeling of community is not really what 
I'm looking for, unless the site is one I plan to use frequently for 
other reasons. If you need some words, how about "By sharing feedback 
with consumers, publishers can demonstrate to users that their concerns 
are being addressed, and they can avoid submission of duplicate bug 
reports. Sharing feedback also helps consumers understand any issues 
that may affect their ability to use the data, and it can foster a sense 
of community among them."

Intended Outcome
This is better, but it's still not saying what I was hoping it would 
say. How about this?

"Consumers will be able to assess the kinds of errors that affect the 
dataset and be reassured that the publisher is actively addressing 
issues as needed. Consumers will also be able to determine whether other 
users have already provided similar feedback, saving them the trouble of 
submitting unnecessary bug reports and sparing the maintainers from 
having to deal with duplicates."

Test
I would say " Check that any feedback given by data consumers for a 
specific dataset or distribution is publicly available. "

On 5/2/16 7:46 AM, Bernadette Farias Lóscio wrote:
> Hi Annette,
>
> As agreed in our discussions last week, I rewrote the following best 
> practices:
> - Provide data up to date [1]
> - Make feedback available [2]
>
> The corresponding commits are [3] and [4]. If necessary, I can make 
> new updates after having your feedback as well as the feedback from 
> the rest of the group.
>
> Thanks!
> Bernadette
>
> [1] http://w3c.github.io/dwbp/bp.html#AccessUptoDate
> [2] http://w3c.github.io/dwbp/bp.html#FeedbackInformation
> [3]https://github.com/w3c/dwbp/commit/43ba83a77ecbcdd03d2e9066bedd5f7df482c2e4
> [4] 
> https://github.com/w3c/dwbp/commit/72ff174f59e2cfe1b1dcda51b1f135daefef39ed
>
>
> -- 
> Bernadette Farias Lóscio
> Centro de Informática
> Universidade Federal de Pernambuco - UFPE, Brazil
> ----------------------------------------------------------------------------

-- 
Annette Greiner
NERSC Data and Analytics Services
Lawrence Berkeley National Laboratory