DataService and DataDistributionService

[agreiner]

We need to clarify the terms DataService and DataDistributionService and DiscoveryService. In the overview definitions, the parent-child relationships should be clear. We say that a DataDistributionService represents a service that provides access to distributions of datasets and extracts of datasets. If it is providing access to distributions alone, then it seems to me that it is not acting as an API, as we are narrowing the definition of a distribution to not include APIs. Maybe this is just a case where the intention was to allow it to apply to an API that also provides access to bulk downloads. If so, it just needs to be clearer. A also think that DiscoveryService should be a direct child of DataService, as a DiscoveryService does not provide access to distributions; it provides access to DataDistributionServices.

[agreiner]

I'll also note here that in section 6.10 the usage note still says a distribution can be an API. I think this is just an oversight.

[agbeltran]

Dropping here this link to an example implementing dcat:DataDistributionService provided by @nicholascar:

http://linked.data.gov.au/dataset/gnaf?_format=text/turtle

[dr-shorthair]

@agreiner I have attempted to clean up the description of data services etc in the context of adding some more explicit text around the scope of DCAT (datasets and data services) along with potential for external extensions through further sub-classing of dcat:Resource. I wonder if this also resolves the concerns that you raised in this issue? Please see https://rawgit.com/w3c/dxwg/dcat-issue649-simon/dcat/index.html#dcat-scope and related.

[agreiner]

Thanks, @dr-shorthair for giving that a go.
I still think it is difficult to understand the relationship between DataService and DataDistributionService as it is described there in the definitions. Maybe the problem is that we don't come out and say there that a DataDistributionService is a type of DataService, which leaves the reader initially trying to differentiate them since they sound similar. If the reader grasps that DataDistributionService is a type of DataService, then the natural assumption from that point is that a DiscoveryService is the other type of DataService. But, no, it is actually just a specialization of DataDistributionService, though it offers no additional attributes, which makes it seem kind of useless. The description below talks about data transformation services and data processing services, but none of those exists in the vocabulary, so that raises more questions. Why is a discovery service special? After all, it is essentially a DataDistributionService that serves a dataset that is a catalog.

I suspect that we are having trouble describing these things because the relationships are not quite what's needed. It seems odd to me to have an entity that is a specialization of another entity that is itself a specialization of another entity, where neither of the two lower level entities carries more information than its parent entity. The DataDistributionService has the attribute of servesDataset, but a DiscoveryService serves a dataset, too (a catalog). If we think it is useful to distinguish a discovery service from an API, we need to fill out those distinctions in the vocabulary so that they are functionally different. For my money, the real difference is not the type of dataset but the fact that an API is intended for programmatic use and a discovery service is intended for human use through a user agent. Useful general information about an API along those lines might be the type of API or the location of documentation if it is separate from the root endpoint. But I'm having a hard time thinking of general information about a discovery service that isn't covered by being a resource or a DataService already.

[kcoyle]

The definition of DataService says "represents a description of a data service in a catalog. A data service is a collection of operations, accessible through an interface (API)"

Would access through a GUI be included in the use of API here? I don't see a mention of access via browsers but that has been discussed in the past. Perhaps that is dealt with elsewhere?

[andrea-perego]

@agreiner , just to be sure, your proposal would then be to keep just dcat:DataService and drop dcat:DataDistributionService?

On a different note:

For my money, the real difference is not the type of dataset but the fact that an API is intended for programmatic use and a discovery service is intended for human use through a user agent.

There's also the use case of using a discovery service (as an OAI-PMH or CSW endpoint, or the CKAN API) for metadata harvesting and for other machine-to-machine operations.

About services vs APIs, personally, I find it difficult to tell them apart.

[dr-shorthair]

@agreiner wrote

Maybe the problem is that we don't come out and say there that a DataDistributionService is a type of DataService, which leaves the reader initially trying to differentiate them since they sound similar.

Right. Figure 1 shows that DiscoveryService is a subclass of DataDistributionService which is a subclass of DataService, but this was not clear in the accompanying text. I've attempted to remedy that now - see https://rawgit.com/w3c/dxwg/dcat-issue432-simon/dcat/index.html#dcat-scope

DiscoveryService is the other type of DataService. But, no, it is actually just a specialization of DataDistributionService, though it offers no additional attributes, which makes it seem kind of useless

There is a little more to it. There is an existential qualifier at line 302 in the RDF representation that requires a dcat:servesDataset refer to at least one dcat:Catalog. See https://github.com/w3c/dxwg/blob/gh-pages/dcat/rdf/dcat.ttl#L302 :

dcat:DiscoveryService
  rdf:type owl:Class ;
  rdfs:label "Discovery Service" ;
  rdfs:subClassOf dcat:DataDistributionService ;
  rdfs:subClassOf [
      rdf:type owl:Restriction ;
      owl:onProperty dcat:servesDataset ;
      owl:someValuesFrom dcat:Catalog ;
    ] ;
.

I've updated the Usage note to mention this.

The motivation for including DiscoveryService was becasue it is one of the key services defined by INSPIRE. Nevertheless, this classification can also be achieved using the dct:type property, and the existential qualifier mentioned above is a minor detail. So I would not fight too hard if the group preferred to drop the class from the vocabulary, and just explain that a discovery-service is a kind of data-distribution-service which serves one or more catalogs.

However, it would be a mistake to collapse the hierarchy entirely, by dropping DataService, as this provides the extensibility point for other kinds of data services, such as data-processing and transformation services. I've added a usage note to the definition of dcat:DataService pointing this out - https://rawgit.com/w3c/dxwg/dcat-issue432-simon/dcat/index.html#Class:Data_Service .

[dr-shorthair]

Renamed branch to dcat-issue432-simon and edited the links in the previous comment.
Please follow revised links from GitHub rather than the email alert.

[agreiner]

@andrea-perego I guess I didn't mean to offer a specific solution, but to point out that what we have now has some problems from my perspective. One option I see is to remove DataDistributionService and DataDiscoveryService but keep DataService and use dct:type to differentiate the various types of services. Another option is to keep DataDistributionService as a subclass of DataService and add other service types as siblings to DataDistributionService, not children, but only if we can make some useful distinctions in the metadata for the various sibling types.

[dr-shorthair]

DataDistributionService is the rdfs:domain of the property dcat:servesDataset which binds a service to one or more specified datasets. It is also the rdfs:range of the property dcat:accessService. So DataDistributionService does have specific metadata that distinguishes it from the general DataService.