The Metadata Community — Supporting Innovation in Metadata Design, Implementation & Best Practices | |||||||

Global navigation options: |

Creator: | Simon Cox |
---|---|

Contributor: | Andy Powell |

Contributor: | Andrew Wilson |

Contributor: | Pete Johnston |

Date Issued: | 2006-04-10 |

Identifier: | http://dublincore.org/documents/2006/04/10/dcmi-box/ |

Replaces: | http://dublincore.org/documents/2000/07/28/dcmi-box/ |

Is Replaced By: | Not Applicable |

Latest version: | http://dublincore.org/documents/dcmi-box/ |

Status of document: | This is a DCMI Recommendation. |

Description of document: | The DCMI Box encoding scheme is a method for identifying a
region of space using its geographic limits and representing
that information as a value string. Components of the value
string correspond to the bounding coordinates in north, south,
east and west directions, plus optionally up and down, and
also allow the coordinate system and units to be specified,
and a name if desired. A method for encoding DCMI Box in a
text string using the DCSV syntax is described. This notation
is intended for representing a value of the DCMES element
Coverage, particularly when using HTML meta
elements. |

Revision note: | 2006-04-10. After approval of the DCMI Abstract Model [DCAM] as a DCMI Recommendation in March 2005, the DCMI Usage Board undertook a review of the DCSV syntax specification and of the related specifications for the encoding schemes DCMI Box, DCMI Point, and DCMI Period, with the goal of revising their language for conformance with the Abstract Model. A summary of the changes made can be found in the document "Revision of DCSV specifications". As of 2005, the DCMI Abstract Model supports the construct "related description" as a method for describing value entities such as a persons or, indeed, time periods or locations in space. The DCMI Usage Board encourages implementers to consider using related descriptions as an alternative to packaging descriptive information in DCSV-encoded strings. Descriptions based on the DCMI Abstract Model are more likely to be interoperable over the longer term than descriptions using DCSV-syntax-based specifications. |

- 1. Introduction
- 2. Identifying a place - the DCMI Box scheme
- 3. Encoding DCMI Box with DCSV syntax
- 4. Examples
- 5. References

Several methods are available to indicate a place. These include, but are not limited to:

- a
**name**, normally defined in an identifiable enumeration such as a gazetteer or list of jurisdictional localities; - a unique
**geocode**, such as a postal code; - the coordinates of a
**point**, using geographic values or some well-defined projection and units; - a set of arcs or faces describing the
**polygon**or**polyhedron**comprising the perimeter of the place; - the
**limits**of a regular shaped container which encompasses the place, typically a rectangular**box**in two or three dimensions, using geographic values or some well-defined projection and units.

The Dublin Core Metadata Element Set [DCMES] includes an element,
**Coverage**, the value of which may be a
place. If a name or geocode is used as the value representation
for the property, then the enumeration from which that is
selected determines valid value strings. However, there are
no simple, commonly used, notations for indicating a place
using coordinates. Here we define DCMI Box, an encoding
scheme which specifies the geographic limits of a place,
and describe a method for encoding DCMI Box in a text string
using the DCSV syntax [DCSV].

In the simplest usage, DCMI Box approximates the extent of
a place using a container with a regular shape. For a more
precise representation of an irregular shape it is possible
to use the approach of "tiling" the place with a
set of simple regions defined using DCMI Box. Alternatively,
another notation describing a polygon or polyhedron may
be used. If a value corresponding to a *point* is
required, then DCMI Point [POINT] is
available.

We identify a place by considering the minimal rectangular box which fully encloses the place, whose faces are aligned parallel with the axes of an identified cartesian coordinate system [Figure].

We define the following components to describe the box:

Component Label | Definition | Default Component Value^{1} |
---|---|---|

northlimit | The constant coordinate for the northernmost face or edge^{2} |
INF^{3} |

eastlimit | The constant coordinate for the easternmost face or edge^{2} |
INF^{3} |

southlimit | The constant coordinate for the southernmost face or edge^{2} |
-INF^{3} |

westlimit | The constant coordinate for the westernmost face or edge^{2} |
-INF^{3} |

uplimit | The constant coordinate for the uppermost face or edge^{2} |
INF^{3} |

downlimit | The constant coordinate for the lowermost face or edge^{2} |
-INF^{3} |

units | The units applying to unlabelled numeric values of northlimit, eastlimit, southlimit, westlimit | signed decimal degrees |

zunits | The units applying to unlabelled numeric values of uplimit, downlimit | metres |

projection | The name of the projection used with any parameters required, such as ellipsoid parameters, datum, standard parallels and meridians, zone, etc | geographic coordinates on Earth for northlimit, eastlimit, southlimit, westlimit; height above mean-sea-level for uplimit, downlimit |

name | A name for the place^{4} |
- |

^{1}*All components
are optional. If any *limit component is absent, then this
implies an interval unbounded on that side. Thus, a DCMI
Box with a single component northlimit="0" would
identify the entire southern hemisphere.*

^{2}*Component values
are text strings representing numbers. Units should be included
using conventional (SI) notation, unless the relevant units
or zunits component is present. However, if units are given
as part of any component value, then for this component these
override those given by units or zunits.*

^{3}*If this component
is absent then the value is undefined. Processors performing
numeric comparisons are recommended to set values corresponding
to maximally inclusive matching.*

^{4}*In this context
the name is non-normative. In the case of a conflict, the
place identified by the coordinate values takes precedence. The
name is provided for user convenience only.*

The components specified above have no meaning when disaggregated, since in any particular instance it is the complete set which acts to indicate the specific location. For systems in which data is encoded using a limited character set, this is conveniently accomplished by packaging the components into a single text string according to the DCSV syntax [DCSV].

A DCMI Box value string using DCSV syntax, and using the component names defined above, appears as follows:

northlimit=v1; eastlimit=v2; southlimit=v3; westlimit=v4; uplimit=v5; downlimit=v6; units=v7; zunits=v8; projection=v9; name=v10

where v1 - v10 are component values as defined in the table above.

All components are optional but must not be repeated, and their order is not significant.

**Western Australia:**

name=Western Australia; northlimit=-13.5; southlimit=-35.5; westlimit=112.5; eastlimit=129

**Lake Jindabyne:**

northlimit=5980000; westlimit=644000; eastlimit=647000; southlimit=5966000; units=m; projection=UTM zone 55 south

**The Western Hemisphere:**

westlimit=180; eastlimit=0

**The Tropics:**

northlimit=23.5; southlimit=-23.5

**A mine, illustrating the use of 3-D coordinates:**

northlimit=-21.3; southlimit=-21.4; westlimit=139.8; eastlimit=139.9; uplimit=400; downlimit=-100; name=Duchess copper mine

**[DCMES]**

Dublin Core Metadata Element Set,
Version 1.1: Reference Description,

http://dublincore.org/documents/dces/.

**[POINT]**

DCMI Point Encoding Scheme,

http://dublincore.org/documents/dcmi-point/.

**[DCSV]**

DCMI DCSV: A syntax for representing simple
structured data in a text string,

http://dublincore.org/documents/dcmi-dcsv/.

Copyright © 1995-2014 DCMI. All Rights Reserved.