Edit comment LC-3059 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-3059

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:

generally speaking, i am wondering why the terms hypertext or
hypermedia are not even mentioned in the spec. isn't that what data on
the web ideally should be, linkable and linked?
https://github.com/dret/webdata#one-star-linkable and
https://github.com/dret/webdata#four-star-linked are core principles for
good web data. *linkable* means more than just URIs. it also means, for
example, to provide meaningful and robust fragment identifiers for
others to link to. *linked* means to use URIs and to specifically avoid
other kinds of (often non-globally scoped) identifiers, so that links
don't break when taken out of context.

Related issues: (space separated ids)

WG Notes: We had long discussions by email about this subject: https://lists.w3.org/Archives/Public/public-dwbp-comments/2015Jul/0002.html and https://lists.w3.org/Archives/Public/public-dwbp-comments/2015Oct/0000.html. Annette's email: Partially addressed. We don’t talk about fragment identifiers. I suggest we add it. This relates to LC-3058 and LC-3051.

Resolution:

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