Adding a version to profile attribute (or doing this via a "spec" namespace)

[pwalsh]

v1 is here! Going forward, we will have to have ways to handling different spec versions, and specifically, implementors will need to be able to rely on some metadata for this.

Status

• 👍 on supporting recording of version
• RECOMMENDED: Use urls for profiles and do versioning in url - see Profile is a url rather than string #689
• If we didn't go for that, keep profile single value and use @ eg. profile: "data-package@1.0"

Original Proposal

Towards this end, I propose adding a spec property, which is a namespace for this purpose. One can think of this namespace as being metadata for the descriptor itself, rather than metadata for the data.

At this stage, there are two properties that would live in the spec namespace:

• profile: This property has landed in v1
• version: This property has not yet been added to the specifications, but the need has been established and it will be vital for implementors going forward

"spec": {
  "profile": "tabular-data-package",
  "version": "1.0.0"
}

In the absence of the spec property, defaults are to be assumed:

• spec.profile - the same as the current profile definition
• spec.version - the current specification version

This property should apply to all specifications.

For related discussions, see #403 (use namespaces in DP - WONTFIX), #399 (introduce version - WONTFIX at time and reference to this issue for future changes) and #103

[sandervdwaal]

This sounds very useful for our Fiscal Data Package work over at OpenSpending, where we've also reached v1.0 and would like to be able to specify that so we can inspect a package to understand if it's v1.0 or not.
A related reason is that the repository behind OS has both v1.0 and pre-v1.0 data.

[pwalsh]

@rufuspollock let's talk this one over soon? My thoughts are basically the same as when I opened this issue.

[rufuspollock]

Generally 👍 but want to know how this works if e.g. a package satisfies several specs (is that a valid use case)?

[rufuspollock]

There's renewed interest in this and we have now hit v1 and making improvements beyond that. In terms of structure, one option is using a @ symbol eg.

profile: "data-package@1.4.0"

This would allow compatibility with current profile structure by defaulting when no @ to current.

[rufuspollock]

PROPOSED RESOLUTION:

• 👍 on supporting recording of version
• RECOMMENDED: Use urls for profiles and do versioning in url - see Profile is a url rather than string #689
• If we didn't go for that, keep profile single value and use @

@roll @pwalsh @akariv - thoughts?

[roll]

I generally like the idea of reducing "magic" for the profile field and using raw URLs. Is there is a plan to drop Data Package Identifier spec also (not implemented anywhere)? It's another "magic" or one-point-of-failure area making general specifications to be vendor-locked.

I think we can have endpoints on the specs site to publish profiles:

• https://specs.frictionlessdata.io/table-schema/v1/
• https://specs.frictionlessdata.io/table-schema/v1/profile.json

[rufuspollock]

@roll glad you like this approach and agree on deprecating data-package-identifier spec. Also agree on endpoint style.