[Rafnuss]

v1.0 puts the GeoLocator DP table schema URL in resource.$schema, but in the Data Package standard $schema is the profile of the descriptor and the Table Schema belongs in schema. A resource written exactly as v1.0 prescribes cannot be read:

Resource "tags" must have a schema property.

Real GeoLocatoR output failed the profile too — 8/8 resources — because it writes an inline schema and no $schema. The two errors cancelled out and nothing validated a complete package, so neither was noticed.

This brings v1.1 into line with Data Package v2 and adds an example package plus a CI check, so a mistake of this shape cannot go unnoticed again.

Resources

A tabular resource now requires $schema, name, path, type and schema:

{
  "$schema": "https://datapackage.org/profiles/2.0/dataresource.json",
  "name": "tags",
  "path": "tags.csv",
  "type": "table",
  "schema": "https://raw.githubusercontent.com/GeoPressure/GeoLocator-DP/v1.1/tags-table-schema.json"
}

schema also accepts an inline descriptor, so packages stay self-contained. type: "table" replaces the v1 profile: "tabular-data-resource". Package-level $schema is unchanged.

$schema is required, not optional. Without it frictionless::version() reads a resource as Data Package v1 even inside a package declaring v2 — the package reports >=2.0 while every resource in it reports 1.0 — and upgrade_resource() branches on exactly that value. GeoLocatoR sets the property itself rather than waiting for frictionless 2.0 to reach CRAN.

Table schemas

• fieldsMatch is a string, not an array. The array form came from an error in the published Table Schema profile (frictionlessdata/datapackage#965), fixed in v2.1.
• tags moves to fieldsMatch: partial, so a package may carry extra attributes on a tag. The other six tables keep superset.
• primaryKey and foreignKeys fields are arrays of strings, the v2 spelling.
• categories on every categorical field, giving each allowed value a label. The EURING age_class and catching_method codes were previously only partly documented in prose; measurements.sensor carries its vocabulary term per category. enum is kept alongside, as the standard allows, because no implementation enforces categories yet.
• Dropped the unique constraint on tags.tag_id, which duplicated the primary key; fixed the observations.sex and pressurepaths.type examples, which were not valid values of their own fields.

One thing worth recording: fieldsMatch says nothing about which columns are required, so on its own every mode here lets a table omit a column carrying a required constraint — including a primary key. The standard cannot yet express "the required columns must be present, the optional ones may be absent" (frictionlessdata/datapackage#1126), so GeoLocatoR::validate_gldp() checks that separately.

Profile

Resource schemas are selected with if/then on the resource name rather than oneOf. The accepted descriptors are unchanged, but a validation error now names the property at fault instead of reporting that the whole resource matched none of the branches.

Website and CI

• Each table page shows primaryKey, foreignKeys, missingValues and fieldsMatch, lists categories with their labels, links SKOS terms by identifier, and says which columns may be left out and which must be present — the * marking a required column was previously unexplained.
• Fixed a broken SKOS link on observations.datetime and restored the _data symlink for the measurements schema, so the site renders the schema the standard ships.
• Added example/datapackage.json with example/measurements.csv, and tests/validate_profile_and_schemas.py, which validates the example package against the profile along with the spelling of fieldsMatch and of the keys. It runs on every PR.
• Added the changelog page.

Compatibility

Breaking for archived packages, which carry profile and no type — hence v1.1. GeoLocatoR upgrades them on read.

Resources still carry profile: "tabular-data-resource" alongside $schema and type. It is the v1 spelling those two replace, but frictionless 1.3.0, the current CRAN release, refuses to read a resource without it. It can be dropped once frictionless 2.0 ships.

Tracked separately: #36 (lat/lon vs latitude/longitude) and uniqueKeys adoption, which needs the j column to stop being null outside simulations.

🤖 Generated with Claude Code

[Rafnuss]

@peterdesmet, Could I ask you opinion on the required property on $schema? I'm not really seeing the point of forcing it as I can control it in creation, but I'm not sure I have a wide enough understanding on the issue.

I'm also considering to set tags resources as fieldMatch: partial to be more flexible to possible specific user case. Curious to hear if you have any opnion on this too?

[peterdesmet]

1. Question about the issue title. Did geolocatoR 1.0 put the table schema in $schema? Cause that is wrong, table schema should be included or referenced in schema.

I'm not really seeing the point of forcing it as I can control it in creation

2. What do you mean by forcing it? When reading? Note that frictionless will use that property to assess the version of the Data Package standard used.

3. If you’re using Data Package v2 properties like fieldMatch, then you should set $schema to the v2 value. Definitely for schema, and also for the resource.

I'm also considering to set tags resources

4. What do you mean by tags?

—

A minimal json example of a package with a resource and schema might help 😊

[Rafnuss]

Thanks @peterdesmet, this is helpful.

1. Yes, it was wrong: v1.0 had required: ["name", "path", "$schema"] with $schema pinned to a *-table-schema.json URL, and no schema property at all. That's what this PR fixes 1062e75.

2./3. Ok, make sense. Implemented in a87f327

4. tags is one of our resources (tags.csv). Some users want to carry extra Movebank attributes on it, which superset forbids.

Example — example/datapackage.json in this PR:

{
  "$schema": "https://raw.githubusercontent.com/GeoPressure/GeoLocator-DP/v1.1/geolocator-dp-profile.json",
  "resources": [
    {
      "$schema": "https://datapackage.org/profiles/2.0/dataresource.json",
      "name": "tags",
      "path": "tags.csv",
      "type": "table",
      "format": "csv",
      "mediatype": "text/csv",
      "encoding": "utf-8",
      "schema": "https://raw.githubusercontent.com/GeoPressure/GeoLocator-DP/v1.1/tags-table-schema.json"
    }
  ]
}

[peterdesmet]

Your geolocator-dp-profile.json looks good:

• Extends "https://datapackage.org/profiles/2.0/datapackage.json", so the package is defined as v2
• Requires package.$schema with a URL referring to your geolocator-dp-profile. This is self-fulfilling: if you refer to it, it will be there.
• Requires resource.$schema with the value "https://datapackage.org/profiles/2.0/dataresource.json", so resources are defined as v2
• Requires resource.schema referring to a table-schema for that resource
• Requires resource.type with the value "table". This is good practice (documents that it is tabular), but not absolutely needed. Good to have it.

The table schemas (e.g tags-table-schema.json) look good too:

• Have schema.$schema with the value https://datapackage.org/profiles/2.0/tableschema.json, so resources are defined as v2
• Have fieldMatch which is now a string rather than an array.

The fieldMatch you currently have is:

• edges: superset
• measurements: superset
• observations: superset
• paths: superset
• pressurepaths: partial
• staps: superset
• tags: superset
• twilights: superset

So all tables can MAY fewer fields than in the schema, except for pressurepaths, which may have fewer fields + extra undefined fields.

---

For all of the above version() in {frictionless} should recognize the version as:

• package: >=2.0 (notices a custom $schema, doesn't dive deeper, but knows it's at least 2.0)
• resource: 2.0
• schema: 2.0

read_resource() in {frictionless} will throw an error, because we haven't implemented fieldsMatch yet (frictionlessdata/frictionless-r#216). But I think you catch that with your R package.