- From: Phil Archer <phila@w3.org>
- Date: Fri, 12 Dec 2014 11:11:06 +0000
- To: Annette Greiner <amgreiner@lbl.gov>
- CC: Laufer <laufer@globo.com>, Data on the Web Best Practices Working Group <public-dwbp-wg@w3.org>
Thanks very much for this, Annette. Comments inline below. On 11/12/2014 20:34, Annette Greiner wrote: > Phil, > I think you are confusing being a stakeholder with being a part of the audience. It may seem like a fine point to some, but I’m sure you, as someone who has worked as a professional writer (we should trade war stories some day), will appreciate the fundamental importance of having agreement on who our audience is. All the decisions about what to include in the BP doc and how to frame it should flow from that. The usage vocabulary is a different document; I’m talking about the Data on the Web BP document specifically. Fair enough. > > The paragraph you quoted makes it clear that developers are stakeholders in the group’s work, but I don’t think that means they are our audience for all our documents. What I glean as guidance from the paragraph is that we, as a group, need to be cognizant of the various disagreements that exist about how data should be published online. It explains that developers want perfect data but that publishers have to take a more realistic view. The group needs to take account of both sides and make some recommendations that both sides can embrace. To my mind, that is the sort of stuff that we can provide the most helpful guidance about, the stuff that will foster trust and enable change. Ack. A publisher would likely ask, “how complete does my metadata need to be to be useful? How important is it that I make data available as an API? Where could I best spend my limited resources to make my data useful to others?” I think we can be a big help to publishers by recommending reasonable responses to those types of difficult questions. I think that's a really good set of questions that we should try and answer. > > 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. 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
Received on Friday, 12 December 2014 11:10:40 UTC