W3C home > Mailing lists > Public > public-dwbp-comments@w3.org > January 2017

DWBP comments

From: Phil Archer <phila@w3.org>
Date: Mon, 16 Jan 2017 15:15:55 +0000
To: Laurent Lefort <laurent.lefort@abs.gov.au>, "public-dwbp-comments@w3.org" <public-dwbp-comments@w3.org>
Message-ID: <cb4d49a3-eed5-5aa7-1615-fc7c4c219532@w3.org>
Hi Laurent,

Thanks very much for your review of the BP doc as part of the AC review. 
That detail of the review process is member confidential but I hope 
you'll allow me to air your issues in public here.

On the EU Data Portal
We have been in touch with the relevant folks throughout. See, for 
https://www.europeandataportal.eu/en/content/best-practices-data-web in 
which they encourage review of the document. This is actually tied in to 
the Share-PSI project that I ran on the related policy issues 

Temporal aspects

True: DWBP does not go into a lot of detail on this. As it says in the 

"The Best Practices set out in this document serve a general purpose of 
publishing and using Data on the Web and are domain & application 
independent. They can be extended or complemented by other Best 
Practices documents or standards that cover more specialized contexts."

*However*, as you know, spatial and temporal aspects are being 
addressed, at least in part, by the Spatial Data WG. See, for example, 
https://www.w3.org/TR/sdw-bp/#provide-context. Rob Atkinson's work on 
QB4ST (https://www.w3.org/TR/qb4st/) is obviously relevant to helping 
define spatial-temporal slices through statistical data cubes.

I offer the Data Quality Vocabulary as a partial answer in that it 
provides a framework in which the appropriateness of a dataset for a 
particular use can be described (by the publisher or a user). The 
Dataset Usage Vocab is also relevant in this regard. 
https://www.w3.org/TR/vocab-dqv/ https://www.w3.org/TR/vocab-duv/

Things like preparing and publishing a Privacy Impact Assessment, like 
the Share-PSI work, is out of scope for W3C in that it is a 
policy-related issue where W3C is concerned only with technical issues. 
Again, quoting from the document's intro:

"Not all data and metadata should be shared openly, however. Security, 
commercial sensitivity and, above all, individuals' privacy need to be 
taken into account. It is for data publishers to determine policy on 
which data should be shared and under what circumstances. Data sharing 
policies are likely to assess the exposure risk and determine the 
appropriate security measures to be taken to protect sensitive data, 
such as secure authentication and authorization."

API Keys
It's true, there is no mention of API Keys, however, the doc does point 
to a number of frameworks and sources of info that do support them.

Vocabulary choices

On vocabulary choices, the BP doc points to earlier work on this 
https://www.w3.org/TR/ld-bp/#VOCABULARIES in which a number of points 
are made. What the paper you point to refers to as Frankenstein 
ontologies would be avoided by following that advice, specifically:

"Vocabularies should be used by other datasets
If the vocabulary is used by other authoritative Linked Open datasets 
that is helpful. It is in re-use of vocabularies that we achieve the 
benefits of Linked Open Data. Selected vocabularies from third parties 
should be already in use by other datasets, as this shows that they are 
already established in the LOD community, and thus better candidates for 
wider adoption and reuse.

For example: An analysis on the use of vocabularies on the Linked Data 
cloud reveals that FOAF is reused by more than 55 other vocabularies."

Even though I am able to point to at least partial answers to your 
comments, it's clear that you are absolutely correct that there is much 
more that can be said on these topics. I will ask the editors to 
consider adding a short statement to the effect that further advice 
should be sought in specific areas as you suggest.

Thanks again



Phil Archer
Data Strategist, W3C

+44 (0)7887 767755
Received on Monday, 16 January 2017 15:16:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:38:14 UTC