2.1.1 2.1 Direct Annotations

Direct annotations are properties on the description object for a given table, column, row or cell which map directly to properties on the described table, column, row or cell. The name of the annotation is the same as the name of the property on the annotation. The value of the annotation is the same as the value of the property on the description object.

2.1.2 2.2 Inherited Properties

A cell may be assigned annotations based on properties on the description objects for the group of tables, table, column or row that it appears in. These properties are known as inherited properties and are listed in section 3.8 3.10 Cells Inherited Properties . To ascertain a value for these annotations, an application MUST identify the relevant property in the descriptions of the table, column and row. table or column.

Applications MUST raise an error if the value of a property in a column or row table description is not compatible with the value of that property on the table. group of tables. Applications MUST raise an error if the value of a property on in a row column description is not compatible with the values value of that property on all the columns in the table. Application Applications MUST raise an error if the value of a property on a cell is not compatible with the values of that property on both the column and the row that the cell is associated with.

A value for a cell, column or row table is compatible with with a value on a row, column or column, table or group of tables if they are the same value or if the first value is a sub-value of the second value. The definitions of individual inherited properties indicate what values count as sub-values of others.

3.1 Property Syntax

There are different types of properties on description objects:

array properties

These hold an array of one or more objects, which are usually description objects .

For example, the resources property is an array property. A table group description might contain:

"resources": [{

  "@id": "https://example.org/countries.csv",
  "schema": "https://example.org/countries.json"
}, {
  "@id": "https://example.org/country_slice.csv",
  "schema": "https://example.org/country_slice.json"
}]

in which case the resources property has a value that is an array of two table description objects.

link properties

These hold one or more references to other resources by URL. Their values may be:

• strings — � resolved as URLs against the base URL
• arrays — � lists of strings which are resolved as URLs against the base URL

For example, the hasVersion dc:hasVersion property is a link property. A table description might contain:

Example 4

"hasVersion"

"dc:hasVersion"


:




"example-2014-01-03.csv"

in which case the hasVersion dc:hasVersion property on the table would have a single value, a link to example-2014-01-03.csv , or it . Alternatively, the metadata document might contain:

Example 5

"dc:hasVersion": [
  "example-2014-01-03.csv",
  "example-2014-01-17.csv",
  "example-2014-01-25.csv"


]

in which case the hasVersion dc:hasVersion property on the table would have be an array of three values, links to other versions of the table.

internal URI template properties

A URI template property contains a [ URI-TEMPLATE ] which can be used to generate a URI. These URI templates are expanded in the context of each row by combining the template with a set of variables with values. The variables that are set are:

_row

_row is set to the row number of the row that is currently being processed

Issue 32

Where does row numbering begin?

column names

a variable is set for each column within the schema; the name of the variable is the percent-encoded name of the column and the value is the canonical representation of the value of the cell in that column in the row that is currently being processed

For example, the urlTemplate property holds a URI template that is used to generate a URL identifier for each row, which might look like:

Example 6

"urlTemplate"
:
"http://example.org/example.csv#row={_row}"

The identifiers that are generated for the rows would then look like http://example.org/example.csv#row=1 , http://example.org/example.csv#row=2 and so on.

Alternatively, with the CSV and metadata in the section 1. Introduction , the urlTemplate might look like:

Example 7

"urlTemplate"
:
"http://example.org/tree/{on%2Dstreet}/{GID}"

This would generate URIs such as http://example.org/tree/ADDISON%20AV/1 and http://example.org/tree/EMERSON%20ST/2 .

Once the URI has been generated, it is resolved against the location of the resource (eg the CSV file) to create an absolute URI. For example, given a urlTemplate within a schema such as:

"urlTemplate": "#row={_row}"

and given a CSV file at http://example.com/temp.csv , the URL for the first row will be http://example.com/temp.csv#row=1 .

column reference properties

These hold one or more references to other column description objects. The referenced description object must have an @id property whose value looks like _: name . Internal property. Column reference properties can then reference other column description objects through values that are:

• strings — in the format _: name � which MUST match the @id name on another a column description object within the metadata document
• arrays — � lists of strings as above

For example, the primaryKey property is an internal column reference property on the schema. It has to hold references to columns defined elsewhere in the schema, and the descriptions of those columns must have @id name properties. It can hold a single reference, like this:

Example 8

"schema": {
  "columns": [{
    "name": "GID"
  }, ... ],
  "primaryKey": "GID"


}

or it can contain an array of references, like this:

Example 9

"schema": {
  "columns": [{
    "name": "givenName"
  }, {
    "name": "familyName"
  }, ... ],
  "primaryKey": [ "givenName", "familyName" ]


}

object properties

These hold one or more objects or references to objects by URL. Their values may be:

• strings — � resolved as URLs against the base URL
• objects — � interpreted as structured objects
• arrays — � lists of strings and/or objects, interpreted as URLs or structured objects

Object properties are often used when the values can be or should be values within controlled vocabularies, or structured information which may be held elsewhere. For example, the creator dc:creator of a table is should be an object property. It could be provided as a URL that indicates the creator, like this:

Example 8 10

"creator"

"dc:creator"


:




"http://ons.gov.uk"

or a structured object, like this:

Example 11

"dc:creator": {
  "sch:name": "Office of National Statistics",
  "sch:url": "http://ons.gov.uk",
  "sch:email": "info@ons.gsi.gov.uk"


}

or an array of URLs, like this:

Example 12

"dc:creator"
:
[

"http://ons.gov.uk"
,
"https://www.gov.uk/government/organisations/department-for-transport"

]

or an array of structured objects:

Example 13

"dc:creator": [{
  "sch:name": "Office of National Statistics",
  "sch:url": "http://ons.gov.uk",
  "sch:email": "info@ons.gsi.gov.uk"
}, {
  "sch:name": "Department for Transport",
  "sch:url": "https://www.gov.uk/government/organisations/department-for-transport"

}]

or an array that mixes URLs and objects:

Example 14

"dc:creator": [{
  "sch:name": "Office of National Statistics",
  "sch:url": "http://ons.gov.uk",
  "sch:email": "info@ons.gsi.gov.uk"

},

"https://www.gov.uk/government/organisations/department-for-transport"

]

natural language properties

These hold natural language strings. Their values may be:

• strings — � interpreted as natural language strings in the default language
• arrays — � interpreted as alternative natural language strings in the default language
• objects whose properties MUST be language codes as defined by [ RFC3066 BCP47 ] and whose values are either strings or arrays, providing natural language strings in that language

Natural language properties are used for things like descriptions and titles. For example, the title property provides a natural language label for a column. If it's a plain string like this:

Example 10 15

"title"

:




"Project
title"

then that string is assumed to be in the language provided through the @language property of the nearest @context (or have no assumed language, if there is no such property). Multiple alternative values can be given in an array:

Example 16

"title": [
  "Project title",
  "Project"


]

It's also possible to provide multiple values in different languages, using an object structure. For example:

Example 17

"title": {
  "en": "Project title",
  "fr": "Titre du projet"


}

and within such an object, the values of the properties can themselves be arrays:

Example 18

"title": {
  "en": [ "Project title", "Project" ],
  "fr": "Titre du projet"


}

Issue 5 49

We invite comment on whether it would be useful to enable some markup in natural language strings, for example by stating that they are interpreted as HTML or Markdown.

atomic properties

These hold atomic values. Their values may be:

• numbers — � interpreted as integers or doubles
• booleans — � interpreted as booleans ( true or false )
• strings — � interpreted as defined by the property
• arrays — � lists of numbers, booleans or strings

Note

JSON does not have date or time types. Where a property takes a date as a value, this MUST be a string in the format YYYY-MM-DD .

3.2 Top-Level Properties

The top-level object (whether it is a table group description or a table description ) MAY have a @context property. This holds an object that provides metadata for interpreting other properties, namely:

@language

indicates the default language for the values of properties in the description; metadata document; if present, its value MUST be a language code [ RFC3066 BCP47 ] which is the default language for the values of other properties in the metadata document

Note

Note that the @language property of the @context object, which gives the default language used within the metadata file, is distinct from the language property on a description object , which gives the language used in the data within the table. a group of tables, table or column.

@base

indicates the base URL against which other URLs within the description are resolved; if present, its value MUST be a URL which is resolved against the base URL location of the metadata document (the location from which it was retrieved) to provide the base URL for other URLs in the metadata document; if unspecified, the base URL used for interpreting relative URLs within the metadata document is the location of the metadata document itself

Note

Note that the @base property of the @context object provides the base URL used for URLs within the metadata document, not the URLs that appear within the table. group of tables or table it describes.

dates in the format YYYY-MM-DD 3.3 Common Properties

Descriptions of groups of tables, tables, schemas, columns, rows and cells MAY contain any properties whose names are either absolute URLs or prefixed names. For example, a table description may contain isVersionOf dc:description , dcat:keyword link property or language schema:copyrightHolder atomic property properties to provide a language code description, keywords or the name of the copyright holder, as defined by in Dublin Core Terms , DCAT or schema.org .

The same prefixes are pre-defined as for [ RFC3066 rdfa-core ]; this is an inherited property license object property ] within the RDFa 1.1 Initial Context and MUST NOT be overridden. Properties from other vocabularies MUST be defined using full URLs.

3.4 Table Groups

A table group description is a JSON object property that describes a group of tables.

text-direction One of "rtl" or "ltr" (the default). Indicates whether the text within cells should be displayed by default as left-to-right or right-to-left text. See section 2.2.1 3.5 Bidirectional Tables for more details. 3.4 Tables

A table description is a JSON object that describes a table within a CSV file.

3.6 Dialect Descriptions

Much of the tabular data that is published on the web is messy, and CSV parsers frequently need to other related tables, be configured in order to correctly read in CSV. A dialect description provides hints to parsers about how to parse the file linked to from the @id property. It can have any of the following common properties are particularly suitable for tables: properties, which relate to the flags described in Section 5 Parsing Tabular Data within [ tabular-data-model ]:

created encoding

An atomic property that sets the encoding flag to the single provided string value, which MUST be a defined [ encoding ].

creator lineTerminator

An atomic property that sets the line terminator flag to the single provided string value.

description quoteChar

An atomic property that sets the quote character flag to the single provided value, which MUST be a single character.

language doubleQuote

A single boolean atomic property that, if true , sets the escape character flag to " . If false , to \ .

license skipRows

An atomic property that sets the skip rows flag to the single provided numeric value, which MUST be a non-negative integer.

modified commentPrefix

An atomic property that sets the comment prefix flag to the single provided value, which MUST be a single character string.

provenance header

A single boolean atomic property that, if true , sets the header row count flag to 1 , and if false to 0 , unless publisher headerRowCount is provided, in which case the value provided for the header property is ignored.

rights headerRowCount

An atomic property that sets the header row count flag to the single provided value, which MUST be a non-negative integer.

rightsHolder delimiter

An atomic property that sets the delimiter flag to the single provided value, which MUST be a single character string.

source skipColumns

An atomic property that sets the skip columns flag to the single provided numeric value, which MUST be a non-negative integer.

spatial headerColumnCount

An atomic property that sets the header column count flag to the single provided value, which MUST be non-negative integer.

subject skipBlankRows

An atomic property that sets the skip blank rows flag to the single provided boolean value.

temporal skipInitialSpace

A single boolean atomic property that, if true , sets the trim flag to "start" . If false , to false . If the trim property is provided, the skipInitialSpace property is ignored.

trim

A single atomic property that, if the boolean true , sets the trim flag to true and if the boolean false to false . If the value provided is a string, sets the trim flag to the provided value, which MUST be one of "true" , "false" , "start" or "end" .

@type

If included, @type MUST be set to "Dialect" . Publishers MAY include this to provide additional information to JSON-LD based toolchains.

{

  "encoding": "utf-8",
  "lineTerminator": "\r\n",
  "quoteChar": "\"",
  "doubleQuote": true,
  "skipRows": 0,
  "header": true,
  "headerRowCount": 1,
  "delimiter": ",",
  "skipColumns": 0,
  "headerColumnCount": 0,
  "skipBlankRows": false,
  "skipInitialSpace": false,
  "trim": false
}

3.7 Template Specifications

A template specification is a definition of how tabular data can be transformed into another format. It has the following properties:

{

  "title": "iCalendar",
  "targetFormat": "http://www.iana.org/assignments/media-types/text/calendar",
  "templateFormat": "https://mustache.github.io/",
  "source": "json"
}

3.5 3.8 Schemas

A schema is a definition of a tabular format that may be common to multiple tables. For example, multiple tables from different sources may have the same columns and be designed such that they can be aggregated together.

A schema description is a JSON object that encodes the information about a schema. All the properties of a schema description are optional.

@type If included, @type MUST be set to "Schema" . Publishers MAY include this to provide additional information to JSON-LD based toolchains.

columns

An array property of column descriptions as described in section 3.6 3.9 Columns . These are matched to columns in table tables that use the schema by position: the first column description in the array applies to the first column in the table, the second to the second and so on.

The name properties of the column descriptions MUST be unique within a given table description.

rows

An When an array of row column descriptions as described in section 3.7 Rows . These are matched to row by the value B is imported into an original array of column descriptions A, each column description within B is combined into the row in the row description. The values of original array A by:

• if there is a column description at the row properties MUST be unique same index within a given table A and that column description (ie no row can have more than one description). has the same cells An array of cell descriptions as described in section 3.8 Cells . These are matched to cell by name , the value of column description from B is imported into the row and matching column properties description in A
• otherwise, the cell description. The combination of values of the row and column properties MUST be unique within a given table description (ie no cell can have more than one description). is ignored

primaryKey

An internal A column reference property that holds either a single references reference to a column description object or an array of references.

Validators MUST check that each row has a unique combination of cells in the indicated columns. For example, if primaryKey is set to ["_:familyName", "_:givenName"] ["familyName", "givenName"] then every row must have a unique value for the combination of the familyName and givenName columns.

Issue 11 66

When referencing columns for a Composite primary key, it keys and foreign key references.

foreignKeys

An array property of foreign key definitions that define how the values from specified columns within this table link to rows within this table or other tables. A foreign key definition is a lot clearer to JSON object with the properties:

columns

A column reference property that holds either a single reference them by name rather than by number. For JSON-LD compatibility, we have to assign a blank node column description object within this schema, or an array of references.

reference

An object with the properties:

resource

A link property holding a URL that is the identifier for a specific resource that is being referenced. If this is present then schema MUST NOT be present. The metadata document MUST contain a description of the resource.

schema

A link property holding a URL that is the identifier for a schema that is being referenced. If this is present then resource MUST NOT be present. The metadata document that forms the basis of processing MUST contain a description of a resource that uses the referenced schema, and there MUST NOT be more than one such resource.

columns

A column reference property that holds either a single reference to each a column even though they each description object within this schema, or an array of references.

Note

It is not required for the resource or schema referenced from a foreignKeys property to have a similarly defined name primaryKey .

When an array of foreign key definitions B is imported into an original array of foreign key definitions A, each foreign key definition within B which does not appear within A is appended to the original array A.

Issue 16

The cross reference between files should be limited to files from one publisher - else they are just web links with no guarantee of whether the target of the link exists which 'foreign key' might imply.

urlTemplate

A URI template property that could MAY be used instead. We invite comment on how to make this easier create a unique identifier for people each row when mapping data to use while maintaining JSON-LD compatibility. other formats.

@type

If included, @type MUST be set to "Schema" . Publishers MAY include this to provide additional information to JSON-LD based toolchains.

The description MAY contain any of the common properties as defined in section 3.3 Common Properties to describe provide extra metadata about the schema. As well schema as links to other related schemas, a whole.

The description MAY contain any of the following common inherited properties are particularly suitable defined for schemas: cells in section 2.2 Inherited Properties .

countryCode,latitude,longitude,name

AD,42.546245,1.601554,Andorra
AE,23.424076,53.847818,"United Arab Emirates"
AF

,

license


33.93911

,


67.709953
,

Afghanistan

countryRef,year,population

AF,1960,9616353
AF,1961,9799379
AF

,


1962

,


9989846

{
  "@context": "http://www.w3.org/ns/csvw",
  "resources": [{
    "@id": "https://example.org/countries.csv",
    "schema": {
      "columns": [{
        "name": "countryCode",
        "datatype": "string"
      }, {
        "name": "latitude",
        "datatype": "number"
      }, {
        "name": "longitude",
        "datatype": "number"
      }, {
        "name": "name",
        "datatype": "string"
      }],
      "urlTemplate": "http://example.org/countries.csv{#countryCode}",
      "primaryKey": "countryCode"
    }
  }, {
    "@id": "http://example.com/country_slice.csv",
    "schema": {
      "columns": [{
        "name": "countryRef",
        "datatype": "string"
      }, {
        "name": "year",
        "datatype": "gYear"
      }, {
        "name": "population",
        "datatype": "integer"
      }],
      "foreignKeys": [{
        "columns": "countryRef",
        "reference": {
          "resource": "http://example.org/countries.csv",
          "columns": "countryCode"
        }
      }]
    }
  }]


}

Post Unique Reference,              Name,Grade,             Job Title,Reports to Senior Post

                90115,        Steve Egan,SCS1A,Deputy Chief Executive,                 90334
                90250,     David Sweeney,SCS1A,              Director,                 90334
                90284,       Heather Fry,SCS1A,              Director,                 90334
90334,Sir
Alan
Langlands,
SCS4,
Chief
Executive,
xx

Reporting Senior Post,Grade,Payscale Minimum (�),Payscale Maximum (�),Generic Job Title,Number of Posts in FTE,          Profession

                90284,    4,               17426,               20002,    Administrator,                     2,Operational Delivery
                90284,    5,               19546,               22478,    Administrator,                     1,Operational Delivery
                90115,    4,               17426,               20002,    Administrator,                  8.67,Operational Delivery
90115,
5,
19546,
22478,
Administrator,
0.5,Operational
Delivery

{
  "@context": "http://www.w3.org/ns/csvw",
  "resources": [{
    "@id": "HEFCE_organogram_senior_data_31032011.csv",
    "schema": "http://example.org/schema/senior-roles.json"
  }, {
    "@id": "HEFCE_organogram_junior_data_31032011.csv",
    "schema": "http://example.org/schema/junior-roles.json"
  }]


}

{
  "@context": "http://www.w3.org/ns/csvw",
  "@id": "http://example.org/schema/senior-roles.json",
  "columns": [{
    "name": "ref",
    "title": "Post Unique Reference"
  }, {
    "name": "name",
    "title": "Name"
  }, {
    "name": "grade",
    "title": "Grade"
  }, {
    "name": "job",
    "title": "Job Title"
  }, {
    "name": "reportsTo",
    "title": "Reports to Senior Post"
  }],
  "primaryKey": "ref",
  "urlTemplate": "#post-{ref}",
  "foreignKeys": [{
    "columns": "reportsTo",
    "reference": {
      "schema": "http://example.org/schema/senior-roles.json",
      "columns": "ref"
    }
  }]


}

{
  "@context": "http://www.w3.org/ns/csvw",
  "@id": "http://example.org/schema/junior-roles.json",
  "columns": [{
    "name": "reportsTo",
    "title": "Reporting Senior Post"
  }, 
  ...
  ],
  "foreignKeys": [{
    "columns": "reportsTo",
    "reference": {
      "schema": "http://example.org/schema/senior-roles.json",
      "columns": "ref"
    }
  }]


}

3.6 3.9 Columns

A column description is a simple JSON object that describes a single column. The description provides additional human-readable documentation for a column, as well as additional information that may be used to validate the cells within the column, create a user interface for data entry, or inform conversion into other formats.

3.8.3 3.10 Inherited Properties

Cell descriptions may override inherited properties , as described in section 2.1 2. Annotating Tables . It is good practice to define these properties on columns, so that all cells within a given column are handled in the same way. way, or on tables if appropriate. These properties are:

null

The An atomic property giving the string or strings used for null values. If not specified, the default for this is the empty string.

language

An atomic property giving a single string language code as defined by [ BCP47 ]. Indicates the language of the value within the cell.

text-direction

An atomic property that MUST have a single string value that is one of "rtl" or "ltr" (the default). Indicates whether the text within cells should be displayed by default as left-to-right or right-to-left text. See section 4.1.1 Bidirectional Tables for more details.

separator

The An atomic property that MUST have a single string value that is the character used to separate items in the string value of the cell. If null , or unspecified, the cell does not contain a list. Otherwise, application MUST split the string value of the cell on the specified separator character and parse each of the resulting strings separately. The cell's value will then be a list. Conversion specifications MUST use the separator to determine the conversion of a cell into the target format. See 3.8.5 3.12 Parsing cells for more details.

default

An atomic property holding a single string that provides a default string value for the cell in cases where the original string value is a null value. This default value MAY be used when converting the table into other formats.

format

A An atomic property that contains a single string that is the definition of the format of the cell, used when parsing the cell as described in 3.8.5 3.12 Parsing cells .

datatype

The An atomic property that contains a single string that is the main datatype of the values of the cell. If the cell contains a list (ie separator is specified and not null ) then this is the datatype of each value within the list. Conversion specifications MUST use the datatype of the value to determine the conversion of a cell into the target format. See 3.8.4 3.11 Datatypes for more details.

length

The An atomic property that contains a single integer that is the exact length of the value of the cell. See section 3.8.4.1 3.11.1 Length Constraints for details.

minLength

The An atomic property that contains a single integer that is the minimum length of the value of the cell. See section 3.8.4.1 3.11.1 Length Constraints for details.

maxLength

The An atomic property that contains a single integer that is the maximum length of the value of the cell. See section 3.8.4.1 3.11.1 Length Constraints for details.

minimum

The An atomic property that contains a single number that is the minimum value for the cell (inclusive); equivalent to minInclusive . See section 3.8.4.2 3.11.2 Value Constraints for details.

maximum

The An atomic property that contains a single number that is the maximum value for the cell (inclusive); equivalent to maxInclusive . See section 3.8.4.2 3.11.2 Value Constraints for details.

minInclusive

The An atomic property that contains a single number that is the minimum value for the cell (inclusive). See section 3.8.4.2 3.11.2 Value Constraints for details.

maxInclusive

The An atomic property that contains a single number that is the maximum value for the cell (inclusive). See section 3.8.4.2 3.11.2 Value Constraints for details.

minExclusive

The An atomic property that contains a single number that is the minimum value for the cell (exclusive). See section 3.8.4.2 3.11.2 Value Constraints for details.

maxExclusive

The An atomic property that contains a single number that is the maximum value for the cell (exclusive). See section 3.8.4.2 3.11.2 Value Constraints for details.

3.8.4 3.11 Datatypes

Cells within tables may be annotated with a datatype which indicates the type of the value obtained by parsing the value of the cell. The format expected in the cell is determined by the format annotation, if there is one, or uses a default format determined by the type.

The possible datatypes are:

• the datatypes defined in [ xmlschema-2 ] with the exception of those that rely on XML mechanisms for definition, namely:

  • anySimpleType
  • string ; a sub-value of anySimpleType
  • normalizedString ; a sub-value of string
  • token ; a sub-value of normalizedString
  • language ; a sub-value of token
  • Name ; a sub-value of token
  • NCName ; a sub-value of Name
  • boolean ; a sub-value of anySimpleType
  • decimal ; a sub-value of anySimpleType
  • integer ; a sub-value of decimal
  • nonPositiveInteger ; a sub-value of integer
  • negativeInteger ; a sub-value of nonPositiveInteger
  • long ; a sub-value of integer
  • int ; a sub-value of long
  • short ; a sub-value of int
  • byte ; a sub-value of short
  • nonNegativeInteger ; a sub-value of integer
  • unsignedLong ; a sub-value of nonNegativeInteger
  • unsignedInt ; a sub-value of unsignedLong
  • unsignedShort ; a sub-value of unsignedInt
  • unsignedByte ; a sub-value of unsignedShort
  • positiveInteger ; a sub-value of nonNegativeInteger
  • float ; a sub-value of anySimpleType
  • double ; a sub-value of anySimpleType
  • duration ; a sub-value of anySimpleType
  • dateTime ; a sub-value of anySimpleType
  • time ; a sub-value of anySimpleType
  • date ; a sub-value of anySimpleType
  • gYearMonth ; a sub-value of anySimpleType
  • gYear ; a sub-value of anySimpleType
  • gMonthDay ; a sub-value of anySimpleType
  • gDay ; a sub-value of anySimpleType
  • gMonth ; a sub-value of anySimpleType
  • hexBinary ; a sub-value of anySimpleType
  • base64Binary ; a sub-value of anySimpleType
  • anyURI ; a sub-value of anySimpleType
• the datatype number which is exactly equivalent to double
• the datatype binary which is exactly equivalent to base64Binary
• the datatype datetime which is exactly equivalent to dateTime
• the datatype geopoint any which indicates a comma-separated longitude and latitude (ie values that after stripping leading and trailing whitespace are in the format longitude \s*,\s* latitude ); a sub-value of is exactly equivalent to anySimpleType Issue 13 In JSON Table Schema, geopoint permits values in JSON representations of points, namely { lon: longitude , lat: latitude } and [ longitude , latitude ] . We invite comment about whether these types are suitable for CSV files. If they are, we suggest that these additional formats for geopoint are supported through the format property.
• the datatype any xml which is exactly equivalent to anySimpleType indicates the cell contains an XML fragment
Issue 14 The JSON Table Schema also includes object ,
• the datatype array html and geojson . We invite comment on whether we should we support which indicates the inclusion of JSON-based structures within CSV files. Issue 15 We invite comment on whether cell contains an HTML fragment
• the datatype any json type is useful. Issue 16 We invite comment on whether there should be types for formats like XML, HTML and markdown which may appear within CSV cells. indicates the cell contains serialized JSON

3.8.5 3.12 Parsing cells

Unlike many other data formats, tabular data is designed to be read by humans. For that reason, it's common for data to be represented within tabular data in a human-readable way. The separator and format properties indicates the format used to represent data within the table. This is used:

• by validators to check that the data in the table is in the expected format
• by converters to parse the values before mapping them into values in the target of the conversion
• when displaying data, to map it into formats that are meaningful for those viewing the data (as opposed to those publishing it)
• when inputting data, to turn entered values into representations in a consistent format

The process of parsing the string value of a cell into a single value or a list of values is as follows:

1. unless the datatype is string or anySimpleType or any , strip leading and trailing whitespace from the value
2. if the value is the same as the null value, then the value is null
3. if the separator property is not null , create a list of values by splitting the string at the character specified by the separator property
4. validate the value(s) against the format , if one is specified, as described below; raise an error if any of the values do not match the specified format
5. parse the value(s) using the format , as described below

4.1 Displaying Tables

4.2 Validating Tables

4.3 Converting Tables

Conversions of tabular data to other formats operate over a minimum value constraint is specified then the cell descriptor annotated table constructed as defined in section 2. Annotating Tables . The mechanics of these conversions to other formats are defined in other specifications.

Conversion specifications MUST contain define a default mapping from an annotated table that lacks any annotations (ie that is equivalent to an un-annotated table).

Conversion specifications MUST use either the type name key or the maximum predicateUrl – as above, but specifies of a maximum value column as the basis for a cell. naming machine-readable fields in the target format, such as the name of the equivalent element or attribute in XML, property in JSON or property URI in RDF.

A constraints descriptor may contain multiple constraints, Conversion specifications MAY use any of the properties defined in this specification to adjust the mapping of an annotated table into another format.

Conversion specifications MAY define additional properties, not defined in this specification, which case are specifically used when converting to the target format of the conversion. For example, a conversion to XML might specify a consumer MUST element-or-attribute apply all the constraints when determining if property on columns that determines whether a cell value particular column is valid. represented through an element or an attribute in the data.

A data file, e.g. an entry Conversion specifications SHOULD specify format-specific properties specifying external processing steps to provide more control to people defining conversions. If these are specified, the conversion specification MUST specify at what point in a data package, the processing this external processing takes place, and what it takes place on. Examples might be:

• the URL of an XSLT file that is considered used to be valid if all process XML after it is generated
• a string containing a SPARQL CONSTRUCT pattern that is executed on RDF after it is generated
• properties that contain definitions of its cells Javascript callback functions that are valid according to their declared type and constraints . used when processing particular columns or individual rows