Separate concerns between metadata enrichment and data structure in Data Resource using resource.type. Remove Tabular Data Resource from v2 website

[roll]

• fixes Separate concerns between metadata extensions and resource types datapackage#887

---

Rationale

Currently, implementations have only one way to identify a resource type -- checking if profile: tabular-data-resource. But Tabular Data Resource can have a profile set to URL; it also can be set to an extension URL. It makes it basically impossible to guarantee resource's type information communication.

I think it will be more robust and extendable if the metadata enrichment system (profiles/extensions) is not mixed with the logical data structure (text/table/etc) as it is mostly orthogonal. For example, we might have Fiscal Data Resource (extra properties) but it still needs to be a table structurally.

This change might highly simplify the Data Resource spec structure and perception. At the same time, I don't think that since the v1 release there are any use cases that rely on resource.profile for anything else rather than resource type communication. Anyway, in frictionlessdata/datapackage#42 we will still have a way to extend resource using profile/$schema but it won't be coupled to the data structure.

Preview deployment:

• Data Resource

[cloudflare-workers-and-pages]

Deploying datapackage with    Cloudflare Pages

Latest commit:	de2b7f5
Status:	✅  Deploy successful!
Preview URL:	https://22f4da46.datapackage.pages.dev
Branch Preview URL:	https://887-separate-concerns-betwee.datapackage.pages.dev

View logs

[peterdesmet]

It's probably fine to leave this as SHOULD, but previously a resource with "profile"="tabular-data-resource" (i.e. a "Tabular Data Resource") REQUIRED the schema property.

I just want to make sure this change is intentional.

[roll]

@peterdesmet
I think one of the good consequences of removing specs fragmentation is that we can simplify things. What I read here - https://specs.frictionlessdata.io/tabular-data-resource/#specification - is that schema needs to be Table Schema, but it doesn't say that schema MUST be present. I also thought that schema was required, but I don't see it in the text.

Personally, I think that not requiring schema is better as it opens more usage scenarios based on incremental enhancement model

[peterdesmet]

Does that glossary item already exist?

[roll]

It needs to wait for #49 to get merged

[peterdesmet]

Is profile then not defined at all?

[roll]

If we goes with $schema I think it's only needed as a backward-compat note

[peterdesmet]

For clarification: are we abandoning the profile property in all specs then?

• In Data Package in favour of $schema, see Versioning and extensions #42.
• In Data Resource (this PR) in favour of type. Maybe some clarification should be provided on how to extend Data Resource with e.g. $schema (rather than the v1 profile). I see this is now suggested in Versioning and extensions #42. Note we will then have $schema and schema.

[ezwelty]

I like the symmetry of resource.type and field.type and agree that it feels more intuitive. What role could extensions have in defining or requiring resource.type? It seems that most extensions would be written for a specific resource type.

[roll]

@peterdesmet

For clarification: are we abandoning the profile property in all specs then?

I would say that current proposals just rename profile -> $schema (I would re-iterate on this renaming again on the Community Call but I feel that using $schema gives a lot of benefits), keeping almost exactly the same semantics for this property but also:

• providing versioning
• solving Profile is a url rather than string datapackage#689

At the same type as schema/profile being an URL with versioning can't now serve the needs of indicating a resource type, we introduce additional resource.type property. I agree with @ezwelty that is super natural to have this symmetry between resource.type and field.type (both resource and field are collection items in the hierarchy). In the future it also opens a door for adding other resource types like json with e.g. jsonSchema etc and probably we can't create a new spec for every new resource type.

[roll]

@ezwelty
As we figured it out in frictionlessdata/datapackage#823, modern JSON Schema gives us an ability to define almost any data package structure an extension needs, for example, this definition will accept only data packages with exactly 1 resource, that is a table called data (and we can required a specific schema, format etc as well):

resources:
  type: array
  items: false
  prefixItems:
    - type: object
      properties:
        name: 
          enum: [data]
        type:
          enum: [table]

[roll]

ACCEPTED by WG (6/9)