Details of Distribution


It would be useful to be able to express the type of a Distribution if it is not a downloadable file. DCAT defines the property accessURL with definition "A landing page, feed, SPARQL endpoint or other type of resource that gives access to the distribution of the dataset" but it does not give further recommendation on how to distinguish between the options mentioned.

Some suggestions already made:   In use dct:format to indicate that the distribution is an API and dct:description to specify the API format(s).    In  use dct:conformsTo to describe how to access the data or what the structure of the data is, for example an API documentation, VOID description, Linked Data API description, CSV metadata, etc.   The latter suggestion could also be a solution for the need to be able to express the data schema of the data stated in  






Wed, 08/04/2015 - 11:20

I don't think we have agreed how to express a SPARQL end-point yet. VoID seems ideal for it, yet if Anastasia is correct, it is incompatible with DCAT because of its requirement of APIs as distributions. So we don't have any agreed way forward here. Suggestions welcome.


It does seem straightforward to agree to use dct:conformsTo for a link to a schema (JSON/XML/CSV) or ontology (linked data) or format documentation.


It seems less obvious to use dct:conformsTo for details of the transport of the data - API calls (e.g. Swagger API definition), Linked Data API calls. Personally I think we should use dct:conformsTo for this unless anyone can suggest a better one, but we do need it documented. The US version of DCAT-AP (which is derived from and aligned with DCAT) introduces describedBy and describedByType for this:


I'm not sure about Makx's suggestion of using dct:conformsTo to link to a VoID description of a dataset. Can you give some example RDF?

Wed, 08/04/2015 - 12:12

The suggestion to use dct:conformsTo to link to a VoID descriptions was not mine but made by Deirdre in her message Maybe she can elaborate?



Thu, 09/04/2015 - 12:31



I was looking at a way to describe how to access the data or what the structure of the data is, for example an API documentation, VOID description, Linked Data API description, CSV metadata, etc. and suggested dct:conformsTo


But you make a good point David. Description of dct:conformsTo is 'An established standard to which the described resource conforms.' Considering an API documentation or VOID description as an 'established standard' might be a stretch.


dct:description could be used either. A resource can have multiple descriptions, for example, a human-readable description, and a formal API/SPARQL Endpoint description?

Fri, 17/04/2015 - 11:12

I agree with the use case being presented here as an useful and frequent one, but I'm afraid all alternatives proposed so far are not appropriate (being the use of conformsTo too stretch as said, don't know how we could be indicating APIs, SPARQL endpoints and the like as formats and don't see them as alternatives "descriptions" as well.

Unfortunately I can't come up with a better approach by now.



Thu, 23/04/2015 - 07:09

I suggest that conformsTo is used, and certain URLs are used for certain APIs. eg.



<foo> dct:conformsTo <; .



<bar> dct:conformsTo <; .


This way automated services can 'expore' further without having to guess.



In the UK we have a project to collect open data about university research equipment, which can be published in one of 6 ways. We use dct:confomsTo for people to indicate which they are using. eg.


(see the dct:conformsTo). This appoach has worked fine for us


Thu, 23/04/2015 - 11:37

On the phone meeting I suggested we use some standardized text in the dct:description field. To avoid translation issues, the proposal could be is simply to have:


<foo> dct:description "SPARQL"


We were a bit stuck with the premise that there is not an agreeable way to express a SPARQL endpoint in DCAT. And since it is something we want to express in a machine-readable way, we talked about finding a pragmatic way to do this, that didn't bend/break any of the rules, and hope that DCAT & VOID work out their differences soon.


However, I'm actually more in favour of using dct:conformsTo as Christopher suggests. It's not quite what it was designed for, but it's pretty close, and it's working in the real world. And it takes a URI as a parameter, which really doesn't suit dct:description for many cases where APIs do have a URL/URI.

Sun, 03/05/2015 - 17:35

The optional property dct:conformsTo for Distribution is in Draft 3.

Thu, 04/06/2015 - 10:16

I 'd like to point you to this initiative:… the catalogue community is setting up a list of 'common data protocols', to be used in such a fields like conformsTo. Next step would be to expose them as a skos vocab (or have the list be adopted by iana for example)

Sun, 07/06/2015 - 10:16

The content of this field is kept private and will not be shown publicly.