Re: dwbp-ACTION-123: Call for comments

Hi Phil and Annette,

Thank you very much for your comments!

I'd like to make one more comment about the organization of the document.

>
>>
>> Thus far, the BPs we have listed are not aimed at developers, and I think
>> that is true to our charter. Take a look at the list of Requirements[1]
>> thus far and see if you can identify anything that specifies an action to
>> be taken by a consumer of the data.
>>
>
> Actually there are a couple:
>
> R-TrackDataUsage
>   It should be possible to track the usage of data
>
> R-IncorporateFeedback
>   Data consumers should have a way of sharing feedback and rating data.
>
> R-UsageFeedback (arguably the same as the first one)
>   Data consumers should have a way of sharing feedback and rating data.
>
> But... taking your point on board I wonder whether we should consider a
> separate document for consumers. A sort of 'what to look for, how to find
> it, how to use it, why it's in your interests to feedback to the data
> producer' etc.
>
> Or maybe a separate section at the end? i.e. make it clear what advice is
> for data publishing and what is for consumption.


The idea of organizing the BP according to the Data on the Web Lifecycle is
that we may organize BP according to specific tasks and actors. In the
current version, there are three sections:

6.1 Best Practices for Data Creation and Publication
6.2 Best Practices for Data Access, Refinement and Archiving
6.3 Best Practices for External Use and Feedback

In my opinion, Sections 6.1 and 6.2 will have BP for data publishers, while
section 6.3 will have BP for data consumers.

I'm not sure if it is a good idea to have a separate document or a separate
section for consumers. In fact, this decision will be easier when we have
an agreement about our audience, i.e., our audience concerns both data
publishers and data consumers or just data publishers?

In my opinion, we should consider both. Maybe, we should talk abou this
during our meeting today.

kind regards,
Bernadette






>
>
>
>
>  I would not expect someone who is about to use someone else’s data to
> review the types of best practices we have been talking about.
>
>>
>> These principles determine how data is made available, and that in turn
>> determines how developers can use it. I hope that we will come up with
>> practices that enable broad, innovative use. Telling consumers how to use
>> data on the web seems to me not only beyond the scope of our group, but
>> also even potentially a barrier to innovation. It is crucial, however, that
>> *publishers* provide information that tells developers how they *can* use
>> the data they have published on the web.
>>
>
> OK, makes sense.
>
>
>> Of course, publishers employ developers to put data online, and new apps
>> and visualizations are created by consumers of published data. In re-using
>> data, a consumer may become a publisher of data, but it is only in that
>> capacity that he/she would be interested in this document. Its scope would
>> increase tremendously if we were to attempt to include guidance for
>> creating apps or visualizations.
>>
>
> Oh we're definitely not going that far. New work is being talked about for
> data vis.
>
>
>> Because of the way the term “data broker” is getting used in the media, I
>> would prefer we not use it. It has negative connotations for many, as it is
>> associated with privacy invasion and surveillance. See, for example,
>> http://www.cbsnews.com/news/the-data-brokers-selling-your-
>> personal-information/
>>
>
> You've convinced me on the term broker. I do think it's within scope,
> somehow, however, to use BPs as guidance on what steps can be taken to add
> value to data, by providing APIs, enrichment, metadata etc.
>
>
>> -Annette
>>
>> [1] I’m not sure why we are calling these “Requirements". The term
>> suggests that datasets will either pass or fail. I think we want to be more
>> granular than that. If we need to have a list of requirements for the
>> document, that should contain things like “the document should” rather than
>> “data should”.
>>
>
>
> I agree. I'm suggesting that we use MUST, SHOULD and MAY in each of the
> 'intended outcome' sections of each BP. That gives us normative language
> and something to test.
>
> I believe we are in agreement - and I appreciate your helpful comments
> here.
>
> Phil.
>
>
>
>> --
>> Annette Greiner
>> NERSC Data and Analytics Services
>> Lawrence Berkeley National Laboratory
>> 510-495-2935
>>
>> On Dec 11, 2014, at 7:13 AM, Phil Archer <phila@w3.org> wrote:
>>
>>
>>>> Because we are really targeting publishers of data, I think the first
>>>> few sentences are unnecessary.
>>>>
>>>
>>> -1
>>>
>>> I don't agree that we're only targeting publishers. The charter includes
>>> this:
>>>
>>> "Developers would like easy access to data that is 100% accurate,
>>> regularly updated and guaranteed to be available at all times. Data
>>> publishers are likely to take a different view. There are disparities
>>> between different developers too: for many, data means CSV files and APIs,
>>> for others it means linked data and the two sides are often disparaging of
>>> each other."
>>>
>>> So it talks about developers as much as publishers.
>>>
>>> The data usage vocab is a clear example where users are in scope.
>>>
>>> It's also often the case that data publishers are also data users and,
>>> actually, I rather like the term data broker (a much nicer word than the
>>> horrible mangling of the English language that the European Commission
>>> uses: 'Infomediary' - gah!). Data brokers seem particularly relevant if
>>> we're talking about data enrichment etc.
>>>
>>> So personally, I like a lot of what Laufer has captured, modulo trivial
>>> editorial nit picks.
>>>
>>>
>>> Phil Archer
>>> W3C Data Activity Lead
>>> http://www.w3.org/2013/data/
>>>
>>> http://philarcher.org
>>> +44 (0)7887 767755
>>> @philarcher1
>>>
>>
>>
>>
> --
>
>
> Phil Archer
> W3C Data Activity Lead
> http://www.w3.org/2013/data/
>
> http://philarcher.org
> +44 (0)7887 767755
> @philarcher1
>
>

-- 
Bernadette Farias Lóscio
Centro de Informática
Universidade Federal de Pernambuco - UFPE, Brazil
----------------------------------------------------------------------------