Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Distribution vs DataDistributionService #809

Closed
andrea-perego opened this issue Mar 8, 2019 · 4 comments
Closed

Distribution vs DataDistributionService #809

andrea-perego opened this issue Mar 8, 2019 · 4 comments
Labels
critical defects that must be completed for CR dcat:DataService dcat:Distribution dcat
Milestone
DCAT CR

Comments

@andrea-perego
Copy link
Contributor

andrea-perego commented Mar 8, 2019 •
edited
Loading

In the section of the DCAT spec devoted to distributions, the following text is included in a note:

The scope of dcat:Distribution here is narrower than in DCAT-2014 [VOCAB-DCAT-20140116], where it also included APIs and feeds. Data catalogues designed using DCAT-2014 therefore used instances of type dcat:Distribution to describe data distribution services. Applications consuming DCAT should be aware that catalogues designed using DCAT-2014 might use dcat:Distribution to represent both services and representations.

Under the revised scope, instances of type dcat:Distribution SHOULD be limited to representations of datasets which might be transported as files, and SHOULD NOT be used for data services such as APIs or feeds. Data services including APIs and feeds SHOULD be described using instances of type dcat:DataService whose sub-class dcat:DataDistributionService MAY serve dcat:Distributions.

Links between a dcat:Distribution and services or web addresses where it can be accessed are expressed using dcat:accessURL, dcat:accessService, dcat:downloadURL, as shown in Figure 1 and described in the definitions below.

Reading the two first paragraphs (and especially the 2nd one), it seems that dcat:Distribution is replaced by dcat:DataDistributionService whenever the data is accessible via a service / API.

Unless I'm mistaken, this is not the case. When data is available via a service / API, dcat:Distribution will be still there, but, in addition to what is in DCAT 2014, it points to the service / API by using specific properties - as explained in the last paragraph of the quoted text above.

Probably the issue with the text concerns this statement "The scope of dcat:Distribution here is narrower than in DCAT-2014 [VOCAB-DCAT-20140116], where it also included APIs and feeds." I don't think this was the case: dcat:Distribution's were just pointing to APIs and feeds, but not describing or replacing them - also because there were no appropriate properties for doing that.

So, it is not the scope of dcat:Distribution that is narrower; rather, the point is that now DCAT offers the possibility to provide details about the service / API (if any) a dcat:Distribution points to, with the purpose of enabling consumers (human and machines) to know which mechanisms should be used to access the data. In other words, we are talking here about an extension to DCAT, not of a revision of scope of a legacy class.
@dr-shorthair
Copy link
Contributor

dr-shorthair commented Mar 10, 2019 •
edited
Loading

Thanks @andrea-perego. I added those paragraphs on the basis of my interpolation from the examples that you provided, but I now see that I didn't get it quite right (I think the discussion is in #56, #166, #172). I had the impression that Services had been shoehorned into dcat:Distributions in some catalogs, as mentioned in

Data catalogues designed using DCAT-2014 therefore used instances of type dcat:Distribution to describe data distribution services.

so the warning about backward compatibility was needed. But maybe not. So I guess the material that you quote above can be dropped completely? All of the important information is implied by the descriptions of the properties dcat:accessURL and dcat:accessService.

@andrea-perego
Copy link
Contributor Author

@dr-shorthair said:

So I guess the material that you quote above can be dropped completely? All of the important information is implied by the descriptions of the properties dcat:accessURL and dcat:accessService.

Yes, I would be in favour of dropping that part. Thanks for explaining the background for that, text, @dr-shorthair .

@andrea-perego andrea-perego mentioned this issue Mar 12, 2019
Merged
@davebrowning davebrowning added this to the DCAT CR milestone Mar 14, 2019
@davebrowning davebrowning added the critical defects that must be completed for CR label Mar 14, 2019
@dr-shorthair dr-shorthair mentioned this issue Mar 19, 2019
Merged
@dr-shorthair
Copy link
Contributor

I've attempted to address this in #832

dr-shorthair pushed a commit that referenced this issue Mar 27, 2019
Somehow these notes crept back in - they were removed in #832 in resp…
630cfcd 
…onse to #809

Squashed again
@dr-shorthair dr-shorthair added the due for closing Issue that is going to be closed if there are no objection within 6 days label Mar 31, 2019
@davebrowning
Copy link
Contributor

As notified/discussed: https://www.w3.org/2017/dxwg/wiki/Meetings:Telecon2019.04.02

@davebrowning davebrowning removed the due for closing Issue that is going to be closed if there are no objection within 6 days label Apr 5, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
critical defects that must be completed for CR dcat:DataService dcat:Distribution dcat
Projects
None yet
Milestone
DCAT CR
Development

No branches or pull requests
3 participants
@dr-shorthair @andrea-perego @davebrowning