On Wed, Dec 28, 2016 at 5:08 PM, Karl Dubost <kdub...@mozilla.com> wrote: > David, > > Le 29 déc. 2016 à 09:15, L. David Baron <dba...@dbaron.org> a écrit : >> Data on the Web Best Practices >> https://www.w3.org/TR/dwbp/ > > I didn't participate to this group and this document, but I went through it > today.
I also did not participate in this group or document, and wasn't going to go through it (generally suspicious from experience of any W3C spec with "data" in the title), but since Karl thought it was worth going through, thought I would take a look as well. >> My inclination is to abstain from this review, but could probably be >> convinced to send other forms of supportive response. > > There's nothing to implement on the browser side from Mozilla wrt to this > specification, I agree with this conclusion (though I suspect we may have different reasoning). > but the best practices which are given into the document are quite good, I have to dispute this assertion, or at a minimum ask what is meant by "good". If by "good" we mean the modern interpretation of good open web standards, which is to document growing and broadly interoperable (publishing and consuming) standards, then this specification fails that so dramatically that it's laughable.*(expansion in footer) From a quick skim, it appears this spec reflects a small set of niche publishers on the web, rather than what the open web as a whole has emergently adopted by both publishing and *consuming* code. (publishing any format or data, without involving consuming code, over time, is next to useless and subject to noise, rot, as well as outright deception, see also Metacrap by Doctorow). E.g.: the specification mentions a bunch of "namespaces" (nevermind that being a red flag itself) explicitly: http://www.w3.org/TR/dwbp/#namespaces Most of which appear to be tired old W3C (mostly) academic attempts to make RDF a thing (no pun intended). > well articulated, I'm not sure how to evaluate that. As is usual with RDF based documents, the spec seemed quite abstract. > with a nice regular template for each best practice. I think we have a different understanding of "template". The only "template" in the spec is for individual best practice *descriptions* in the spec, not best practices of data publishing. In addition, a single data "template" (as example) is provided of a bus stop timetable: http://www.w3.org/TR/dwbp/dwbp-example.html > It's easy to read and easy to use. I think we have a different understanding of "easy", or perhaps "read" or "use". > And one is basically free to pick-up the elements that will improve his/her > data collections for sharing. I think we have different understandings of "improve" and "sharing". For one, sharing depends on data consumers, which the spec (and implementation report) recognize as important, but are scant to actually document (typical for RDF). Bottom line recommendation for AC vote: =============================== Explicit "Abstains from review". Comment: In our opinion, there's nothing to implement on the browser side WRT this specification. In general we don't think this specification reflects actual deployed and growing modern data publication and consumption practices on the open web of 2016, however practices therein seem (mostly) harmless. =============================== Meta-summary: * Not worth time fighting. I think we should not object to this spec, as it will simply waste time fighting with academics who have time to waste (may even be paid / grant funded to do so), including by publishing PDF papers about it (not actually using web standards, nor even the formats in this spec). * Bad data practices may slow or counter hostile/oppressive gov use-cases. Another consideration (for passively allowing this spec), especially per the spec's explicit frequent mentions of government data use-cases, is that if these practices are as bad as I suspect they are (per noise, rot, deception comment above), then the adoption (by governments are other such large institutions) of poor quality and unconsumed data practices may actually have the indirect side-effect be *good* for individual user privacy by way of the failure of such systems that follow the advice in this spec. Tantek *Laughable because the spec doesn't even bother to *mention* (except barely in one case), the data on the web practices that have *actually* become widely published *and* consumed (pretty much expect most people here to have heard of most of these in contrast to the RDF namespaces that W3C's spec mentions) Zero mentions of: * Atom feed format — still plenty of publishers and independent consumers, despite Google Reader shutdown * microformats — check any Web Data Commons crawl stats for publication for the past 5 years (back to 2012), shows adoption in excess of any of the namespaces provided by the W3C spec, and growing *consumption* beyond search engines by numerous IndieWeb (mostly open source) implementations on tens of thousands of websites on the open web * Facebook's Open Graph Protocol — Web Data Commons crawl ibid, actively consumed by Facebook, Twitter, Slack, Pinterest, etc. * Twitter Cards — not as popular as OGP but still growing and consumed by Twitter, Slack, etc. One unlinked/unreferenced mention: * RSS — mentioned *once* as an offhand example without any acknowledgement as to its (still) wide deployment (similar to Atom as noted above) One "practice" mention: * Schema.org – actually mentioned in the spec, but only specifically for "Provide data license information" best practice, as well as recognized as "massively adopted", yet somehow didn't merit inclusion in their "Namespaces" summary. One possible explanation for this wide discrepancy (of "best" and "data") is that the "Web" that this working group and spec are looking at / recommending "Best Practices" for, is not the same Web that Mozilla builds a browser for. _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
