Edit comment LC-3060 for Data on the Web Best Practices Working Group

Quick access to LC-3057 LC-3058 LC-3059 LC-3060 LC-3061 LC-3062 LC-3063

Comment LC-3060

Comment Shortname:

Commenter: Erik Wilde <dret@berkeley.edu>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeAbstract 1. Introduction 3. Audience 4. Scope 5. Context 6. Data on the Web Challenges Fig. 1 Diagram showing how best practices address each of t... 7. Best Practices Template Best Practice Template Issue 1 8. Best Practices Summary 9. The Best Practices 9.1 Example 9.2 Metadata Best Practice 1: Provide metadata Best Practice 2: Provide descriptive metadata Machine-readable Human-readable Best Practice 3: Provide locale parameters metadata Issue 2 Best Practice 4: Provide structural metadata 9.3 Data Licenses Best Practice 5: Provide data license information 9.4 Data Provenance Best Practice 6: Provide data provenance information 9.5 Data Quality Best Practice 7: Provide data quality information 9.6 Data Versioning Issue 3 Issue 4 Issue 5 Fig. 2 Diagram showing the relationships between Dataset, V... Best Practice 8: Provide versioning information Best Practice 9: Provide version history Issue 6 9.7 Data Identification Issue 7 Best Practice 10: Use persistent URIs as identifiers Best Practice 11: Assign URIs to dataset versions and series 9.8 Data Formats Best Practice 12: Use machine-readable standardized data for... Issue 8 Best Practice 13: Use non-proprietary data formats Best Practice 14: Provide data in multiple formats 9.9 Data Vocabularies Issue 9 Issue 10 Issue 11 Best Practice 15: Use standardized terms Best Practice 16: Document vocabularies Best Practice 17: Share vocabularies in an open way Best Practice 18: Vocabulary versioning Best Practice 19: Re-use vocabularies Best Practice 20: Choose the right formalization level Issue 12 9.10 Sensitive Data Best Practice 21: Preserve people's right to privacy Data m... Best Practice 22: Provide data unavailability reference Issue 13 9.11 Data Access Best Practice 23: Provide bulk download Best Practice 24: Follow REST principles when designing APIs Best Practice 25: Provide real-time access Best Practice 26: Provide data up to date Issue 14 Best Practice 27: Maintain separate versions for a data API 9.12 Data Preservation Best Practice 28: Assess dataset coverage Best Practice 29: Use a trusted serialization format for pre... Best Practice 30: Update the status of identifiers 9.13 Feedback Best Practice 31: Gather feedback from data consumers Best Practice 32: Provide information about feedback 9.14 Data Enrichment Issue 15 Issue 16 Best Practice 33: Enrich data by generating new metadata.
or

Refinement of the section concerned:

Status:

open proposal pending resolved_yes resolved_no resolved_partial other assigned to Nobody

Type: substantive editorial typo question general comment undefined

Comment:

best practices 24 and 27 kind of conflict. one important idea of REST
is to avoid versioning, and having versioned URIs is a pretty certain
sign of bad design smell when it comes to media types and API design.

Related issues: (space separated ids)

WG Notes: Email from Annette - Addressed: We now have a BP “Avoid breaking changes to your API”

Proposed Resolution: Addressed: We now have a BP “Avoid breaking changes to your API”

(Please make sure the resolution is adapted for public consumption)