- From: Trani, Luca (KNMI) <luca.trani@knmi.nl>
- Date: Mon, 10 Dec 2018 14:27:43 +0000
- To: "'andrea.perego@ec.europa.eu'" <andrea.perego@ec.europa.eu>
- CC: "public-dxwg-comments@w3.org" <public-dxwg-comments@w3.org>
- Message-ID: <6cec622343224ebc947539045e4e44cd@knmi.nl>
Dear Andrea,
Thank you for considering my comments.
Some answers below.
I am available to provide you more information when needed. Also, we are working on the documentation that will help clarify our applications. A document should be available soon that will contain descriptions of classes, relationships, examples etc.
Kind regards,
Luca
Luca Trani
Senior Advisor IT - Researcher
........................................................................
KNMI
Ministry of Infrastructure and Water Management
Utrechtseweg 297 | 3731 GA | De Bilt | the Netherlands
PO Box 201 | 3730 AE | De Bilt | the Netherlands
........................................................................
T +31 (0)30 2206 297
trani@knmi.nl<mailto:trani@knmi.nl>
www.knmi.nl<http://www.knmi.nl/>
........................................................................
Van: andrea.perego@ec.europa.eu [mailto:andrea.perego@ec.europa.eu]
Verzonden: maandag 19 november 2018 15:54
Aan: Trani, Luca (KNMI)
CC: public-dxwg-comments@w3.org
Onderwerp: RE: W3C Data Exchange Working Group: Invitation to review draft revision of DCAT
Dear Luca,
Many thanks for your comments, and for the appreciation of the work done by the DXWG.
On behalf of the WG, I would like to inform you that we had a preliminary discussion during the 7 Nov DCAT subgroup meeting [1], and I include below some preliminary feedback wrt your questions.
At the same time, we would very much appreciate if you could contribute some more details on how you extended DCAT in EPOS-DCAT-AP, especially wrt the requirements you had, and the rationale behind the solutions you adopted. This would help us understand if any update is needed of the existing use cases [2], based on which the current revision of DCAT is carried out.
Looking forward to you feedback,
Best,
Andrea
----
> […] the introduction of additional resources (beyond Dataset) as first-class citizens in a Catalogue
> was definitely required and we accommodated that by extending DCAT 2014. […] Also, two
> specialisations of a dcat:Resource are provided: Dataset and DataService. I assume that more
> might be added to extend the scope of a Catalogue when needed. Am I correct?
dcat:Resource is intended to enable this. However, one of the concerns of the WG is that this option may be abused (which may lead to the use of DCAT beyond its real scope) – see, e.g., the discussion in https://github.com/w3c/dxwg/issues/172
So, to give you a more precise answer, we wonder whether you can outline which are the types of resources in EPOS-DCAT-AP that you include (or plan to) in a dcat:Catalog.
Examples of resources included in EPOS-DCAT-AP are: Equipment, Facility, Publication, Project, Service and WebService.
However, this set might not be exhaustive and evolve in the future. Having a generic parent Class relaxed from axioms such a Resource allows to extend the scope of a Catalogue, if necessary, without having to introduce additional specific relationships.
> Do you support composition of resources? Would that be covered by dct:relation?
Could you please elaborate? The exact scenario you refer to ("composition of resources") is not completely clear to us.
We cover a broad spectrum of cases.
E.g. a Dataset composed of other Datasets (e.g. a collection), or similarly or an Equipment that includes other Equipments, or a Facility that contains Equipments or …
> Also, I would be interested in the approach you are considering to tackle Issue 66 and Issue 71.
About project / funding sources, the discussion is still ongoing, also to clearly identify what is in the actual scope of DCAT, and what should be rather addressed by other vocabularies.
Did you have to address this issue in EPOS-DCAT-AP?
In general yes but we need to further detail those aspects. At the moment we chose to include foaf:Project which is very generic and to create relationships in the epos namespace (e.g. epos:associatedProjects from Organization). If there was an established ontology we would consider to test it.
> I agree that the description of a service, via dcat:endpointDescription, should be as much as possible
> relying on dedicated description standards (e.g. WADL, OpenAPI/Swagger, OpenSearch). However, in
> some cases where such descriptions are not available a templating approach might be useful. In our
> case, while promoting the first approach, we also provided an alternative by embedding the W3C
> Hydra Vocabulary. For instance, Templated Links can be used. Hydra offers quite extensive
> descriptions although its status (Unofficial Draft) makes its adoption and future support unclear.
We would be interested to know more details on how you are doing this in EPOS-DCAT-AP, as so far the examples we had were mainly related to services / APIs described with standard specifications, and usually not using RDF. This would help us verify whether the current approach fits also these scenarios.
Below an example of a real service described in both Swagger and RDF/Hydra.
<GlassFramework/APIDocumentation> a hydra:APIDocumentation;
hydra:title "Documentation for GlassFramework webresources" ;
hydra:description "some description of API Documentation" ;
hydra:entrypoint "https://glass.epos.ubi.pt:8080/GlassFramework/swagger.json"^^xsd:anyURI ;
.
#WS products/attributes
<GlassFramework/webresources/products/attributes/> a epos:WebService;
schema:identifier "GlassFramework/webresources/products/attributes";
schema:description "Returns the GNSS product attributes that can be used in other product requests";
schema:name "Gets attributes for application in other requests";
dcat:contactPoint <http://orcid.org/0000-0002-9733-284X/contactPoint> ;
schema:datePublished "2016-06-30T12:00:00Z"^^xsd:dateTime;
schema:dateModified "2016-12-31T12:00:00Z"^^xsd:dateTime;
schema:provider <PIC:996437254>;
dcat:theme <epos:GNSSProductsPortal> ;
hydra:entrypoint "https://glass.epos.ubi.pt:8080/GlassFramework/swagger.json"^^xsd:anyURI;
schema:keywords "Geodesy", "GNSS" ;
dct:conformsTo <GlassFramework/APIDocumentation> ;
hydra:supportedOperation <GlassFramework/webresources/products/attributes/operation>;
.
#WS Operation products/attributes
<GlassFramework/webresources/products/attributes/operation> a hydra:Operation;
hydra:method "GET"^^xsd:string;
hydra:returns "application/json";
hydra:property[ a hydra:IriTemplate;
hydra:template "https://glass.epos.ubi.pt:8080/GlassFramework/webresources/products/attributes/{attribute}"^^xsd:string;
hydra:mapping[ a hydra:IriTemplateMapping;
hydra:variable "attribute"^^xsd:string;
rdfs:range "xsd:string";
rdfs:label "attribute - string with attribute ";
hydra:required "true"^^xsd:boolean;
http:paramValue "network";
http:paramValue "analysis_center";
http:paramValue "reference_frame";
http:paramValue "otl_model";
http:paramValue "calibration_model";
http:paramValue "sampling_period";
http:paramValue "format";
schema:defaultValue "network";
];
];
.
Although in most cases this might seem an overkill, Hydra could provide a useful mechanism to describe APIs when other descriptions are missing. Moreover, the RDF description should offer more flexibility at query time.
> About Organization and Person. I think it might be useful to make them explicit in the model in order
> to facilitate relationships between them and with their associated resources. For instance, a Person
> belonging to an Organization, her roles etc.
Also here, the problem is understanding which is or not in scope with DCAT. E.g., the role of an individual / organisation wrt to a catalogue, dataset, etc. is indeed in scope of DCAT, whereas the affiliation of individuals and their role(s) in an organisation might be better addressed with other vocabularies (as the W3C Organization Ontology [3]).
> Did you consider adding additional roles beyond publisher,
> creator and contributor? Why the latter applies only to CatalogRecord?
This issue has been actually discussed, and the roles included in the 2PWD correspond to the ones identified by the WG based on the DXWG use cases and requirements. Again, we would be interested to know which are the roles you identified in EPOS-DCAT-AP.
As far as dct:contributor is concerned, this role is mentioned only in Section 5.8 ("Dataset provenance") [4], but currently it is not explicitly associated with any class.
----
[1] https://www.w3.org/2018/11/07-dxwgdcat-minutes#x04
[2] https://www.w3.org/TR/dcat-ucr/
[3] https://www.w3.org/TR/vocab-org/
[4] https://www.w3.org/TR/vocab-dcat-2/#examples-dataset-provenance
----
Andrea Perego, Ph.D.
Scientific / Technical Project Officer
European Commission DG JRC
Directorate B - Growth and Innovation
Unit B6 - Digital Economy
Via E. Fermi, 2749 - TP 262
21027 Ispra VA, Italy
https://ec.europa.eu/jrc/
----
The views expressed are purely those of the writer and may
not in any circumstances be regarded as stating an official
position of the European Commission.
From: Trani, Luca (KNMI) [mailto:luca.trani@knmi.nl]
Sent: Monday, October 29, 2018 1:25 PM
To: public-dxwg-comments@w3.org
Subject: RE: W3C Data Exchange Working Group: Invitation to review draft revision of DCAT
Dear DXWG,
I would like to thank you for your considerable effort in the revision of DCAT. As designer and main author of EPOS-DCAT-AP (https://github.com/epos-eu/EPOS-DCAT-AP) I appreciate very much the new features you introduced. To respond to the requirements of our communities we had to accommodate functionalities in our profile that are now supported natively. In particular, the introduction of additional resources (beyond Dataset) as first-class citizens in a Catalogue was definitely required and we accommodated that by extending DCAT 2014. My view is that in the context of RIs catalogues have an essential role to represent a variety of assets -- having the focus only on Dataset would be too restrictive. Therefore, I am pleased to see that there is a dcat:Resource in this new version. Also, two specialisations of a dcat:Resource are provided: Dataset and DataService. I assume that more might be added to extend the scope of a Catalogue when needed. Am I correct? Do you support composition of resources? Would that be covered by dct:relation?
Also, I would be interested in the approach you are considering to tackle Issue 66 and Issue 71.
Another important feature for us is the support for Data Services. I like your solution and I would like to understand a bit more about how to deal with a service that is providing multiple datasets e.g. by different methods/operations. I agree that the description of a service, via dcat:endpointDescription, should be as much as possible relying on dedicated description standards (e.g. WADL, OpenAPI/Swagger, OpenSearch). However, in some cases where such descriptions are not available a templating approach might be useful. In our case, while promoting the first approach, we also provided an alternative by embedding the W3C Hydra Vocabulary. For instance, Templated Links can be used. Hydra offers quite extensive descriptions although its status (Unofficial Draft) makes its adoption and future support unclear.
About Organization and Person. I think it might be useful to make them explicit in the model in order to facilitate relationships between them and with their associated resources.
For instance, a Person belonging to an Organization, her roles etc. Did you consider adding additional roles beyond publisher, creator and contributor? Why the latter applies only to CatalogRecord?
Finally, I think the alignments with other standards are very important, e.g. Schema.org and PROV. We found it very useful to import elements of Schema.org directly in our profile. We also discussed the introduction of PROV and therefore I appreciate that some elements are now available: e.g. prov:wasGeneratedBy.
In conclusion I would like to thank you all again for this new revision and its substantial improvements. They will facilitate uptake and usability of the model in broader contexts.
I look forward to seeing a finalised version.
Kind regards,
Luca Trani
Luca Trani
Senior Advisor IT - Researcher
........................................................................
KNMI
Ministry of Infrastructure and Water Management
Utrechtseweg 297 | 3731 GA | De Bilt | the Netherlands
PO Box 201 | 3730 AE | De Bilt | the Netherlands
........................................................................
T +31 (0)30 2206 297
trani@knmi.nl<mailto:trani@knmi.nl>
www.knmi.nl<http://www.knmi.nl/>
........................................................................
Van: Alejandra Gonzalez-Beltran [mailto:alejandra.gonzalez.beltran@gmail.com]
Verzonden: dinsdag 23 oktober 2018 09:55
Aan: public-dxwg-comments@w3.org<mailto:public-dxwg-comments@w3.org>
Onderwerp: W3C Data Exchange Working Group: Invitation to review draft revision of DCAT
Dear All,
This mail is to update you on the work of the W3C Data Exchange Working Group [1] and to ask for your help in reviewing progress on the revision of the RDF vocabulary for data catalogues, DCAT, that was published on 16 October 2018. The draft of the revision is available at https://www.w3.org/TR/vocab-dcat-2/.
The revision of DCAT is part of a group of 3 deliverables described in the Charter [2], but it is able to stand up by itself as an update to the recommended way in which data catalogues should be published on the web.
The main ways in which this first draft revision differs from the current recommendation include:
* the scope of DCAT is extended to include data services and data distribution services, as well as datasets, as members of a catalog
* some initial recommendations concerning the use of elements from the W3C PROV-O vocabulary for Dataset provenance
* recommendations for catalogs with lower expressivity, concerning the relations between Datasets and associated resources
* recommendations concerning the description of dataset quality, primarily using DQV (from the Data on the Web Working Group)
* some minor adjustments to support citation of all catalogued resources
* more relaxed axiomatisation that gives greater flexibility to the domain and range Classes of several predicates
In addition, among other things, we are working on:
* ways of dealing with related datasets (including sub-datasets)
* further recommendations regarding use of PROV-O elements and patterns in DCAT descriptions
* patterns for dataset versioning
In reviewing the draft it might be helpful for you to keep in mind the “Use Cases and Requirements” document that we are working to [3].
We would find it helpful to get feedback on the following lines:
1. Do you agree with the direction of travel of this revision of DCAT?
2. Are there any areas where we could improve what we have done? [please illustrate]
3. Are there any areas where you think the proposal is wrong or could lead us into developing proposals that are erroneous? [please give examples and reasons]
4. Are there other use cases for data catalogues and datasets descriptions that we have not considered [please illustrate]
Please also feel free to make any other comments and suggestions regarding the draft. Note that positive comments or general assent to changes are very welcome, as these provide evidence of community acceptance.
Please, send comments through GitHub issues (https://github.com/w3c/dxwg/issues) or through email at public-dxwg-comments@w3.org<mailto:public-dxwg-comments@w3.org>.
Best wishes
Alejandra (on behalf of the W3C DXWG)
[1] https://www.w3.org/2017/dxwg/wiki/Main_Page
[2] https://www.w3.org/2017/dxwg/charter
[3] https://www.w3.org/TR/dcat-ucr/
Received on Monday, 10 December 2018 14:57:34 UTC