Re: Comments on BP document

Thanks!

Best,

Andrea

On 28/06/2016 0:19, Caroline Burle wrote:
> 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
> [2]
> https://github.com/w3c/dwbp/pull/408/commits/f18044394f04e8495b427667bff9122f1ee194fb
> [3]
> https://github.com/w3c/dwbp/pull/408/commits/2a8089e45d9aece41c68b0f947c270f78d9cb726
> [4]
> https://github.com/w3c/dwbp/commit/64d71cb6bd4a3761cf61e3eb8670b834be6d3119
>
> 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
>> ----------------------------------------------------------------------------
>

-- 
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Institute for Environment & Sustainability
Unit H06 - Digital Earth & Reference Data
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy

https://ec.europa.eu/jrc/

Received on Tuesday, 28 June 2016 16:41:14 UTC