Add more properties on DataService

[matthiaspalmer]

Data services may need to be viewed independently from datasets in a Catalog. This is stated clearly e.g. in chapter 14: "Whereas a data service is an entity in its own right. It provides access to datasets or it provides data processing functions."

In this scenario we think additional properties would make sense. We suggest to at least consider the following properties that are present in the Swedish profile DCAT-AP-SE2:

• Publisher (dcterms:publisher)
• Contactpoint (dcat:contactPoint)
• Keyword (dcat:keyword)
• Theme (dcat:theme)
• Conforms to (dcterms:conformsTo)
• Landing page (dcat:landingPage)
• Documentation (foaf:page)

For examples of data service that may be needed to be viewed independently from datasets we suggest to consider at least the following cases:

1. Data service serving no datasets, e.g. data processing services
2. Data services serving many datasets

[fabiankirstein]

I would like to second this request. Although in DCAT it is already supported to use all properties from dcat:Resource, explicitly listing certain properties in DCAT-AP will increase the reusability and help implementers.

For instance, independent data service could be displayed in faceted/filtered search view. Many Open Data portals offer filtering for publishers, keywords, etc.

I would see the following properties as essential:

• Publisher (dcterms:publisher)
• Keyword (dcat:keyword)
• Theme (dcat:theme)

However, a discussion about the exact selection should continue.

@matthiaspalmer Wouldn't you say dcat:endpointDescription is already a kind of Documentation (foaf:page)?

[matthiaspalmer]

@fabiankirstein, I think dcat:endpointDescription is closer to dcterms:conformsTo, i.e. have a more formal character than a pointer to a more general documentation resource intended for humans, i.e. via foaf:page. This is supported by the usage note in dcat3.

For a dataset you have dcterms:conformsTo on both the dataset and the distribution level, giving you the option to be more specific on the expression for each distribution. For a dataservice you may need to indicate the workings of the API via openapi / swagger / RAML etc. you do this with the dcat:endpointDescription and use dcterms:conformsTo to point to the wider specification being implemented. This still leaves the need for documentation targeting humans, hence the need for foaf:page.