DWBP Evidences Form

Thank you for your help to collect implementation evidence of the Data on the Web Best Practices (DWBP), a document to be released as a W3C Recommendation in 2016.

There are 35 forms, each one of them is referring to one Best Practice and there is the possibility to create more evidences for each BP.

The Data on the Web Best Practices document is available at https://www.w3.org/TR/dwbp.

The Organization name will be mentioned as one of the organizations that tested the Data on the Web Best Practices in order to become a W3C Recommendation.

You may want to start filling the Organization's info form and then filling the respective forms for the best practices you have implemented.

Organization's info
Best Practice 1: Provide metadata

How to test:

Check if human readable metadata is available.

Check if the metadata is available in a valid machine-readable format and without syntax error.



Best Practice 2: Provide descriptive metadata

How to test:

Check if the metadata for the dataset itself includes the overall features of the dataset in a human-readable format.

Check if the descriptive metadata is available in a valid machine-readable format.



Best Practice 3: Providelocale parameters metadata

How to test:

Check if the metadata for the dataset itself includes information about local parameters (i.e. data, time, number formats, and language) in a human-readable format.

Check if the metadata with locale information is available in a valid machine-readable format and without syntax errors.



Best Practice 4: Provide structural metadata

How to test:

Check if the structural metadata of the dataset is provided in a human-readable format.

Check if the metadata of the distribution includes structural information about the dataset in a machine-readable format and without syntax errors.



Best Practice 5: Provide data license information

How to test:

Check if the metadata for the dataset itself includes the data license information in a human-readable format.

Check if a user agent can automatically detect /discover the data license of the dataset.



Best Practice 6: Provide data provenance information

How to test:

Check that the metadata for the dataset itself includes the provenance information about the dataset in a human-readable format.

Check if a computer application can automatically process the provenance information about the dataset.



Best Practice 7: Provide data quality information

How to test:

Check that the metadata for the dataset itself includes quality information about the dataset.

Check if a computer application can automatically process the quality information about the dataset.



Best Practice 8: Provide a version indicator

How to test:

Check if the metadata for the dataset/distribution provides a unique version number or date in a human-readable format.

Check if a computer application can automatically detect/discover the unique version number or date of a dataset or distribution.



Best Practice 9: Provide version history

How to test:

Check that a list of published versions is available as well as a change log describing precisely how each version differs from the previous one.



Best Practice 10: Use persistent URIs as identifiers of datasets

How to test:

Check that each dataset is identified using a URI that has been designed for persistence. Ideally the relevant Web site includes a description of the design scheme and a credible pledge of persistence should the publisher no longer be able to maintain the URI space themselves.



Best Practice 11: Use persistent URIs as identifiers within datasets

How to test:

Check that within the dataset, references to things that don't change or that change slowly, such as countries, regions, organizations and people, are referred to by URIs or by short identifiers that can be appended to a URI stub. Ideally the URIs should resolve, however, they have value as globally scoped variables whether they resolve or not.



Best Practice 12: Assign URIs to dataset versions and series

How to test:

Check that each version of a dataset has its own URI, and that there is also a "latest version" URI.



Best Practice 13: Use machine-readable standardized data formats

How to test:

Check if the data format conforms to a known machine-readable data format specification.



Best Practice 14: Provide data in multiple formats

How to test:

Check if the complete dataset is available in more than one data format.



Best Practice 15: Reuse vocabularies, preferably standardized ones

How to test:

Using vocabulary repositories like the Linked Open Vocabularies repository or lists of services mentioned in technology-specific Best Practices such as the Best Practices for Publishing Linked Data [[LD-BP]], or the Core Initial Context for RDFa and JSON-LD, check that classes, properties, terms, elements or attributes used to represent a dataset do not replicate thosedefined by vocabularies used for other datasets.

Check if the terms or codes in the vocabulary to be used are defined in a standards development organization such as IETF, OGC & W3C etc., or are published by a suitable authority, such as a government agency.



Best Practice 16: Choose the right formalization level

How to test:

This is almost always a matter of subjective judgement with no objective test. As a general guideline:

  • Are common vocabularies used such as Dublin Core and schema.org?
  • Are simple facts stated simply and retrieved easily?
  • For formal knowledge representation languages, applying an inference engine on top of the data that uses a given vocabulary does not produce too many statements that are unnecessary for target applications.


Best Practice 17: Provide bulk download

How to test:

Check if the full dataset can be retrieved with a single request.



Best Practice 18: Provide Subsets for Large Datasets

How to test:

Check that the entire dataset can be recovered by making multiple requests that retrieve smaller units.



Best Practice 19: Use content negotiation for serving data available in multiple formats

How to test:

Check the available representations of the resource and try to get them specifying the accepted content on the HTTP Request header.



Best Practice 20: Provide real-time access

How to test:

To adequately test real time data access, data will need to be tracked from the time it is initially collected to the time it is published and accessed. [[PROV-O]] can be used to describe these activities. Caution should be used when analyzing real-time access for systems that consist of multiple computer systems. For example, tests that rely on wall clock time stamps may reflect inconsistencies between the individual computer systems as opposed to data publication time latency.



Best Practice 21: Provide data up to date

How to test:

Check that the update frequency is stated and that the most recently published copy on the Web is no older than the date predicted by the stated update frequency.



Best Practice 22: Provide an explanation for data that is not available

How to test:

Where the dataset includes references to data that is no longer available or is not available to all users, check that an explanation of what is missing and instructions for obtaining access (if possible) are given. Check if a legitimate http response code in the 400 or 500 range is returned when trying to get unavailable data.



Best Practice 23: Make data available through an API

How to test:

Check if a test client can simulate calls and the API returns the expected responses.



Best Practice 24: Use Web Standards as the foundation of APIs

How to test:

Check that the service avoids using http as a tunnel for calls to custom methods, and check that URIs do not contain method names.



Best Practice 25: Provide complete documentation for your API

How to test:

Check that every call enabled by your API is described in your documentation. Make sure you provide details of what parameters are required or optional and what each call returns.

Check the Time To First Successful Call (i.e. being capable of doing a successful request to the API within a few minutes will increase the chances that the developer will stick to your API).



Best Practice 26: Avoid Breaking Changes to Your API

How to test:

Release changes initially to a test version of your API before applying them to the production version. Invite developers to test their applications on the test version and provide feedback.



Best Practice 27: Preserve identifiers

How to test:

Check that dereferencing the URI of a dataset that is no longer available returns information about its current status and availability, using either a 410 or 303 Response Code as appropriate.



Best Practice 28: Assess dataset coverage

How to test:

It is impossible to determine what will be available in, say, 50 years' time. However, one can check that an archived dataset depends only on widely used external resources and vocabularies. Check that unique or lesser-used dependencies are preserved as part of the archive.



Best Practice 29: Gather feedback from data consumers

How to test:

Check that at least one feedback mechanism is provided and readily discoverable by data consumers.



Best Practice 30: Make feedback available

How to test:

Check that any feedback given by data consumers for a specific dataset or distribution is publicly available.



Best Practice 31: Enrich data by generating new data

How to test:

Verify that there are no missing values in the dataset, or additional fields likely to be needed by others, that could readily be provided. Check that any data added by inferential enrichment techniques is identified as such and that any replaced data is still available.



Best Practice 32: Provide Complementary Presentations

How to test:

Check that the dataset is accompanied by some additional interpretive content that can be perceived without downloading the data or invoking an API.



Best Practice 33: Provide Feedback to the Original Publisher

How to test:

Check that you have a record of at least one communication informing the publisher of your use of the data.



Best Practice 34: Follow Licensing Terms

How to test:

Read through the original license and check that your use of the data does not violate any of the terms.



Best Practice 35: Cite the Original Publication

How to test:

Check that the original source of any reused data is cited in the metadata provided. Check that a human-readable citation is readily visible in any user interface.