Remove DataDistributionService

[dr-shorthair]

This PR addresses #432 and #821

Figure 1 regenerated by @dr-shorthair
Text and RDF edits from @riccardoAlbertoni

[pwin]

need to double-check that earlier text editing b @pwin to remove DataDistributionService from the narrative was complete

[agreiner]

This PR is still referencing the type of service that we said we were not going to address.
In index.html
Line 275: " A data service might represent a data distribution service to select and download a distribution of a dataset or subset, or a data discovery service to find the description of a suitable dataset, often through a portal or catalog service."
Line 2114: " is an extension point for the description of any kind of data service. " I don't think we've agreed on any kind of future structure.
Line 2116: "The kind of service can be indicated using the dct:type"
Lin 2117: "A data discovery service supports discovery of data"
In dcat.ttl
Line 276: skos:scopeNote "The class dcat:DataService is an extension point for the description of any kind of data service. Additional subclasses may be defined in a DCAT application profile or other DCAT application for catalogs of specific kinds of services"
Line 279: skos:scopeNote "A data discovery service supports discovery of data, usually by providing access to a Catalog. In that context the data discovery service can be understood as a DataService in which least one dcat:Catalog appears as the object of its dcat:servesDataset property"

If people want to reserve the name DataService for a future parent class, I would suggest we use DataAPI for this, so that we have the option to later define a parent class without forcing people to change their RDF.

[dr-shorthair]

@agreiner - we intended for these changes to implement what was resolved in the 2019-03-13 meeting
The textual changes were merely to copy the details from the (deleted) sub-class to the parent.

You quote a number of lines where I guess you would like to see further changes. Can you provide a concrete proposal in this context?

[dr-shorthair]

@agreiner : Picking up on your last point: as I recall the discussion in the meeting, this DataService class is indeed intended to correspond to APIs, and we agreed to continue to use this class name (@andrea-perego described strong precedents from the GI community).

On the other hand, we decided that Data Applications (e.g. with web-hosted UIs) are out of scope for this iteration of DCAT. Perhaps a note should be added to make this explicit, and to point out that a class for applications might be constructed as additional sub-classes of dcat:Resource.

(In some cases there could be a relationship from a data-application to a data-service, and perhaps also to to datasets, but I think we agreed to defer modeling of the data-application class at this stage.)

[agreiner]

We just need to make it clear that a DataService in DCAT is not a general data service as initially defined in the draft. To do that, we need to remove old references to things that are not APIs, like "portals", and to proposed structure like "extension points". I've indicated where the old terminology remains.

[dr-shorthair]

Thanks @agreiner - would the following suit?

In index.html
Line 275: " A data service might represent a data distribution service to select and download a distribution of a dataset or subset, or a data discovery service to find the description of a suitable dataset." (delete final phrase)
Line 2114: " is an extension point for the description of any kind of data service end-point. " (add "end-point" to emphasize that this relates primarily to API-like resources)
Line 2116: "The kind of end-point can be indicated using the dct:type" (Change 'service' to 'end-point')
Lin 2117: "A data discovery service end-point supports discovery of data" (add "end-point".)

In dcat.ttl
Line 276: skos:scopeNote "The class dcat:DataService is an extension point for the description of any kind of data service end-point. Specific subclasses may be defined in a DCAT application profile or other DCAT application for catalogs of specific kinds of service end-points"
Line 279: skos:scopeNote "A data discovery service end-point supports discovery of data, usually by providing access to a Catalog. In that context the data discovery service end-point can be understood as a DataService in which least one dcat:Catalog appears as the object of its dcat:servesDataset property"

[agreiner]

Line 275: yes
Line 2114: no, remove mention of it as an extension point. We have no agreement regarding future structure. Also, calling it an extension point for description of an endpoint doesn't really make sense.
Line 2116: should just be removed. We are not making a recommendation about subtypes of endpoint other than an API.
Line 2117: Remove mention of a data discovery service, as that is removed from the vocabulary
Line 276: no, remove mention of it as an extension point.
Line 279: no, remove mention of a data discovery service, as that is removed from the vocabulary.

[agreiner]

I think there will be mentions throughout the text of index.html that need to be harmonized with the simpler model. Just looking at the beginning, I see
In the Introduction: "Data is often provided through a service, accessed through a form or API which supports selection of an extract, sub-set, or combination of data. DCAT allows the description of a data access service to be included in a catalog. " should be "Data is often provided through a service, accessed through an API that supports selection of extracts, sub-sets, or combinations of data. DCAT allows the description of such a service to be included in a catalog."

In the Scope: remove "dcat:DataDistributionService represents a kind of data service that provides access to distributions of one or more datasets or extracts of datasets. "

[dr-shorthair]

@agreiner
Line 2116 should stay.

dct:type is used in several of the examples [1][2]
As mentioned in the accompanying text and several times by @andrea-perego, INSPIRE provides a typology of service-types [3]. These have been used in service descriptions appearing in catalogs for several years now. It is appropriate that we provide guidance on a standard way to do this.

Furthermore, this is merely a scope note, and the recommendation is couched in non-normative terms.

[1] https://w3c.github.io/dxwg/dcat/#a-dataset-available-from-a-service
[2] https://w3c.github.io/dxwg/dcat/#data-service-examples
[3] https://inspire.ec.europa.eu/metadata-codelist/SpatialDataServiceType/

[dr-shorthair]

@agreiner wrote:

I think there will be mentions throughout the text of index.html that need to be harmonized with the simpler model.

If you can enumerate them then they can be addressed.

[agreiner]

Re 2116, in the interest of forward progress I'll say let's keep it and see if anyone cares. Type is pretty ambiguous for APIs, because it can be the "style", or language, or whether it's streaming or not, the domain, the content, etc.

[agreiner]

Re the enumeration, maybe it would be best if you submit your updated changes and then I did a PR.

[dr-shorthair]

dct:type (and dc:type before it) was always highly malleable. This means that it will depend on conventions that are understood in particular contexts.

[dr-shorthair]

The last item in today's DCAT call was agreement to merge this PR because it is important that the DataDistributionService is removed from the ED asap. Other polishing is largely editorial.