W3C home > Mailing lists > Public > public-dwbp-wg@w3.org > October 2015

Best Practices Cross-Reference Section

From: Laufer <laufer@globo.com>
Date: Mon, 19 Oct 2015 14:48:01 -0200
To: DWBP WG <public-dwbp-wg@w3.org>
Message-ID: <26f096becf03f6700802872599d83fa0@globo.com>

Hi, All, 

We have a scope issue since the beginning of the group around the type
of thing that we should deal with our Best Practices. As Phil pointed
during the last F2F, maybe the name of the group should be different, to
clarify in a better way the things the BPS refer. 

We have decided that the group will not treat things like the choice of
data, its domain, neither the way it is collected or how to guarantee
data quality, etc.. We decided, too, that we will not treat only Linked
Data Publications. Maybe a more appropriate name could be Data on the
Web Publishing Best Practices (as Phil has talked about). 

We have now a long discussion about how to facilitate the reading of our
document and the term webby has been introduced by Eric. I think it is a
very good way to see the things but I also think that we have to deal
with features of a published document that are not so directed to this
term. And, again, we have to deal with not LD things, as CSV files, for

In our work process we have started with collecting a set of use cases
and then we listed a set of requirements that should be took into
account in the BPs. We defined a template for the BPs where we have a
Why and an Intended Outcome sections that should, in some sense, address
these requirements. But we do not have an explicit relation between the
requirements and the BPs. 

I think that a way to facilitate the user that want some guidance in how
to publish a document with best practices, is to give a cross-reference
of these BPs, using some taxonomy that would consider the requirements
and the features for a webby data proposed by Eric in [1], and other

Each Bp has each own Why and Intended Outcome, but there are common
features (characteristics, criteria, I do not know the better term...)
that could group BPs ins a way to help a Publisher to achieve a more
clear objective. 

Bernardette has listed some of these characteristics that she collected
from the BPs [2]. 

I made an exercise highlighting some sentences (mainly verbs) used in
the Why and Intended Outcome sections of the BPs. I think that we could
make a collective effort to define a taxonomy and create a BPs
Cross-Reference with an explanation of how to use this cross-reference
section as a guidance to the reading of BPs. 

-- Erik List

-- Bernadette List

-- BPs Highlights
Humans Understand the Metadata
Machines Process the Metadata
Humans Understand the Nature of the Dataset
Machines Automatically Discover the Dataset
Understand and Manipulate the Data
Improve Re-Use of Data
Interpret the Meaning
Enable Automated Translation Services
Understand Internal Structure
Automatically Process the Structural Data
Assess the Usability of Data
Understand Possible Restrictions On the Use of A Distribution
Know the Origin or History of Data
Easy the Dataset Selection
Increase Chances of Re-Use
Document Data Quality
Document Quality Issues
Uniquely Identify A Dataset
How Data Changed Over Time
Understand How the Dataset Typically Changes from Version To Version
Understand How Any Two Specific Versions Differ
Enables Data Identification and Comparison
Pre-Condition For Proper Data Management and Re-Use
Datasets Must Be Discoverable and Citable Through Time
Refer to a Specific Version of a Dataset and to Concepts Such as a
'Dataset Series' and 'the Latest Version'
Machines Easily Read and Process Data Published On the Web
Data Consumers Use Computational Tools Typically Available In the
Relevant Domain to Work With the Data
Data Consumers Re-Use of Data Without Investment in Proprietary Software
Work With the Data Without Transforming It
Enable Interoperability and Consensus Among Data Publishers and
Encourage Re-Use of the Data
Data Should Not Be More Complex to Produce and Re-Use Than Necessary
Data That Can Identify an Individual Person Must Not Be Published
Without their Consent.
Provide Access to Bulk Data
Provide Machines Data Access in a Variety of Formats
Provide Data Access Using Browser s a Client
Provide Real-Time Access to Critical Time Sensitive Data
Provide Data Up-To-Date
Explicit Update Frequency of Data
Make API Versioning Separated from Data Versioning
Keep the Old Versions of APIs
Make Possible To Read and Load a Dataset into a Database Even if its
Software is no Longer Supported
Improve the Quality of Published Data
Encourage Publication of New Data Help Data Publishers Understand Data
Consumers Needs 
Enhance the Consumers' Collaborative Experience
Make Data a More Valuable Asset 

[1] http://dret.github.io/webdata/ 




. . . .. . . 
. . . ..
. .. . 

Received on Monday, 19 October 2015 16:48:36 UTC

This archive was generated by hypermail 2.3.1 : Monday, 19 October 2015 16:48:37 UTC