W3C home > Mailing lists > Public > public-dwbp-comments@w3.org > June 2016

Re: Comments on BP document

From: Caroline Burle <cburle@nic.br>
Date: Mon, 27 Jun 2016 19:19:19 -0300
To: Bernadette Farias Lóscio <bfl@cin.ufpe.br>, Andrea Perego <andrea.perego@jrc.ec.europa.eu>
Cc: W3C DWBP WG - Comments <public-dwbp-comments@w3.org>
Message-ID: <5771A667.3060609@nic.br>
Dear Andrea,

thank you indeed for your comments. We addressed it on the BP Document 
[1] as you may see the Commit at Github [2] [3] [4].

Kind regards,
BP Editors

[1] http://w3c.github.io/dwbp/bp.html

On 31/05/16 08:14, Bernadette Farias Lóscio wrote:
> Hi Andrea,
> Thanks a lot for your valuable comments and suggestions!
> We're gonna discuss your comments with the group and we will let you 
> know how we're gonna handle them.
> Cheers,
> Bernadette
> 2016-05-31 6:18 GMT-03:00 Andrea Perego 
> <andrea.perego@jrc.ec.europa.eu <mailto:andrea.perego@jrc.ec.europa.eu>>:
>     Dear DWBP WG,
>     Congratulations for the great work done!
>     I would like to contribute a couple of comments on the BP
>     document, concerning data versioning and access. I don't know if
>     they can be addressed at this stage, but I thought they may be
>     worth to be mentioned - at least to know the position of the WG.
>     Thanks!
>     Andrea
>     ----
>     1. Data versioning
>     The issue is about a specific metadata field, namely the date of
>     last modification of a dataset (dct:modified in DCAT).
>     This field conveys useful information for end users - e.g., they
>     can check whether the data are actually recent enough for their
>     purposes - and it is sometimes considered more important than the
>     dataset issue date.
>     Going through the BP doc, I realised dct:modified occurs just in
>     one of the examples (#4), and it is not included in BP2 in the
>     list of recommended fields for datasets and distributions. There's
>     actually another field (dct:accrualPeriodicity) that is referred
>     to from the data versioning section, as a way to inform end users
>     about the data update frequency. Nonetheless, the two fields are
>     not mutually exclusive, and dct:accrualPeriodicity cannot replace
>     dct:modified when the update frequency is "irregular" or "unknown".
>     May I ask which is the position of the WG on this issue?
>     2. Data access
>     There's a scenario that I'm not sure it is addressed, at least
>     explicitly. This concerns data that, to be accessed, require users
>     to register. This is different from data that can be accessed only
>     by authorised users. It's basically just about preventing data
>     from being anonymously accessed, because, for some data providers,
>     it is important to know who downloads / uses the data.
>     This is quite common for research data, but there are also quite a
>     few examples from the public sector.
>     A first issue here is that, usually, this compulsory registration
>     does not result in clear benefits from the end users' side, who
>     may be reasonably concerned to provide personal information -
>     that, in many cases, is not limited to your email address, but
>     you're also asked to say which is you real name, the organisation
>     you're working for, etc.
>     To address this, a recommendation to data providers could be: if
>     you require users to register / authenticate to get to the data,
>     you should explain (a) why, (b) how their personal information
>     will be used, and (c) which are the benefits (if any) they can get
>     (e.g., they will be allowed to submit feedback, they will be
>     updated about data they're interesting in).
>     I think this could be addressed by extending BP22 accordingly
>     ("Provide an explanation for data that is not available").
>     Another issue is that, although these data are open to everyone,
>     the need to authenticate creates a barrier to machine-based data
>     access. This can be addressed by supporting Web-based
>     authentication / authorisation protocols, but this is usually not
>     the case.
>     Of course, this applies as well to data subject to access control.
>     Maybe, BP23 ("Make data available through an API") could be
>     extended  to mention that, whenever direct data access is
>     prevented, data providers should support standard authentication /
>     authorisation APIs.
>     ----
> -- 
> Bernadette Farias Lóscio
> Centro de Informática
> Universidade Federal de Pernambuco - UFPE, Brazil
> ----------------------------------------------------------------------------
Received on Monday, 27 June 2016 22:19:55 UTC

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