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.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.10 Inherited Properties. To ascertain a value for these annotations, an application MUST identify the relevant property in the descriptions of the table or column.

Applications MUST raise an error if the value of a property in a table description is not compatible with the value of that property on the group of tables. Applications MUST raise an error if the value of a property in a column description is not compatible with the value of that property on the table. Applications MUST raise an error if the value of a property on a cell is not compatible with the values of that property on the column that the cell is associated with.

A value for a cell, column or table is compatible with with a value on a 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 dc:hasVersion property is a link property. A table description might contain:

Example 4

"dc:hasVersion": "example-2014-01-03.csv"

in which case the dc:hasVersion property on the table would have a single value, a link to example-2014-01-03.csv. 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 dc:hasVersion property on the table would be an array of three values, links to other versions of the table.

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": "https://example.org/example.csv#row={_row}"

The identifiers that are generated for the rows would then look like https://example.org/example.csv#row=1, https://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": "https://example.org/tree/{on%2Dstreet}/{GID}"

This would generate URIs such as https://example.org/tree/ADDISON%20AV/1 and https://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 https://example.com/temp.csv, the URL for the first row will be https://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 name property. Column reference properties can then reference column description objects through values that are:

• strings — which MUST match the name on a column description object within the metadata document
• arrays — lists of strings as above

For example, the primaryKey property is an 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 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 dc:creator of a table should be an object property. It could be provided as a URL that indicates the creator, like this:

Example 10

"dc:creator": "https://ons.gov.uk"

or a structured object, like this:

Example 11

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

or an array of URLs, like this:

Example 12

"dc:creator": [ "https://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": "https://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": "https://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 [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 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 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 metadata document; if present, its value MUST be a language code [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 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 location of the metadata document 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 group of tables or table it describes.

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 dc:description, dcat:keyword or schema:copyrightHolder properties to provide a description, keywords or the name of the copyright holder, as defined in Dublin Core Terms, DCAT or schema.org.

The same prefixes are pre-defined as for [rdfa-core] 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 that describes a group of tables.

3.5 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 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 properties, which relate to the flags described in Section 5 Parsing Tabular Data within [tabular-data-model]:

encoding

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

lineTerminator

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

quoteChar

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

doubleQuote

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

skipRows

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

commentPrefix

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

header

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

headerRowCount

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

delimiter

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

skipColumns

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

headerColumnCount

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

skipBlankRows

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

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": "https://www.iana.org/assignments/media-types/text/calendar",
  "templateFormat": "carview.php?tsp=https://mustache.github.io/",
  "source": "json"
} 

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.

columns

An array property of column descriptions as described in section 3.9 Columns. These are matched to columns in 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.

When an array of column descriptions B is imported into an original array of column descriptions A, each column description within B is combined into the original array A by:

• if there is a column description at the same index within A and that column description has the same name, the column description from B is imported into the matching column description in A
• otherwise, the column description is ignored

primaryKey

A column reference property that holds either a single 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"] then every row must have a unique value for the combination of the familyName and givenName columns.

Issue 66

Composite primary 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 JSON object with the properties:

columns

A column reference property that holds either a single reference to a 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 a column 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 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 MAY be used to create a unique identifier for each row when mapping data to 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 common properties as defined in section 3.3 Common Properties to provide extra metadata about the schema as a whole.

The description MAY contain any of the inherited properties defined for 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,33.93911,67.709953,Afghanistan

countryRef,year,population
AF,1960,9616353
AF,1961,9799379
AF,1962,9989846

{
  "@context": "https://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": "https://example.org/countries.csv{#countryCode}",
      "primaryKey": "countryCode"
    }
  }, {
    "@id": "https://example.com/country_slice.csv",
    "schema": {
      "columns": [{
        "name": "countryRef",
        "datatype": "string"
      }, {
        "name": "year",
        "datatype": "gYear"
      }, {
        "name": "population",
        "datatype": "integer"
      }],
      "foreignKeys": [{
        "columns": "countryRef",
        "reference": {
          "resource": "https://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": "https://www.w3.org/ns/csvw",
  "resources": [{
    "@id": "HEFCE_organogram_senior_data_31032011.csv",
    "schema": "https://example.org/schema/senior-roles.json"
  }, {
    "@id": "HEFCE_organogram_junior_data_31032011.csv",
    "schema": "https://example.org/schema/junior-roles.json"
  }]
}

{
  "@context": "https://www.w3.org/ns/csvw",
  "@id": "https://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": "https://example.org/schema/senior-roles.json",
      "columns": "ref"
    }
  }]
}

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

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.10 Inherited Properties

Cell descriptions may override inherited properties, as described in section 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, or on tables if appropriate. These properties are:

null

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

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.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

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.12 Parsing cells.

datatype

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.11 Datatypes for more details.

length

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

minLength

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

maxLength

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

minimum

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

maximum

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

minInclusive

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

maxInclusive

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

minExclusive

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

maxExclusive

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

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 any which is exactly equivalent to anySimpleType
• the datatype xml which indicates the cell contains an XML fragment
• the datatype html which indicates the cell contains an HTML fragment
• the datatype json which indicates the cell contains serialized JSON

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 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 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 name or the predicateUrl of a column as the basis for 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.

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 are specifically used when converting to the target format of the conversion. For example, a conversion to XML might specify a element-or-attribute property on columns that determines whether a particular column is represented through an element or an attribute in the data.

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 the processing this external processing takes place, and what it takes place on. Examples might be:

• the URL of an XSLT file that is used to 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 Javascript callback functions that are used when processing particular columns or individual rows