Re: dwbp-ACTION-123: Call for comments

Hi all,



I feel happy that my simple text has fed these deep discussions. For me,
there is no problem in suppressing or changing parts of the text. But I
completely disagree that the audience of the document are only “data
publishers”. I think that the fact that we are dealing with data and
metadata (data about data), mix different things. Data and metadata are not
the same.



I think that we are talking about data (the Dataset) and all the things we
think are valuable to help a consumer of this Dataset to use it. Metadata
are one of them. Defining cool URIs, preservation schemes, are others. The
comments and tips that consumers post could help consumers too. And so on.



I think that there are a lot of different roles working to do this, all of
them working around a Dataset that is published. And we are trying to
define best practices for some of them. Metadata are published, but this
not means that the role of the person that do that is, for sure, a “data
publisher” (“metadata publisher”?). And what about things that are not
metadata? What is the role of the person that is responsible for defining
the data preservation scheme? What is the role of the person that is
responsible for defining the URI naming scheme?



We can have examples of other areas that deal with things different from
data. In a talk of Tim Berners-Lee, about Semantic Web, he uses a Snack
package to show a lot of different information printed in the package, that
help users to buy and to consume the Snack (nutrition facts, composition,
product quality seals, etc.). Besides that, we have the designers of the
package, the CRM, a site about the product, etc.. All of them are things
that could help a user to choose a product. Someone could define best
practices for things that help the user, generated by persons with
different roles.



In another example, I also do not think that all the people that work in a
Publisher, and do things that help the consumer to choose and to buy, for
example, a Magazine, or a Book, have the single role of "data publisher".
And all the people in a Publisher have to follow best practices that could
help the consumer to consume a Magazine.



Well, again, no problem in changing the text. I already did a new version
of the text suppressing things. But I do not agree with the idea that we
are talking to only one role in this process. Many roles are related to
Data on the Web Best Practices.



Cheers,

Laufer

2014-12-12 9:11 GMT-02:00 Phil Archer <phila@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 12:43:48 UTC