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.

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

DCAT: Distribution – suggestion attribute for record – ‘planned availability’ #40

Open
init-dcat-ap-de opened this issue Mar 14, 2018 · 12 comments

Comments

@init-dcat-ap-de
Copy link

@init-dcat-ap-de init-dcat-ap-de commented Mar 14, 2018

Def:
Uses a list of guaranteed availabilities, like

http://dcat-ap.de/def/plannedAvailability/temporary
http://dcat-ap.de/def/plannedAvailability/experimental
http://dcat-ap.de/def/plannedAvailability/available
http://dcat-ap.de/def/plannedAvailability/stable

Datatype: rdfs:resource

Reasoning for change:
This concept was added to dcat-ap.de and seems to be a good extension for dcat-ap itself; perhaps even W3C dcat.
The concept of indicating a datasets planned lifetime close to other metadata of the dataset seems a good idea for fostering reuse and decoupling the dataset metadata from its technical publishing channel.

@akuckartz

This comment has been minimized.

Copy link

@akuckartz akuckartz commented Mar 14, 2018

rdfs:Resource is better that rdfs:Literal but I think this can and should be restricted to skos:Concept.

@makxdekkers

This comment has been minimized.

Copy link
Collaborator

@makxdekkers makxdekkers commented Mar 15, 2018

This seems to be essentially an aspect of 'status'. If so, maybe the controlled vocabulary MDR Dataset status could be used and maybe extended if necessary?

@DGatt

This comment has been minimized.

Copy link

@DGatt DGatt commented Mar 16, 2018

The idea is actually from the silver level of the ODI open data certificates (https://certificates.theodi.org/en/about/whatyouneed ). It describes an aspect of the "level of dependability" of the data: "For a silver certificate, you should intend for the data to be available in the same form for at least a year. If it is not going to be available for at least a year, it is unlikely any reuser will invest time to use it except in proofs of concept."
As such the concept seems to be orthogonal to "status". I agree that it could be restricted to skos:Concept.

@makxdekkers

This comment has been minimized.

Copy link
Collaborator

@makxdekkers makxdekkers commented Apr 7, 2018

A couple of questions related to this:

  1. what charateristic of the dataset does this list of terms describe? The terms do not seem to be for "planned lifetime"; for "lifetime", I would expect a value of type "period of time". Would it be more like "availability"?
  2. would this be similar to schema:availability? see http://schema.org/availability. Or do you know of other standards that have a property that could be reused?
  3. what is the exact meaning of each of the proposed values in the vocabulary? It looks like the value :available is in a different dimension than the other three.
@DGatt

This comment has been minimized.

Copy link

@DGatt DGatt commented Apr 9, 2018

At https://certificates.theodi.org/ one can find the following elaborations:-

  • temprorary: it might disappear at any time
  • experimental: it's available experimentally but should be around for another year or so
  • available: it's in your medium-term plans so should be around for a couple of years
  • stable: it's part of your day-to-day operations so will stay published for a long time

This doesn't amount to an exact definition, but I think it describes very well the reality, where a precise lifetime of the data is seldom on the records, yet one can give the users at list a hint how much they can rely on the future availability. A value type "period of type" is nevertheless an alternative.

@makxdekkers

This comment has been minimized.

Copy link
Collaborator

@makxdekkers makxdekkers commented Apr 26, 2018

Proposed resolution | Retain issue for next major semantic release.

@addragan

This comment has been minimized.

Copy link
Contributor

@addragan addragan commented Jul 23, 2019

Proposed resolution: Align DCAT-AP with DCAT that is also currently developing this area, see discussion https://www.w3.org/TR/vocab-dcat-2/#Class:Period_of_Time.

@init-dcat-ap-de

This comment has been minimized.

Copy link
Author

@init-dcat-ap-de init-dcat-ap-de commented Jul 25, 2019

We do not see that "Period_of_time" will cover the requirement of "indicating whether something is meant to be persistent or just provided for temporal usage."

In both cases indicating an exact time will not tell the user about the intended stability of an URL.

@NatasaSofou

This comment has been minimized.

Copy link
Contributor

@NatasaSofou NatasaSofou commented Sep 12, 2019

Proposed resolution:

  • add plannedAvailability in class dcat:Distribution.

  • propose a different name

  • decide whether it will be optional or recommended

@init-dcat-ap-de

This comment has been minimized.

Copy link
Author

@init-dcat-ap-de init-dcat-ap-de commented Sep 17, 2019

We suggest to name the element "availability" with the options
temporal
experimental
available
stable

and make it a recommended one.

@init-dcat-ap-de

This comment has been minimized.

Copy link
Author

@init-dcat-ap-de init-dcat-ap-de commented Oct 7, 2019

In the UML diagram dcatap:availability is marked as optional, in the PDF as recommended.

@init-dcat-ap-de

This comment has been minimized.

Copy link
Author

@init-dcat-ap-de init-dcat-ap-de commented Oct 20, 2019

The property now has the range skos:Concept, in dcat-ap.de we use rdf:ressource and a controlled vocabulary with URIs. We recommend something similiar for dcat-ap.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.