Merge branch 'main' into next

.husky/pre-push

@@ -0,0 +1 @@
+npm test

.prettierignore

@@ -1,2 +1,3 @@
 content/docs/guides/csvw-data-package.md
+content/docs/guides/mediawiki-tabular-data.md
 public/profiles

content/docs/guides/csvw-data-package.md

@@ -86,7 +86,7 @@ Data Package can define more than groups of tables. A [package](/standard/data-p
 
 ### Tables
 
-| CSVW property | Data package support | Details |
+| CSVW property | Data Package support | Details |
 | ---- | ---- | ---- |
 | [url](http://table-url) | Yes | As [resource.path](/standard/data-resource/#path-or-data) |
 | [dialect](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#table-dialect) | Yes | As [resource.dialect](/standard/data-resource/#dialect) |
@@ -104,7 +104,7 @@ Data Package can define more than groups of tables. A [package](/standard/data-p
 Data Package [Table Schema](/standard/table-schema/) has features that CSVW schema does not, including [fieldMatch](/standard/table-schema/#fieldsMatch) for matching a schema with data, [missingValues](/standard/table-schema/#missingValues) for multiple (and labelled) missing values, and [uniqueKeys](/standard/table-schema/#uniqueKeys).
 :::
 
-| CSVW property | Data package support | Details |
+| CSVW property | Data Package support | Details |
 | ---- | ---- | ---- |
 | [columns](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#schema-columns) | Yes | As [schema.fields](/standard/table-schema/#fields) |
 | [foreignKeys](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#schema-foreignKeys) | Yes | As [schema.foreignKeys](/standard/table-schema/#foreignKeys) |
@@ -115,7 +115,7 @@ Data Package [Table Schema](/standard/table-schema/) has features that CSVW sche
 
 ### Columns
 
-| CSVW property | Data package support | Details |
+| CSVW property | Data Package support | Details |
 | ---- | ---- | ---- |
 | [name](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#column-name) | Yes | As [field.name](/standard/table-schema/#name) |
 | [suppressOutput](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#column-suppressOutput) | No |  |
@@ -128,7 +128,7 @@ Data Package [Table Schema](/standard/table-schema/) has features that CSVW sche
 
 Data Package properties do not inherit from their parent, unless otherwise specified (e.g. [resource.sources](/standard/data-resource/#sources)). The properties listed below only exist at one level in Data Package, except for `missingValues`.
 
-| CSVW property | Data package support | Details |
+| CSVW property | Data Package support | Details |
 | ---- | ---- | ---- |
 | [aboutUrl](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#cell-aboutUrl) | Custom property |  |
 | [datatype](http://cell-datatype) | Yes | As [field.type](/standard/table-schema/#type-and-format) |
@@ -152,7 +152,7 @@ Common properties can be added in Data Package as [custom properties](/standard/
 Data Package [Table Dialect](/standard/table-dialect/) was used as inspiration for CSVW dialect. It has features that CSVW dialect does not, since it covers tabular data formats beyond delimited text files, such as spreadsheets and databases. For delimited text files it supports [headerJoin](/standard/table-dialect/#headerJoin), [doubleQuote](/standard/table-dialect/#doubleQuote), [escapeChar](/standard/table-dialect/#escapeChar), and [nullSequence](/standard/table-dialect/#nullSequence), which CSVW does not.
 :::
 
-| CSVW property | Data package support | Details |
+| CSVW property | Data Package support | Details |
 | ---- | ---- | ---- |
 | [commentPrefix](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#dialect-commentPrefix) | Yes | As [dialect.commentChar](/standard/table-dialect/#commentChar) |
 | [delimiter](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#dialect-delimiter) | Yes | As [dialect.delimiter](/standard/table-dialect/#delimiter) |
@@ -182,7 +182,7 @@ CSVW defines data types as built-in data types and derived data types. A derived
 Data Package [Table Schema](/standard/table-schema/) supports data types that CSVW does not, such as (labelled) [categories](/standard/table-schema/#categories) and [geojson](/standard/table-schema/#geojson). It also supports a number of constraints that CSVW does not, such as [unique](/standard/table-schema/#unique) values, [pattern](/standard/table-schema/#pattern) for regex comparison and [enum](/standard/table-schema/#enum) for controlled values, which allow rigorous data validation.
 :::
 
-| CSVW property | Data package support | Details |
+| CSVW property | Data Package support | Details |
 | ---- | ---- | ---- |
 | [base](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#datatype-base) | No | All types are defined as [field.type](/standard/table-schema/#type-and-format) |
 | [format](https://www.w3.org/TR/2015/REC-tabular-metadata-20151217/#datatype-format) | Yes | As [field.format](/standard/table-schema/#type-and-format) |

content/docs/guides/mediawiki-tabular-data.md

@@ -0,0 +1,61 @@
+---
+title: Comparison with MediaWiki Tabular Data
+sidebar:
+  order: 3
+---
+
+<table>
+  <tr>
+    <th>Authors</th>
+    <td>Jakob Voß</td>
+  </tr>
+</table>
+
+[MediaWiki](https://www.mediawiki.org/) is the software used to run Wikipedia and related projects of the Wikimedia Foundation, including the media file repository [Wikimedia Commons](https://commons.wikimedia.org/). Commons hosts mostly images but also some records with tabular data. The [MediaWiki Tabular Data Model](https://www.mediawiki.org/wiki/Help:Tabular_data) was inspired by Data Package version 1 but it slightly differs from current Data Package specification, as described below.
+
+## Property Comparison
+
+A [MediaWiki tabular data page](https://www.mediawiki.org/wiki/Help:Tabular_data) describes and contains an individual table of data similar to a [Data Resource](/standard/data-resource/) with inline tabular data. Both are serialized as JSON objects, but the former comes as a page with unique name in a MediaWiki instance (such as Wikimedia Commons).
+
+### Top-level Properties
+
+MediaWiki Tabular Data has three required and two optional top-level properties. Most of these properties map to corresponding properties of a Data Resource:
+
+| MediaWiki Tabular Data                                                                                                                     | Data Package Table Schema                                                             |
+| ------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------- |
+| - (implied by page name)                                                                                                                   | [name](/standard/data-resource/#name) (required) is a string                          |
+| [description](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (optional) is a localized string                          | [description](/standard/data-resource/#description) (optional) is a CommonMark string |
+| [data](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (required)                                                       | [data](/standard/data-resource/#name) (optional)                                      |
+| [license](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (required) is the string `CC0-1.0` or another known identifier | [licenses](/standard/data-resource/#licenses) (optional) is an array                  |
+| [schema](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (required) as [described below](#schema-properties)            | [schema](/standard/data-resource/#schema) (optional) can have multiple forms          |
+| [sources](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (optional) is a string with Wiki markup                       | [sources](/standard/data-resource/#sources) (optional) is an array of objects       |
+
+The differences are:
+
+- property `name` does not exist but can be implied from page name
+- property `description` and `sources` have another format
+- property `data` is always an array of arrays and [data types](#data-types) of individual values can differ
+- property `schema` is required but it differs in definion of [schema properties](#schema-properties)
+- there is no property `licenses` but `license` fixed to plain string value `CC0-1.0` (other license indicators may be possible)
+
+### Data Types
+
+Tabular Data supports four data types that overlap with [Table Schema data types](/standard/table-schema/#field-types):
+
+- `number` subset of Table Schema [number](/standard/table-schema/#number) (no `NaN`, `INF`, or `-INF`)
+- `boolean` same as Table Schema [boolean](/standard/table-schema/#boolean)
+- `string` subset of Table Schema [string](/standard/table-schema/#string) (limited to 400 characters at most and must not include `\n` or `\t`)
+- `localized ` refers to an object that maps language codes to strings with same limitations as `string` type.
+  This type is not supported in Table Schema.
+
+Individual values in a MediaWiki Tabular Data table can always be `null`, while in Table Schema you need to explicitly list values that should be considered missing in [schema.missingValues](/standard/table-schema/#missingValues).
+
+### Schema Properties
+
+The `schema` property of MediaWiki tabular contains an object with property `fields` just like [Table Schema](/standard/table-schema/) but no other properties are allowed. Elements of this array are like Table Schema [field descriptors](/standard/table-schema/#field) limited to three properties and different value spaces:
+
+| MediaWiki Tabular Data                                                                                                                   | Data Package Table Schema                                                                |
+| ---------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- |
+| [name](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (required) must be a string matching `^[a-zA-Z_][a-zA-Z_0-9]*` | [name](/standard/table-schema/#name) (required) can be any string                        |
+| [type](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (required) is one of the [Data Types above](#data-types)       | [type](/standard/table-schema/#type) (optional) with [different data types](#data-types) |
+| [title](https://www.mediawiki.org/wiki/Help:Tabular_data#Top-level_fields) (optional) is a localized string                              | [title](/standard/table-schema/#title) (optional) is a plain string                      |

content/docs/recipes/relationship-between-fields.md

@@ -5,13 +5,13 @@ title: Relationship between Fields
 <table>
   <tr>
     <th>Authors</th>
-    <td>Philippe Thomy, Peter Desmet</td>
+    <td>Philippe Thomy</td>
   </tr>
 </table>
 
-The structure of tabular datasets is simple: a set of Fields grouped in a table.
+The structure of tabular datasets is simple: a set of fields grouped in a table.
 
-However, the data present is often complex and reflects an interdependence between Fields (see explanations in the Internet-Draft [NTV tabular format (NTV-TAB)](https://www.ietf.org/archive/id/draft-thomy-ntv-tab-00.html#section-2)).
+However, the data present is often complex and reflects an interdependence between fields (see explanations in the Internet-Draft [NTV tabular format (NTV-TAB)](https://www.ietf.org/archive/id/draft-thomy-ntv-tab-00.html#section-2)).
 
 Let's take the example of the following dataset:
 
@@ -22,15 +22,15 @@ Let's take the example of the following dataset:
 | Estonia | European Union | ES   | 449        |
 | Nigeria | Africa         | NI   | 1460       |
 
-The data schema for this dataset indicates in the Field Descriptor "description":
+The data schema for this dataset has the following `description`:
 
-- for the "code" Field : "country code alpha-2"
-- for the "population" Field: "region population in 2022 (millions)"
+- for the `code` field : "country code alpha-2"
+- for the `population` field: "region population in 2022 (millions)"
 
 If we now look at the data we see that this dataset is not consistent because it contains two structural errors:
 
-- The value of the "code" Field must be unique for each country, we cannot therefore have "ES" for "Spain" and "Estonia",
-- The value of the "population" Field of "European Union" cannot have two different values (449 and 48)
+- The value of the `code` Ffeld must be unique for each country, we cannot therefore have "ES" for "Spain" and "Estonia",
+- The value of the `population` field of "European Union" cannot have two different values (449 and 48)
 
 These structural errors make the data unusable and yet they are not detected in the validation of the dataset (in the current version of Table Schema, there are no Descriptors to express this dependency between two fields).
 
@@ -70,92 +70,96 @@ Two aspects need to be addressed:
 
 A relationship is defined by the following information:
 
-- the two Fields involved (the order of the Fields is important with the "derived" link),
+- the two fields involved (the order of the fields is important with the `derived` link),
 - the textual representation of the relationship,
 - the nature of the relationship
 
 Three proposals for extending Table Schema are being considered:
 
-- New Field Descriptor
-- New Constraint Property
-- New Table Descriptor
+- New field descriptor
+- New constraint property
+- New table descriptor
 
-After discussions only the third is retained (a relationship between fields associated to a Field) and presented below:
+After discussions only the third is retained (a relationship between fields associated to a field) and presented below:
 
-- **New Table Descriptor**:
+- **New table descriptor**:
 
-  A `relationships` Table Descriptor is added.
-  The properties associated with this Descriptor could be:
+  A `relationships` table descriptor is added.
+  The properties associated with this descriptor could be:
 
-  - `fields`: array with the names of the two Fields involved
+  - `fields`: array with the names of the two fields involved
   - `description`: description string (optional)
   - `link`: nature of the relationship
 
   Pros:
 
-  - No mixing with Fields descriptors
+  - No mixing with fields descriptors
 
   Cons:
 
-  - Need to add a new Table Descriptor
-  - The order of the Fields in the array is important with the "derived" link
+  - Need to add a new table descriptor
+  - The order of the fields in the array is important with the `derived` link
 
   Example:
 
   ```json
-  { "fields": [ ],
+  {
+    "fields": [ ],
     "relationships": [
-      { "fields" : [ "country", "code"],
+      {
+        "fields" : ["country", "code"],
         "description" : "is the country code alpha-2 of",
         "link" : "coupled"
       }
-      { "fields" : [ "region", "population"],
+      {
+        "fields" : ["region", "population"],
         "description" : "is the population of",
-        "link" : "derived"}
+        "link" : "derived"
+      }
     ]
   }
   ```
 
 ## Specification
 
-Assuming solution 3 (Table Descriptor), the specification could be as follows:
+Assuming solution 3 (table descriptor), the specification could be as follows:
 
-The `relationships` Descriptor MAY be used to define the dependency between fields.
+The `relationships` descriptor MAY be used to define the dependency between fields.
 
-The `relationships` Descriptor, if present, MUST be an array where each entry in the array is an object and MUST contain two required properties and one optional:
+The `relationships` descriptor, if present, MUST be an array where each entry in the array is an object and MUST contain two required properties and one optional:
 
 - `fields`: Array with the property `name` of the two fields linked (required)
 - `link` : String with the nature of the relationship between them (required)
-- `description` : String with the description of the relationship between the two Fields (optional)
+- `description` : String with the description of the relationship between the two fields (optional)
 
 The `link` property value MUST be one of the three following :
 
-- `derived` :
+- `derived`:
 
   - The values of the child (second array element) field are dependant on the values of the parent (first array element) field (i.e. a value in the parent field is associated with a single value in the child field).
-  - e.g. The "name" field [ "john", "paul", "leah", "paul" ] and the "Nickname" field [ "jock", "paulo", "lili", "paulo" ] are derived,
-  - i.e. if a new entry "leah" is added, the corresponding "nickname" value must be "lili".
+  - e.g. The `name` field ["john", "paul", "leah", "paul"] and the `nickname` field ["jock", "paulo", "lili", "paulo"] are derived,
+  - i.e. if a new entry "leah" is added, the corresponding `nickname` value must be "lili".
 
-- `coupled` :
+- `coupled`:
 
   - The values of one field are associated to the values of the other field.
-  - e.g. The "Country" field [ "france", "spain", "estonia", "spain" ] and the "code alpha-2" field [ "FR", "ES", "EE", "ES" ] are coupled,
-  - i.e. if a new entry "estonia" is added, the corresponding "code alpha-2" value must be "EE" just as if a new entry "EE" is added, the corresponding "Country" value must be "estonia".
+  - e.g. The `Country` field ["france", "spain", "estonia", "spain"] and the `code alpha-2` field ["FR", "ES", "EE", "ES"] are coupled,
+  - i.e. if a new entry "estonia" is added, the corresponding `code alpha-2` value must be "EE" just as if a new entry "EE" is added, the corresponding `Country` value must be "estonia".
 
-- `crossed` :
+- `crossed`:
 
   - This relationship means that all the different values of one field are associated with all the different values of the other field.
-  - e.g. the "Year" Field [ 2020, 2020, 2021, 2021] and the "Population" Field [ "estonia", "spain", "estonia", "spain" ] are crossed
+  - e.g. the `Year` field [2020, 2020, 2021, 2021] and the `Population` field [ "estonia", "spain", "estonia", "spain"] are crossed
   - i.e the year 2020 is associated to population of "spain" and "estonia", just as the population of "estonia" is associated with years 2020 and 2021
 
 ## Implementations
 
-The implementation of a new Descriptor is not discussed here (no particular point to address).
+The implementation of a new descriptor is not discussed here (no particular point to address).
 
 The control implementation is based on the following principles:
 
-- calculation of the number of different values for the two Fields,
-- calculation of the number of different values for the virtual Field composed of tuples of each of the values of the two Fields
+- calculation of the number of different values for the two fields,
+- calculation of the number of different values for the virtual field composed of tuples of each of the values of the two fields
 - comparison of these three values to deduce the type of relationship
 - comparison of the calculated relationship type with that defined in the data schema