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

Quick access to LC-3003 LC-3004 LC-3005 LC-3006 LC-3007 LC-3008 LC-3028 LC-3029 LC-3030 LC-3031 LC-3032 LC-3033 LC-3034 LC-3035 LC-3036 LC-3037 LC-3038 LC-3039 LC-3040 LC-3046 LC-3047 LC-3048 LC-3049 LC-3050 LC-3051 LC-3052 LC-3053 LC-3054 LC-3055 LC-3056

Comment LC-3052

Comment Shortname:

Commenter: Erik Wilde <dret@berkeley.edu>

Message-id:

Section of the document concerned:

[Free text description]Document as a wholeAbstract 1. Introduction Note 2. Conformance 3. Audience 4. Scope 5. Data on the Web Challenges Issue 1 6. Best Practices Template Best Practice Template Issue 2 7. Best Practices Summary 8. The Best Practices Issue 3 Issue 4 8.1 Metadata Best Practice 1: Document data Issue 5 Best Practice 2: Use machine-readable formats to provide met... Best Practice 3: Use standard terms to define metadata Issue 6 8.1.1 Data Discovery Best Practice 4: Provide discovery metadata 8.1.2 Locale Parameters Best Practice 5: Provide locale parameters metadata 8.1.3 Data Licenses Best Practice 6: Provide data license information 8.1.4 Data Provenance Best Practice 7: Provide data provenance information 8.1.5 Data Quality Best Practice 8: Provide data quality information Issue 7 8.1.6 Data Versioning Best Practice 9: Provide versioning information Best Practice 10: Provide version history 8.2 Data Identification Best Practice 11: Use unique identifiers 8.3 Data Formats Best Practice 12: Use machine-readable standardized data for... Issue 8 Best Practice 13: Use open data formats Best Practice 14: Provide data in multiple formats 8.4 Data Vocabularies Issue 9 The section needs terminolog... 8.4 Data Vocabularies Issue 9 Issue 10 Best Practice 15: Document vocabularies Best Practice 16: Share vocabularies in an open way Best Practice 17: Vocabulary versioning Best Practice 18: Re-use vocabularies Best Practice 19: Choose the right formalization level Issue 11 8.5 Sensitive Data Best Practice 20: Preserve people's right to privacy Preserve organization's security Best Practice 21: Provide data unavailability reference Issue 12 8.6 Data Access Best Practice 22: Provide bulk download Best Practice 23: Follow REST principles when designing APIs Best Practice 24: Provide real-time access Best Practice 25: Provide data up to date Best Practice 26: Maintain separate versions for a data API 8.7 Data Preservation Issue 13 8.8 Feedback Best Practice 27: Gather feedback from data consumers
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

Resolution status:

Response drafted Resolution implemented Reply sent to commenter

Response status:

No response from Commenter yet Commenter approved disposition Commenter objected to disposition
Commenter's response (URI):

Comment:

- when it comes to versioning, i am always recommending to focus on
openness and extensibility and have robust and well-defined models for
those (this almost always requires well-defined processing models for
data). this often avoids the need for versioning, which when done badly
will be a breaking change.

- when it comes to versioning, it is important to distinguish between
breaking and non-breaking versioning changes. this comes down to the
comment above: good openness and extensibility makes it easier to have
non-breaking versioning, which helps tremendously in decentralized
ecosystems.

Related issues: (space separated ids)

WG Notes: Email from Annette - Addressed: We now have a BP “Avoid breaking changes to your API”. Carol has sent an email to Erik Wilde

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

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