Navigation path

DCAT application profile for data portals in Europe

(
 
)
5/5 | 9 votes
Editor's choice

Available Translations

Available Translations:

DCAT Application Profile for Data Portals in Europe - Final Draft

(
 
)
5/5 | 2 votes | 7836 reads |
Editor's Choice

Description

The DCAT Application profile for data portals in Europe (DCAT-AP) is a specification based on the Data Catalogue vocabulary (DCATfor describing public sector datasets in Europe. Its basic use case is to enable a cross-data portal search for data sets and make public sector data better searchable across borders and sectorsThis can be achieved by the exchange of descriptions of data sets among data portals.

This final draft is open for public review until 15 July 2013 (extended deadline). Members of the public are invited to download the specification and post their comments directly on this page. To be able to do so you need to be registered and logged in.

All issues will be discussed by the DCAT Application Profile Working Group, in the Virtual Meeting of 18 July 2013.

 

The DCAT-AP will be used in the Open Data Support service that will shortly be initiated by the European Commission. This new service will play an important role towards realising the objectives of the pan-European Data Portal.

Keywords

data portal
Antonio Maccioni
Posted by Antonio Maccioni on July 08, 2013 at 18:48
"

DCAT-AP Public Review

 

General comments on the final draft:
 
1. I would mention Dublic Core as a related work. DCAT is "almost an extension" of Dublin Core.
 
2. In section 11.3 the PROV model should be mentioned. It has been recently standardized by the W3C as the model to manage provenance.
 
Typos:
 
3. There is a typo in the section 1.2: "...terms form one or more...".
 
4. There is a typo in the section 11.3 "According the the base DCAT specification...".
Makx Dekkers
Posted by Makx Dekkers on June 25, 2013 at 13:50
"

Lynne, thanks for your comments. We'll look at the spelling and correct the typos. 

On your other issues:

  • The ADMS namespace is not in the list in section 4.2.2 because that list specifies the namespaces used in the base DCAT specification. You are right that there is no reference to the ADMS namespace (other than in a footnote on page 3). I will include a list of namespace prefixes in the beginning of section 6.
  • The application profile uses dct: because that is what the base DCAT specification uses. It appears that implementers prefer the shorter version.
  • There is no concept in DCAT (nor in the AP) for "dataset content creator". The only Agent  role that is specified is the publisher, expressed through the property dct:publisher.

 

 

Lynne McAvoy
Posted by Lynne Mcavoy on June 24, 2013 at 22:17
"

DCAT Final Draft comments

When I first saw the document title with namespace (DCAT) I thought it was a new Dublin Core namespace. Modifying the document title to reflect the long name form (as in W3C document) would increase clarity:

Data Catalog Vocabulary (DCAT) Application Profile for data portals in Europe

 

Spelling inconsistency throughout the document: “datasets” vs “data sets”

 

The namespace prefix for Dublin Core terms is typically “dcterms” and formatted as “dcterms:subject”. Why is it listed as “dct” in both this document (see 4.2.2) and the W3C document?

 

2.1.6 Typo : SMDX should be SDMX

 

Figure 2-DCAT Application Profile UML Diagram:  

  • Under dcat:Dataset, there are inconsistent namespace entries “adms” and “amds”. Neither of these was refered to in the namespace prefixes in section 4.2.2

Which property would be used for the concept of the dataset Content Creator? “Agent” does not seem to include roles. How are the various roles recorded?

Makx Dekkers
Posted by Makx Dekkers on June 17, 2013 at 19:14
"

Enrico, thanks for your comment.

 

The use of dcat:accessURL and dcat:downloadURL in the Application Profile is based on the way the base DCAT specification handles access to distributions of datasets. DCAT works on the assumption that datasets are distributed as files, and the dcat:downloadURL is the URL where such a file can be directly accessed. The property dcat:accessURL is more general and can also link to a landing page that gives access to the distribution. But for the time being, the protocol to get access to the distribution is limited to HTTP as these properties are HTTP URLs.

An issue was raised on the mailing list of the W3C Government Linked Data Working Group related to the description of APIs (see http://lists.w3.org/Archives/Public/public-gld-wg/2013May/0087.html). This may be covered in future work on DCAT.

I am not quite sure I understand your requirement for an additional name property; both the Dataset and the Distribution have a dct:title property that can be used for their names. Every Distribution also has a URI, which is the 'correct' identifier.

Enrico Boldrini
Posted by Enrico Boldrini on June 17, 2013 at 15:48
"

The dcat:accessURL element by itself seems to be insufficient to address the problem of machine to machine access of datasets published on a given access service type (e.g. WMS, OPeNDAP, WFS, ...).
Clients would benefit of an additional "protocol" element, in order to communicate with the remote data service using the correct protocol. Use of URNs is suggested for this element when available (e.g. urn:ogc:serviceType:WebCoverageService:1.0:HTTP)
Clients would benefit as well of an additional resource "name" element, in order to request the dataset using the correct identifier (e.g. this element will be filled with the layer name in case of WMS or the coverage name in case of a WCS).
("name" and "protocol" have been borrowed from ISO 19115)

Makx Dekkers
Posted by Makx Dekkers on June 15, 2013 at 12:54
"
Johan, thanks for your comments.
 
Your remarks 1 and 2 concern table 2 wich will be deleted from the specification and replaced by a reference to the final DCAT specification, as the text in section 4.2 explains. I do not know the status of the ttl file, but it seems to me that Government Linked Data Working Group at W3C should be responsible for providing consistent files for both the human-readable and machine-readable versions. This also covers your remarks 4 and 5.
 
Remark 3: I will propose to the DCAT-AP WG to add a paragraph to section 8.2 pointing to both the Open Data Commons and the Creative Commons licences.
 
Remark 6: The resolution of the URIs of the Publications Office was raised as an issue in the WG. See the issue at https://joinup.ec.europa.eu/asset/dcat_application_profile/issue/investigate-alternatives-eurovoc and the response from the Publications Office at 
Johan De Smedt
Posted by Johan De Smedt on June 10, 2013 at 8:51
"

Remark 1:

about: Table 2: DCAT properties, alphabetically per class;

dcat:Distribution

byteSize

dcat:byteSize

>>> start remark

There is a difference between the ttl schema file and the on-line documentation

- ttl: dcat:bytes

- specification document: dcat:byteSize

This should be resolved before usage

end remark <<<<

 

Remark 2:

about: Table 2: DCAT properties, alphabetically per class;

dcat:Distribution

media type

dcat:mediaType, subproperty of dct:format

>>> start remark

a reference can be added to http://mediatypes.appspot.com/ which provides a representation of IANA mime-types as URI.

See also: http://answers.semanticweb.com/questions/639/is-there-a-namespace-to-des...?

end remark <<<<

 

Remark 3:

about: 7.4.1 Mandatory properties for Distribution; license

>>> start remark

Proposal: Add reference to http://www.w3.org/TR/void/#license giving license suggestions.

end remark <<<<

 

Remark 4:

about 7.4.2 Optional properties for Distribution; byteSize

>>> start remark

same as remark 1 above

end remark <<<<

 

Remark 5:

about 7.4.2 Optional properties for Distribution; media type

>>> start remark

same as remark 2 above

end remark <<<<

 

Remark 6:

about 8.2 Controlled vocabularies


>>> start remarks

Most of the publications.europa.eu vocabulaires are not yet accessible

A note chould explain

- where to find working versions

- when to expect released version

end remark <<<<

 

Makx Dekkers
Posted by Makx Dekkers on May 14, 2013 at 18:12
"

David, there are zip file viewers for various operating systems.

I am also told that the next release of Joinup (expected next week) will allow us to directly include non-zipped files.

 
David Valentine
Posted by David Valentine on May 14, 2013 at 15:43
"

Zip files mean you can't easily download to tablets.

and docx is already zipped.

Metadata

Type: Interoperability Solution
Solution category:
Framework
Interoperability level:
Semantic
Release Language:
English
Publisher:
Related solutions:
Solution type:
Information Exchange Package Description
Status:
Under development
Date of creation:
13 May 2013 - 18:15
Date of last modification:
4 Dec 2014 - 19:26