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

Comment Shortname:

Commenter: Christophe Guéret <christophe.gueret@dans.knaw.nl>

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:

# Data vocabularies
Issue 9 : we should stick to using "vocabularies"
Issue 10 : we should aim at being generic
BP 19: there is a problem in advocating for simplicity as this can prevent from having rich vocabularies. It could instead be suggest that publishers may provide vocabularies as rich as needed but strive at basing them on "simpler" ones (e.g. core ontologies / upper ontologies / ... ) to ensure there is always a minimum level of understanding. See, e.g. http://arxiv.org/abs/1304.5743 for a discussion about this.

Related issues: http://www.w3.org/2013/dwbp/track/issues/166
(space separated ids)

WG Notes: There is an ongoing discussion about the Data Vocabularies section. I propose to postpone this discussion for the next draft of the DWBP document.

Resolution: The group discussed this topic and we got a consensus about the terms.

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