Skip to content
This repository has been archived by the owner on Jun 18, 2024. It is now read-only.

Clarify that format refers to mediaType #272

Closed
philipashlock opened this issue Feb 12, 2014 · 4 comments
Closed

Clarify that format refers to mediaType #272

philipashlock opened this issue Feb 12, 2014 · 4 comments

Comments

@philipashlock
Copy link
Contributor

While many of the fieldnames are derived from DCAT it looks like format and mediaType were mixed up. The way that format is used here is really what mediaType is meant for (referring to IANA, aka MIME type). The distinction is described here: http://www.w3.org/TR/vocab-dcat/#Property:distribution_media_type

As a recommendation for a future iteration of the spec, format should be deprecated in favor of mediaType when referring to an IANA (aka MIME type) value as we're currently using it. The format field could still be acceptable for a more human readable name for the mediaType as per http://www.w3.org/TR/vocab-dcat/#Property:distribution_format

In related issues: mediaType should also be paired with downloadURL (#335) within the distribution array (#217)

@mhogeweg
Copy link
Contributor

I want to connect a discussion to this issue that's been going on between a number of us offline (@ddnebert, @rsignell-usgs, @amilan17, ...) about format. There are some guidance documents such as the Geospatial Platform/data.gov Metadata Best Practices to Support data Discovery that suggest specific values of format that are not media types, or the Open Geospatial Consortium OGC Urn Policy that suggest specific values for service types (which in the end are referenced in the accessURL).

it would be good to get a consolidated list of formats (or mediaTypes as @philipashlock suggests) to be used in DCAT and through that hopefully upstream in agency catalogs and metadata practices.

@gbinal
Copy link
Contributor

gbinal commented Aug 22, 2014

@gbinal
Copy link
Contributor

gbinal commented Sep 8, 2014

This is addressed in 6c376cf

rebeccawilliams pushed a commit that referenced this issue Oct 2, 2014
Changes that still need to be addressed are changes in structure and should we add usage notes additions here or no?:

* Adds optional describedByType field at the dataset and distribution level (#291, #332)
* Changes contactPoint field to an object that contains the name (fn) and email address (hasEmail) (#358)
* Adds fn field as part of contactPoint replacing earlier use of contactPoint (#358)
* Changes publisher field to an object that allows multiple levels of organizations (#296)
* Changes accessURL field to represent indirect access and to exist only within distribution (#217, #335) 
* Changes format field to a human readable description and to exist only within distribution (#272, #293)
* Adds optional description field for use within distribution (#248)
* Adds optional title field for use within distribution (#248)
* Changes accrualPeriodicity field to use ISO 8601 date syntax (#292)
* Changes distribution field to become required-if-applicable and to always contain the accessURL or downloadURL fields (#217)
* Changes license field to be a URL (#196)
@gbinal
Copy link
Contributor

gbinal commented Nov 7, 2014

Thank you for driving the conversation around this issue and helping to assemble the v1.1 metadata update.

There appears to be strong consensus around this issue, which has been accepted in the v1.1 update and merged into Project Open Data. Project Open Data is a living project though. Please continue any conversations around how the schema can be improved with new issues and pull requests!

It's important for government staff as well as the public to continue to collaborate to make the Open Data Policy ever better. Though the v1.1 update is a substantial update, future iterations do not have to be, so whatever your ideas - big or small - please continue to work with this community to improve how government manages and opens its data.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants