SV: Feedback to First Public Working Draft of the Dataset Exchange Use Cases and Requirements

Hi Ixchel/all

The following is an input to the working group on some of the usecases described in the "Dataset Exchange Use Cases and Requirements" document. Hope you find this useful.

Kind regards,

Øystein Åsnes
Senior Advisor
Mob. +47 99158285
Agency for Public Management and eGovernment (Difi) www.difi.no<http://www.difi.no>
Norway


5.6 DCAT Distribution to describe web services [ID6]
Comments:
This is of great importance, since more and more data is distributed through APIs. Today there is no way to predict what's behind an dcat:accessURL unless the dcat:distribution dct:description is used wisely.

The mentioned rdf/owl approach makes sense, but the ontology itself seems to be mainly aimed at webservices within the geospacial domain. A common core vocabulary for describing (classifying) webservices might be useful. A dedicated link for machine readable service decriptions (e.g. WSDL) might add value to users and prevent overloading the dct:conformsTo property. This use case is closely related to ID18. See our comments there.

Some user stories supporting the needs:
As a catalog user, I wish to be able to see directly (on a data portal) what kind of distribution (file, webservice, feed, landingpage) the dcat:accessURL points to, so that I don't have to click on each dcat:accessURl to find out.

As a catalog user, I wish to be able to see directly (on a data portal) what kind of webservice (e.g. SOAP, REST) the dcat:accessURL points to, so that I don't have to click on each dcat:accessURl to find out.

As a data catalog user, I wish to be able to see directly in a data portal the status of the webservice (e.g. under development, deprecated), so that I'm not discovering this after I have started using it.


5.7 Support associating fine-grained semantics for datasets and resources within a dataset [ID7]
Comments:
To be able to point from a dataset description to the URIs for the main concepts of the dataset, we have added a property "Concepts" to  dcat:dataset in DCAT-AP-NO: URI=dct:subject, Range=skos:Concept, Cardinality=0..n, Description= References (URIs) to main concepts that are of importance to be able to understand and interpret the dataset.  There is currently a national standard for machine-readable publication/exchange of concept descriptions/definitions under development in Norway. SKOS will be used.

For finegrained semantics of all constituents in a dataset, we find the Project Open Metadata Schema properties describedBy and describedByType of interest. These can be applied both for the dcat:dataset and the dcat:distribution class.


5.17 Data access restrictions [ID17]
Comments:
Legal restrictions for access applies regardless of distributions of the data and should be associated with the dcat:Dataset class. Use DCAT-APs dct:AccessRights property and the MDR access Right vocabulary to classify access restrictions.  Why they are closed can be described by referring to the actual law that represents the legal grounds for classifying the data as restricted or non-public. European Legislation Identifier (ELI) is of relevance here. Neither DCAT or DCAT-AP offers a property for this purpose. An additional text property for commenting the applied access level might be useful. The rights property from POD v1.1 looks suitable.

Non-legal obstacles and access restrictions should probably be solved in the dcat:Distribution class. Examples here are mandatory use of API-keys, logins, load limits and payment

Some user stories supporting the needs:
As a data catalog user, I wish to be able to see if a distribution requires login/user registration/API- keys or not, so that I don't have to click on each dcat:accessURL to find out.

As a data catalog user, I wish to be able to see directly in a data portal if a distribution requires payment or not, so that I'm able to identify potential costs as early as possible


5.18 Modeling service-based data access [ID18]
Comments:
A controlled vocabulary (with dct:type on dcat:Distribution) is used by the Norwegian open data portal data.norge.no. The basic need was to be able to say what is behind the dcat:accessURL. The MDRs distribution type vocabulary is used, but further granularity may be needed for webservices.  Landing pages (that somehow provides access to data) might be treated as distributions by adding this as a distribution type in the MDRs distribution type vocabulary.

It is unclear what the difference between a distribution of dct:type DOWNLOADABLE_FILE and and dcat:downloadURL might be, besides that dcat:downloadURL always will be a direct link to a file.


5.32 Relationships between Datasets [ID32]
Comments:
This is one of DCATs most important shortcomings today. Collections of datasets makes  sense and might prevent dcat:distributions from being overused and overloaded. DCAT-AP-NO has introduced a set of dct:relations (e.g.: isPartOf/hasPart) to be able to express relations between datasets. Collections are still only expressed as dcat:dataset in the catalog and not as a separate superclass. Maybe it should.


5.14 Data quality modeling patterns [ID14]
Comments:
We agree that it should be possible to model the various aspects of "data quality" and to refer to from the description of a data set and/or distribution.  We have tried to follow the quality dimensions of ISO/IEC 25012 which [VOCAB-DQV] also refers to. We have suggested some national extensions to the DCAT-AP-NO which though not yet are implemented.

Some user stories supporting the needs:
The governmental guidelines require that one should provide with information about the data quality, when making public data available.
As a User of data from others, I need to, easily, give feedback to the data owner about the experienced quality of the data set in order to help improve the data quality.
As a User of data from others, I need to know how fresh, how complete, how accurate etc.  the data set is, in order to evaluate if the data set is relevant for my usage.

5.15 Modeling data precision and accuracy [ID15]
See our similar comments with some User stories, related to ID14.

5.16 Modeling conformance test results on data quality [ID16]
See our similar comments with some User stories, related to ID14.

5.24 Harmonising INSPIRE-obligations and DCAT-distribution [ID24]
Harmonising obligations from the ITS Directive (Directive 2010/40/EU) with DCAT-AP

The ITS directive gives requirements for sharing data and metadata about transport. A list of required metadata has been made. This list is almost, but not completely, compatible with DCAT-AP. Adding one or a few metadata fields for transport specific datasets (mostly referring to type of road network described in the dataset) would be very useful for those government agencies which are obligated to deliver information according to the ITS directive.

The national road authorities in Sweden, Denmark, and Austria are currently using DCAT-AP with some modifications for providing information according to the ITS directive. This modifications are currently not identical.

Links:
- Action plan and link to the directive and related documents: https://ec.europa.eu/transport/themes/its/road/action_plan_en
- Metadata standard for transport data: https://www.its-platform.eu/highlights/announcement-%E2%80%98workshop-metadata%E2%80%99-october-23-amsterdamschiphol

---------

Fra: Faniel,Ixchel [mailto:fanielI@oclc.org]
Sendt: onsdag 7. februar 2018 17:46
Til: public-dxwg-comments@w3.org; Åsnes, Øystein <Oystein.Asnes@difi.no>
Emne: Re: Feedback to First Public Working Draft of the Dataset Exchange Use Cases and Requirements


Dear Øystein,



We are glad to hear you have special interest in several of the use cases described in the First Public Working Draft of the Dataset Exchange Use Cases and Requirements.  Regarding your agency's set of needs expressed as User Stories, our suggestion is to review the requirements drawn from the working group's use cases that are of interest and check if they meet your needs given your User Stories.



If you feel your User Stories provide additional explanation or justification for existing requirements, offer a counter example, or identify a missing requirement, please let us know the specifics.  We would be very interested to incorporate them in future drafts.



Please note several of our sub-groups have started the next phase of work and they too would be interested in receiving your contributions, so send any comments to the comments list (public-dxwg-comments@w3.org<mailto:public-dxwg-comments@w3.org>).



Thanks for your time and consideration.



Sincerely,

Ixchel (sending on behalf of the W3C Dataset Exchange Working Group)


--

Ixchel M. Faniel

OCLC · Research Scientist, OCLC Research

6565 Kilgour Place, Dublin, Ohio USA 43017

T +1-614-764-4370 · F +1-614-718-7660

[OCLC]<http://www.oclc.org/home.en.html?cmpid=emailsig_logo>

OCLC.org<http://www.oclc.org/home.en.html?cmpid=emailsig_link> · Blog<http://www.oclc.org/blog/main/?cmpid=emailsig_blog> · Facebook<http://www.facebook.com/pages/OCLC/20530435726> · Twitter<http://twitter.com/oclc> · YouTube<http://www.youtube.com/OCLCvideo>