1

Title
Creator
GISCO Reference Geodatabase Naming Conventions
C ésar de Diego Díez, Albrecht Wirthmann
1
1.1
2.0
2.1
Date last revision 2006-10-09
Subject
Status
Type
Publisher
Naming conventions for objects in the reference GISCO geodatabase
Ongoing
EUROSTAT
Description
Format
Source
Contributors
Text
Naming conventions for GISCO reference geodatabase
-
MS Word 95/2000 (doc)
Rights
Identifier
Language
Relation
Coverage
Not applicable
Public domain.
Naming Conventions v2.0
En
Not applicable
GISCO reference database lifecycle duration
RECORD OF MODIFICATIONS
Version Date Author Modified sections
2.2
2.3
13/2/2005 CDD/AW
2/6/2005 CDD
27/1/2006 CDD
2006-10-24 CDD
2008-04-28 CDD
2009-08-31 CDD
Creation
-
Revision of all chapters
Update of annex 3 "keywords" and annex 5 "class identifiers".
New convention for coded-value attributes (domains).
Revision of relationship names
Revision of attribute name "NAME"
Introduction of geometric entity "RL" for attribute tables
(i.e. tables with no geometry or "objects" according to
ESRI nomenclature) representing relational many-to-many relationships.
Text revision. "New" architecture is not "New" after 5 years.
New examples.
2

Content
GISCO database naming conventions ................................................. 4
Background ............................................................................................................................ 4
Purpose of the document ........................................................................................................ 4
General considerations: .......................................................................................................... 4
Naming conventions ............................................................................................................... 5
General rules ...................................................................................................................... 5
Feature datasets and data themes........................................................................................ 6
Feature/object class & subtypes names: ............................................................................. 7
Syntax rules .................................................................................................................... 7
Class identification ......................................................................................................... 7
Geometric entity ............................................................................................................. 8
Additional information ................................................................................................... 9
Classes that implement one-to-one relationships ........................................................... 9
Classes that implement many-to-many relationships ................................................... 11
Examples: ..................................................................................................................... 11
Attribute names ................................................................................................................ 12
Primary key ...................................................................................................................... 12
Relationship names and role names in Arc GIS (Forward/Backward path label)................ 16
Domain names ...................................................................................................................... 17
Subtype names ...................................................................................................................... 18
3

The migration of the GISCO database from a file based coverage structure to the new system architecture was an opportunity for the definition of a new database naming convention. In the
Arc workstation file system, the coverage name was limited to a maximum of 13 characters.
GISCO naming conventions were clearly defined, but they resulted into rather cryptic names due to the strict length limitations. For advanced users, it was easy to navigate through the database, whereas, beginners and occasional users could not easily find their way without constantly consulting the database manual.
After migrating to the new architecture based on ORACLE it is possible to extend the object name length and thus making these names more user-friendly. Moreover, relational databases follow a different logical structure than the coverages. Finally, new features, such as relationships or domains have been introduced. All these new opportunities and needs regarding naming convention have been tackled in this document.
To define the guidelines that will rule the naming of classes, attributes and other objects in the
GISCO Geodatabase.
The aim of the naming conventions is:
 to reflect the content and purpose of the database objects in a standardised, concise and user-friendly way;
 to reflect the logical location of the objects within the database;
 to assure uniqueness of the object name within the database.
 to facilitate the multiplatform use of the data
A sequence of abbreviations is therefore used to describe the contents of a database feature.
The codes are grouped into code lists according to their meaning. Syntax rules define the sequence and the reading of the codes. The names of features, tables and attributes are composed according to the following categories:

Topic (Data themes, feature datasets, feature classes, object classes and subtypes are named according to their topic category)

Geometric Entity (The topological type of a feature or object, e.g. region, boundary, point)
4


Scale, Accuracy, Precision

Time stamp or Version

Source
The naming conventions describe naming rules for the following database features:

Feature datasets and data themes

Feature classes, object classes and subtypes

Relationships

Domains

Attributes
Long names are self explanatory, but become uncomfortable to deal with in programs, scripts, table headings, etc. Sensible and defined abbreviations in the object names can help to the readability of documentation and programming code.
The name of the features and objects in the geodatabase is not meant to be a subset of the metadata. These names must contain the minimum information required to uniquely identify the entity (class, object, relationship, etc) they represent
The GISCO geodatabase architecture objects are hosted in different platforms:
- SDE tables and attributes: Oracle Spatial database
- Feature datasets, subtypes, domains and relationships: ArcGIS
- Data themes: abstract
General restrictions : Each platform presents different naming rules. These are not conventions, but restrictions imposed by the technological platforms. To assure as much as possible the access to the database from different platforms, we will follow the most restrictive rules for all objects, i.e. the Oracle naming rules:



Names cannot be longer than 30 characters.
Names will contain only uppercase characters (A-Z) or _ (underscore).
Oracle reserved words cannot be used as object names (see annex 2)
General conventions : These rules apply to all named objects in the geodatabase.


The name will be structured in segments.
Each segment will have a maximum of four characters. A segment will be an abbreviation or an acronym of the words that better represent the object to be named
5



When a concept name to be abbreviated already exists in the database, the same abbreviation or an acronym should be used for the same concept. See annex 3 for a list of keywords and their respective abbreviations. This annex is intended to be updated with every new database development.
Too generic words as “type” or “class” should not be used in any segment of the name. (See annex 4)
Segments will be separated by a “_” (underscore) 
On top of these rules, particular conventions are to be applied to the different objects in the geodatabase
Alphanumeric data (object classes) and geometry (feature classes) will be conceptually grouped in data themes. This concept does not make part of the geodatabase structure , neither in the Oracle DBMS nor in ArcCatalog .
A feature dataset is a collection of related feature classes, all of which share a common spatial reference system. These collections are recognised only by ArcGIS software.
Most features in the GISCO database will share the same reference system. In consequence they could share the same feature dataset. Nevertheless this approach makes very difficult to find a feature class browsing the ArcGIS catalog. For readability reasons each conceptual data theme will be implemented at least as one separated feature dataset.
The first step to define the names of the different objects in the data theme is to identify the real world concept modelled in the data theme. The data theme name can be as long as desired. It represents an abstract concept and it is not bound to the limitation of name length in databases.
Every data theme will have associated a short name. The short name will have a maximum of
4 characters
. The generic words “area”, “zones”, “location”, “patterns” etc will be disregarded when choosing the short name. Feature datasets (FDS) will be named after the short name of the data theme that they implement.
Again for readability sake, different versions of a given data theme can be implemented in different feature datsets. In this case a version or date segment will be included in the feature dataset name
Examples: data theme (long name)
Territorial Units for Statistics (NUTS + Statistical Regions)
Communes
Transports
Urban Audit Areas
FDS name
NUTS_2003
NUTS_2006
COMM_2004
COMM_2006
TRAN_V2
TRAN_V3
URAU_2004
Airports
A data theme will comprise at least one feature class or object class.
AIRP
6

Syntax rules
The information that will make part of the class name must be exclusively the information needed to uniquely identify the class we want to name. For this purpose we might need to include in the name (or not, depending on the data model) a segment to identify the version, scale, time stamp or source.
The class name (either geometry or just tabular data) will be built up by adding the following strings (segments), in this order:


Data theme short name (compulsory)
Class identification short name (If needed)


Geometric entity (compulsory)
Scale or precision: 100K, 1M, 200M (If needed)
K stands for “thousand”
M stands for “million” or “metres” (no lower case allowed)



- Version: Vxx
- Time stamp:
- Source.
(If needed)
(If applicable and needed)
(If needed)
No spaces are allowed. The different segments will be joined by a “_“ (underscore) and the total length of the name cannot exceed 30 characters.
The use of leading zeroes in the scale, version and time stamp segments should be considered in order to get a stable and logic sort of feature and object class names:
NUTS_RG_03M_2006
NUTS_RG_10M_2006
Class identification
In order to identify feature classes within a data theme, the class name may contain a class identification segment. The class identification will appear only if the data theme name and geometric entity name (defined in next paragraph) do not uniquely identify a feature or object class (See the example a few lines further).
Every class identifier will have a short name associated. This short name will have a maximum of 4 characters.
The class identification must be chosen based on concepts essential to the class. Scale or time stamps are not essential to any class. Examples:
- City: (Short name: CITY)
- Condominium: (Short name: COND)
- Custom (Short name: CUST)
7

The class identification will always be a singular noun.
Example:
The data theme “Urban Audit” models 5 different entities, hierarchically structured: Subcity
Districts (levels 1 and 2), Cities, Kernels and Large Urban Zones. Therefore the class identifications are needed:
- URAU_LUZ_RG ( Urban Audit Large Urban Zone - Multipart polygon topology)
- URAU_KERN_RG (Urban Audit Kernel – Multipart polygon topology)
- URAU_CITY_RG (Urban Audit City – Multipart polygon topology)
- URAU_CITY_PT ( Urban Audit City – Point topology)
- URAU_SCD1_RG (Urban Audit Sub-City District level 1 – Multipart polygon topology)
- URAU_SCD2_RG (Urban Audit Sub-City District level 2 – Multipart polygon topology)
Geometric entity
The geometric entity describes the type of geometric representation chosen to model a certain feature. The description of the geometric entity is mandatory. The geometric entity is abbreviated with 2 characters.
The following table lists the keywords that should be used for describing the type of geometric entity.
Short
Name
PL
Long Name Description Example
RG
BN
LI
Polygon A closed, two-dimensional figure with at Lake polygon least three sides that represents an area. It is used to describe spatial elements with a discrete area, such as parcels or political districts.
Area feature that can represent a single area NUTS regions Region feature as more than one polygon
( multipart polygons ).
Boundary Line feature separating polygon or region NUTS boundary features
Line Line feature representing a geographical entity
Rivers
NW
LB
PT
ND
AN
Network
Label
An interconnected set of lines representing possible paths from one location to another
Maritime routes
(routing aspect)
Point feature, used as reference of a polygon Centroid of NUTS
Feature modelled as point region
Settlement Point
Node End point of a line or network feature
Annotation Text feature for annotating a map
Road junctions
Ocean names
8

RT
GR
IM
AT
RL
Route
Grid
Image
Linear feature specifying a path through a network
A data format for storing raster data that Digital elevation defines geographic space as an array of model equally sized square cells arranged in rows and columns. Each cell stores a numeric value that represents a geographic attribute
(such as elevation) for that unit of space.
A raster-based representation or description Satellite image of a scene, typically produced by an optical or electronic device, such as a camera or a scanning radiometer.
Attributes Alphanumeric tabular information (without geometry) relevant to some geographical
NUTS region attributes. feature in the GeoDatabase.
Relationships Tabular definition (without geometry) of a Custom - country. many-to-many relationship.
Additional information
Additional segments are often needed in order to uniquely name a table. These additional strings might refer to the scale, precision, version or time stamp and the source.
Classes that implement one-to-one relationships
The attributes of an object class having a 1-to-1 relationship to a feature class will often be integrated in the feature class attribute table, i.e. the object class will not exist. In the following real example, the Large Urban Zone geometry and all its attributes are integrated in one single feature class:
«Multipart Polygon»
URAU_LUZ_RG_2004
+URAU_LUZ_ID : esriFieldTypeString
+CNTR_CODE : esriFieldTypeString
+LUZ_NAME : esriFieldTypeString
+NAME_ASCI : esriFieldTypeString
+NAME_HTML : esriFieldTypeString
This is not applicable when the object class has a 1-to-1 relationship to at least two feature classes (for instance, different generalisations of the same real world entity or real world entities modelled as points and polygons). In these cases redundancy should be avoided and the attributes will be either integrated in one of the feature classes or preferably separated in an object class. In this last case the name of the object class will be all the common concepts identified in the attributed feature classes. For instance:
9

STTL_V3: Settlements
STTL_PT_V3
«Primary key» +STTL_ID : string
+CNTR_CODE
+POPL_SIZE : long
+POPL_LORN : long
+POPL_UPRN : long
+ALT_AVRG : long
+NAME : string
+NAME_ASCI : string
+LANG_CODE : LANG_DOM
-MIN_SCAL : long
1
1
0..1
STTL_RG_01M_V3
«Primary key» +STTL_ID : string
+CNTR_CODE
+POPL_SIZE : long
+POPL_LORN : long
+POPL_UPRN : long
+ALT_AVRG : long
+NAME : string
+NAME_ASCI : string
+LANG_CODE : LANG_DOM
-MIN_SCAL : long
1
0..1
1
STTL_RG_250K_V3
«Primary key» +STTL_ID : string
+CNTR_CODE
+POPL_SIZE : long
+POPL_LORN : long
+POPL_UPRN : long
+ALT_AVRG : long
+NAME : string
+NAME_ASCI : string
+LANG_CODE : LANG_DOM
-MIN_SCAL : long
Model 1a: Bad design with high level of redundancy
STTL_V3: Settlements
STTL_RG_01M_V3
«Primary key» +STTL_ID : string
0..1
STTL_PT_V3
«Primary key» +STTL_ID : string
+SRC_CODE : DATA_SRC_AT
1
1
STTL_PT_ATTR
1
0..1
STTL_AR_01M_ATTR
1
1
STTL_AT_V3
«Primary key» +STTL_ID : string
+CNTR_CODE
+POPL_SIZE : long
+POPL_LORN : long
+POPL_UPRN : long
+ALT_AVRG : long
+NAME : string
+NAME_ASCI : string
+LANG_CODE : LANG_DOM
-MIN_SCAL : long
1
0..1
0..1
1
STTL_RG_250K_V3
«Primary key» +STTL_ID : string
1
STTL_AR_250K_ATTR
Model 1b: Attribute redundancy suppressed
The information about the real world entity "Settlement" in model 1b is split without redundancy in four different classes: STTL_RG_01M_V3 (multi-part polygons, 1:1M scale),
STTL_RG_250K_V3 (multi-part polygons, 1:250 000 scale), STTL_PT_V3 (point topology) and STTL_AT_V3 (Attributes). All the information about one settlement can be put together by means of its unique identifier (STTL_ID) which is the same for a given settlement (real world entity) in all four classes.
10

Classes that implement many-to-many relationships
The many-to-many relationships are physically stored as an object class. The name of the object class that represents a many-to-many relationship will be built up by the following segments:
First end class/subtype short name
Second end class/subtype short name
A noun (when possible a “-ship” noun) that gives a general description of the relationship
When both ends belong to the same data theme, the common segments will appear only once:
The data theme short name should be omitted.
If both have the same time stamp and/or version they should appear only once in the second end
The noun for describing the relationship has a maximum length of 8 characters . If the resulting table name exceeds 30 characters, the noun will be shortened to reach the maximum number of characters allowed.
It is not necessary to create an artificial ID for these tables-
Examples:
Class identifications not needed:
The data theme “NUTS” models only NUTS regions. The class identification can be dropped:
NUTS_NUTS_RG (wrong)
NUTS_RG (Correct)
Class identification required:
The data theme “Urban Audit” models 4 different entities: Sub-city Districts, Cities,
Kernels and Large Urban Zones. Therefore the class identifications are needed:
- URAU_CITY_RG (Urban Audit - City – Multipart polygon topology)
- URAU_LUZ_RG ( Urban Audit - Large Urban Zones - Multipart polygon topology)
- URAU_CITY_PT ( Urban Audit - City – Point topology)
Generalisations
- COAS_LN_01M (coastline, line topology, scale 1:1m)
- COAS_LN_100K (coastline, line topology, scale 1:100 000)
11

Time or version stamps
STFD_PL_2000_2006 (Data theme – Feature class identification – time stamp)
Structural Funds. Since only one scale version is available, then “01M” is not strictly needed. This information can be found in the metadata. Nevertheless the scale segment can be included when there are chances to develop generalisations of the dataset to be hosted in the geodatabase in the near future)
In general, version and time stamp will only exceptionally appear at the same time. Since it is more user-friendly, time stamps are preferable to versions.
The source name will rarely be needed.
A list of “Class identifications” and “class identification short names” is available in annex 5.
It must be updated after every new geodataset developmen. Before defining a new “class identification”, it should be verified that none of the existing ones is suitable for the new class. Geometric entity names should not be used as class identifiers, e.g. label, regions, etc.
The common object oriented nomenclature concatenates class and attribute to uniquely identify an attribute (example: “AIRP_PT.ALT”). This way, an attribute name can be repeated in different feature or object classes. The attribute name will omit all references to the feature class identification, scale or time stamp that are already included in the feature or object class name. Example:
Feature class name: AIRP_PT
Good attribute name: ALT
Bad attribute name: AIRP_ALT
Primary key
The first step to start the naming of attributes will be to identify the conceptual “Primary key”: The primary key will be named after the data theme identifier short name + “ID”. When this is not sufficient, the name will be “Data theme name – Feature/object class identification
– ID”
Examples:
- NUTS_ID
- URAU_CITY_ID
Several classes might have the same name for the primary key. This will be correct when the classes are models of the same entity in the real world. For instance, cities in the Urban Audit are modelled as points (URAU_CITY_PT), as regions (URAU_CITY_RG) and as tabular information (URAU_CITY_AT). All these classes will have the same primary key:
URAU_CITY_ID
12

URAU_CITY_RG_2004
+URAU_CITY_ID : esriFieldTypeString
URAU_CITY_PT_2004
+URAU_CITY_ID : esriFieldTypeString
1
URAU_CITY_RG_AT_2004
1 1
Tables::URAU_CITY_AT_2004
+URAU_CITY_ID : esriFieldTypeString
+CNTR_CODE : esriFieldTypeString
+URAU_KERN_CODE : esriFieldTypeString
+URAU_LUZ_CODE : esriFieldTypeString
+STTL_CODE : esriFieldTypeInteger
+CITY_NAME : esriFieldTypeString
+NAME_ASCI : esriFieldTypeString
+NAME_HTML : esriFieldTypeString
+LCA_FLAG : esriFieldTypeString
All classes, except relationship classes, will have an explicit ID attribute. Primary keys in relationship classes are by definition built out of two or more attributes. In this cases there is no added value in a explicit ad-hoc unique identifier attribute.
Foreign keys
The attributes that are foreign keys will keep the same name that the pointed attribute, except the suffix: “ID” will be changed by “CODE”.
Duplicated foreign keys in the same class
It might happen that the same foreign key appears twice in the same class, each one as the result of the implementation of different relationship or a different role (end-name). In this case the foreign key name would be duplicated. This conflict must be solved somehow.
It might happen that this attribute name is not sufficient to distinctly identify where this key is pointing to. In such a case, a version or time stamp should be included. This is commonly the case of features where the historical evolution of the NUTS codes is maintained in different attributes:
- NUTS_CODE_2003
- NUTS_CODE_1999
- NUTS_CODE_1995
This can also be the case of multiple foreign keys in one class pointing to the same target class. This is the case of the language code when the national and the local name of a feature are included:
13

1
TRAN_RWST_V2_LANG_CODE_LU
Tables::LANG_DOM
-LANG_ID : esriFieldTypeString
-LANG_NAME_ENGL : esriFieldTypeString
TRAN_RWST_V2_LANG_CODE_2_LU
1
0..*
0..*
TRAN_RWST_ND_250K_V3
-TRAN_RWST_ID : esriFieldTypeInteger
-CNTR_CODE : esriFieldTypeString
-RWST_NAME : esriFieldTypeString
-NAME_ASCI : esriFieldTypeString
-LANG_CODE : esriFieldTypeString
-RWST_NAME_2 : esriFieldTypeString
-NAME_ASCI_2 : esriFieldTypeString
-LANG_CODE_2 : esriFieldTypeString
-TRAN_RWST_HIER_CODE : esriFieldTypeInteger
This “extra” information on the foreign key name (ordinal, time stamp, etc) must be included only if other attributes pointing to the same class are available in the same feature/object class. The attribute name is not meant to substitute the metadata or the data model.
Another hypothetical albeit likely example could arise with the attribute "country" when an origin and destiny attributes are included in the feature/object class:
- CNTR_CODE_DEST
- CNTR_CODE_ORIG
1.- The foreign keys point to the tabular implementation of a relationship. The attribute name could be completed with the segment of the relationship name that represents the role (See next chapter “Relationship names and role names in Arc GIS”)
2.- When the foreign keys point to different subtypes, the subtype identifier can be added as a segment of the foreign key name.
Classification attributes (coded value domains)
“Type”, “Class”, “Classification”... : These words must be avoided in the attribute names.
Every classification is done according to well defined criteria. The name of the classification, type or status attribute must be decided after these criteria.
BAD: Airport type (Militar, Civil public, civil private...)
GOOD: Airport management body (Militar, Civil public, civil private...)
Types, classes and status can be related to an ArcGIS enumeration (domain class). Otherwise, when the enumeration has a physical implementation in an Oracle table, then the coded value domain attributes must be treated as foreign keys to their respective domain class.
Other attribute names:
Attributes that are not foreign key are obviously only related to the feature/object class that host them. In consequence, no prefix will be used. When it will be needed to identify the
14

feature/object class among other synonyms from different classes, then the object oriented notation will be used (“AIRP_ICAO_PT.ALT")
Difference between "name" and "description"
“NAME”: Word (or small number of words) by which individual person, animal, place or thing is spoken of or to.
"NAME" is an ORACLE reserved word. In consequence, these attributes can not be called simply “NAME”. The class identifier will be added: ClassIdentifier _NAME
It might happen that several names are available for the same feature/object class. In this case the attribute name can be distinguished by a suffix, usually the source. In this case the prefix can be omitted. For example:
NAME_SABE
NAME_SIRE
When possible, three name attributes should be included in the database:
ClassIdentifier _NAME: using full diacritics
NAME_ASCI: using the reduced 7 bit ASCII character set
NAME_HTML: using the conversion from Unicode to the HTML hexadecimal coding.
“DESCRIPTION”: Verbal portrait or portraiture of person, object or event, more or less complete.
The “description” attributes will have the segment “DESC”. They can not be named only "DESC" because this is a reserved word in the ESRI semantics checker (Visio). It is important not to mix up “descriptions” and “names”: the description, by definition, is rather long. No attribute should be named “definition” in this sense.
Boolean attributes: FLAG
Boolean attributes (When the attribute values belong to the domain "True/False", "Yes/No", etc) will be suffixed as "FLAG".
Examples:

TRUE_COMM_FLAG: The polygon represents a commune ("T") or another territory with no self administration ("F" for condominiums, uninhabited forests, lakes administrated by higher administrative entities than communes)

EU_FLAG: European Union flag (The feature is part or not of the European Union territory)
Boolean format is represented internally in many different ways by different systems, for instance [-1,0] in Visual Basic, while SQL evaluates [True, False] as [1,0]. There are other possibilities such as [any positive value, 0]. For a better user-friendliness and facilitate multi-
15

platform access to the data it is recommended to define all conceptual Boolean attributes as strings ([Y,N], [T,F], etc).
Keywords:
A list of keywords and short keywords will be developed and constantly updated. Before naming an attribute, the list of forbidden words and keywords should be consulted. (See annex 4) Examples:
Keywords
Name
Description
Longitude
Latitude
Altitude
Objective
Country
Code
Identifier
Abbreviation
NAME
DESC
LON
LAT
ALT
OBJ
CNTR
CODE
ID
Forbidden words
Type
Class
Definition alternative
Name the criteria used for the classification
Name the criteria used for the classification
Description
Sequential number
Nation
ID or code
Country
State (political concept) Country
NUTS 0 Country
In order to identify the tables involved in a given relationship, the relationship will be named after the tables that they relate, by taking the common and non-common segments from the related tables. Example:
Object class COMM_AT_2001
Feature class COMM_RG_01M_2001
Relationship name COMM_RG_ 01M_2001_AT
In the case of features related to attribute tables we recommend to place first the name of the feature class, followed by the non-common segments from the attribute table.
The name of relationships in ArcGIS can be complemented with a noun (when possible a
“-ship” noun) that gives a general description of the relationship.
The role of the entities involved in a relationship (called in ArcGIS terminology “Forward /
Backward path label”) will be a verb. The forward and backward path label can be labelled
16

with different verbs, but it is a common practice to label one with an active form and the other with the same verb in passive form. Roles will not be implemented in ORACLE, so we can make use of the natural names. Example:
Relationship name: URAU_CITY_KERN (Urban Audit City-Kernels)
Forward path label: covers
Backward path label: is covered by
Factually, all classes that are pointed by a foreign key in another class are domains. In this paragraph we will refer only to the “coded value domains” or “enumerations” in ArcGIS
These "coded value domains" are nothing but a trick to decrease the size of the tables and reduce the probability of errors. For instance, we have an attribute called "eligibility" that can take three different values: "Totally Eligible", "Partially Eligible" or "Non Eligible". It is a common good practise to code these values (For instance "E", "P" and "N" respectively). This way the average size of the attribute is reduce to a 7% approximately (this is not a strong argument in GIS where geometry takes so much space) but most of all it facilitates the quality control procedures (domain integrity) and reduces the edition errors (values with typos like
"Non Eligble")
In consequence, these attributes (that conceptually are not foreign keys to another class) once they are implemented in Oracle they behave as foreign keys. So all naming conventions applied to classes will be applicable to domains. The only difference (in order to make the difference with the "true" classes) will be that domain names will get a suffix "DOM".
The name will be as descriptive as possible. Sometimes it requires an effort to find the word that better describes the criteria followed to define the domain. The forbidden words (“type”,
“class”, “status”, etc) should not be used in the domain name. The name should be composed of the attribute name and the extension DOM. In case the domain name does not uniquely identify a table, additional identifiers, such as time stamps can be added to the name.
Domain classes will be implemented in tables with two attributes (Otherwise they would be real classes):
Table name: DomainName _DOM
Attributes: DomainName _ID
DomainName _DESC
Those attributes in other tables that are based on a give domain " DomainName " will be named
DomainName _CODE. For example:
The name of the domain for the attribute “LANG_CODE” (language code) will be
“LANG_DOM”.
According to the scope of the domain, they can be classified as general purpose domains
(used in several classes in different data themes) or specific usage domain (strongly related to one single data theme).
17

For domains related to a specific data theme, the data theme must appear in the domain name.
Feature class: AIRP_PT_2005
Attribute: AIRP_PASS_2004_CODE (Category of the airport in 2004 defined in the
Airport statistics Regulation according to the traffic of passengers).
Domain name: AIRP_PASS_2004_DOM
This naming strategy presents two advantages:

To avoid the coincidence of names in other data theme domains. The name without the data theme segment "AIRP" (PASS_DOM) could easily clash with the categorisation of passenger traffic for other transport means.

To facilitate navigation among the objects through the different data themes. If we find an attribute called "AIRP_PASS_2004_CODE" we can expect to find a table called "AIRP_PASS_2004_DOM" to decode the attribute values 1 .
In some cases, when many attributes are based on the same coded value domain, the name may become very long an unmanageable. This is the case of the eligibility in the Structural
Funds datasets. There are 11 attributes based on the Eligibility domain. If we strictly follow the conventions described in the previous paragraphs, they would get some names like this:
- STFU_ELIG_CODE_OBJ1_PH05
- STFU_ELIG_CODE_OBJ2_PH06
Although this is good to understand the structure of the data, this is very inconvenient when the data is displayed. A compromise in this case could lead to suppress some of the segments and document it properly in the metadata.
- ELIG_OBJ1_PH05
- ELIG_OBJ2_PH06
Subtype classes will trigger a double implementation:
As coded values domains (in Oracle)
As subtypes in ArcGIS
The implementation in Oracle as coded values domains will follow the rules described in the previous chapter (Domain names)
The names of the subtypes in ArcGIS will be as descriptive as possible.
1 Note that the geometrical objects of each conceptual data theme are implemented in separated feature datasets.
Nevertheless, all tabular objects without geometry (object classes in ESRI terminology) are stored together in one single folder/directory. This makes very difficult to find objects in the database when you are not sure about the name of the object you are searching.
18

The codification of subtypes must be done by means of integer values. This is not a convention but an ArcGIS restriction. Some systems cannot distinguish between a "0" and a
"null value". Hence the value "0" must be avoided in subtype codification to facilitate export to different platforms. Codes should start by "1" or by any other natural number if it is more meaningful.
19

ANNEX 1 Definitions
Data Theme: Collection of geographical features and tabular data concerning a certain subject. This concept has no implementation in ArcGIS
Feature class : Collection of features with the same type of geometry, attributes and coordinate reference system
Feature dataset : Collection of classes that share a common coordinate system.
Geodatabase : Top level unit of geographic data in ArcGIS environment. It is a collection of datasets, feature classes, object classes and relationship classes.
Object class : Table in a geodatabase with which you can associate behaviour. Object classes keep descriptive information about objects that are related to geographic features.
Subtype : A means of setting different rules (relationship class restrictions, domains, etc.) for individual features within a feature class given the value in a single subtype field (which must be integer but can be given a text description).
20

ANNEX 2 Oracle reserved words
There are more than 1000 reserved words in Oracle. After applying the conventions described in this document, only a few reserved words could eventually clash with a name chosen for a table or an attribute. These names should be avoided:
DBA
DDL
DEC
DESC
DISK
DML
DROP
DUMP
EACH
ELSE
END
FACT
FAST
FIC_CIV
FIC_PIV
ADD
ALL
ALL_ROWS
AND
AND_EQUAL
ANY
AS
ASC
AT
AUTO
BITS
BLOB
BODY
BOTH
BULK
BY
BYTE
CALL
CASE
CAST
CHAR
CHAR_CS
CIV_GB
CLOB
COST
CPU_PER_CALL
CUBE
CUBE_GB
DATA
DATE
DATE_MODE
DAY
LOB
LOCK
LOG
LONG
MAIN
MAX
MIN
MODE
MOVE
NAME
NAN
NAV
NEW
NEXT
NL_AJ
INT
INTO
IS
JAVA
JOB
JOIN
KEEP
KEY
KEYS
KILL
LAST
LEFT
LESS
LIKE
LINK
LIST
FILE
FINE
FLOB
FOR
FROM
FULL
HASH
HASH_AJ
HASH_SJ
HEAP
HIGH
HOUR
ID
IDLE_TIME
IF
IN
QB_NAME
RAW
RBA
READ
REAL
REF
RELY
ROLE
ROW
ROWS
RULE
SB4
SCAN
SCN
SD_ALL
NL_SJ
NLS_COMP
NLS_LANG
NLS_SORT
NO
NO_FACT
NO_PUSH_PRED
NO_PUSH_SUBQ
NO_QKN_BUFF
NO_SET_TO_JOIN
NO_USE_HASH
NO_USE_NL
NONE
NOT
NULL
OF
OFF
OID
OLD
ON
ONLY
OPEN
OR
OUT_OF_LINE
OVER
OWN
PIV_GB
PIV_SSF
PLAN
PQ_MAP
PUSH_PRED
PUSH_SUBQ
SD_SHOW
SEED
SEG_FILE
SET
SET_TO_JOIN
SETS
SID
SIZE
SKIP
SOME
SORT
SQL
STAR
STOP
SYS_OP_CAST
TEST
THAN
THE
THEN
TIME
TIME_ZONE
TIV_GB
TIV_SSF
TO
TRUE
TX
TYPE
UB2
UBA
UID
UNDO
USE
USE_ANTI
USE_HASH
USE_NL
USE_SEMI
USE_WEAK_NAM
E_RESL
USER
VIEW
WAIT
WHEN
WITH
WORK
XID
YEAR
ZONE
21

ANNEX 3 Keywords
Flag
Foreshore
French
Hierarchy
Horizontal
Hydrographical
Ice areas
Identifier
Industrial
Interreg 3
ISN
ISO
Lake
Land
Land Cover
Language
Large Urban Zone
Latitude
LAU1
LAU2
Length level 1 level 2 level 3
Keywords
Administrative region
Airport
Altitude
Area
ASCII
Candidate Countries
Category
City
Coastline
Code
Condominium
Corine Land Cover
Country
Country level
Date
Definition
Description
Drain
EFTA
Eligibility
English
FACC
Feature
Fictitious
Fisheries
CNTR
CNLV
DATE
DEFI
DESC
DRAI
EFTA
ELIG
ENGL
FACC
FEAT
FICT
FISH
Abbreviation
ADRG
AIRP
ALT
SURF
ASCI
CC
CATG
CITY
COAS
CODE
COND
CLC
FLAG
FOSH
FREN
HIER
HORI
HYDR
ICE
ID
INDS
IRG3
ISN
ISO
LAKE
LAND
LCOV
LANG
LUZ
LAT
LAU1
LAU2
LENG
LEV1
LEV2
LEV3
22
Location
Longitude
Name
National
Institute
Nature
Number
NUTS
Objective
Objective 1
Objective 2
Other
Owner
Passenger
Perimeter
Population
Port
Primary
Program
Public
Reference
Statistical
LOCA
LON
NAME
Regime
Resolution
Rural
SABE
Scale
Secondary
SIRE
Site
Source
Stack
Statistical
Structural Funds
Subcommune
Surface
Swedish
Symbol
Total
SYMB
TOTL
Traffic TRAF
TransEuropean Network TEN
Unit
Urban
Urban Audit
Vertical
Water areas
Water patterns
Watershed
Width
Zone
UNIT
URBN
URAU
VERT
WTAR
WTPT
WTSH
WDTH
ZONE
REGM
RESO
RURL
SABE
SCAL
SEC
SIRE
SITE
SRC
STCK
STAT
STFU
SBCM
SURF
SWED
NSI
NATR
NUMB
NUTS
OBJ
OBJ1
OBJ2
OTHR
OWNR
PASS
PERI
POPL
PORT
PRI
PRGM
PUBL
REFR

23

ANNEX 4 Forbidden words:
Forbidden words
Class alternative
Describe the criteria for the classification
"Definition" as equivalent to "Description" Description
Nation Country
NUTS 0
Sequential number
State (political concept)
Status
Type
Category
Country level
ID or code
Country
Describe or add the criteria for the classification
Describe the criteria for the classification
Describe the criteria for the categorisation
24

ANNEX 5 Class identifiers:
Feature/object class and Subtype identifications Short name
Airport
City
Commune
Condominium
Country
Kernel
Structural funds
Urban Audit
AIRP
CITY
COMM
COND
CNTR
KERN
STFU
URAU
Interreg III
Large Urban Zone
Port
Site
Source
IRG3
LUZ
PORT
SITE
SRC
Subcommune SBCM
Coastline
Water areas
Ice areas
Water patterns
COAS
WTAR
ICE
WTPT
Dams and weirs
Hydrographical names
DMWE
Watershed
Lakes
HYDR_NAME
WTSH
LAKE
Administrative region ADRG
25

ANNEX 6: GISCO data themes:
ISO 19115 Topic Category
01 - Farming
02 - Biota
02 - Biota
02 - Biota
03 - Boundaries
03 - Boundaries
03 - Boundaries
03 - Boundaries
03 - Boundaries
04 - Climatology / Meteorology / Atmosphere
05 - Economy (14 - Oceans)
06 - Elevation
06 - Elevation
07 - Environment
07 - Environment
08 - Geo-scientific Information
08 - Geo-scientific Information
08 - Geo-scientific Information
08 - Geo-scientific Information
08 - Geo-scientific Information (14 - Oceans)
10 - Imagery/Base maps/Earth cover
12 - Inland waters
12 - Inland waters
12 - Inland waters (07 - Elevation)
13 - Locations
13 - Locations (01 - Farming)
13 - Locations (16 - Society)
13 - Locations (16 - Society)
14 - Oceans
14 - Oceans
15 - Planning/Cadastre
15 - Planning/Cadastre
15 - Planning/Cadastre
15 - Planning/Cadastre
15 - Planning/Cadastre
15 - Planning/Cadastre
16 - Society
16 - Society
18 - Transportation
18 - Transportation
18 - Transportation
18 - Transportation
18 - Transportation
19 - Utilities / Communication
19 - Utilities / Communication
19 - Utilities / Communication
INSPIRE data theme
Agricultural and Aquaculture Facilities
Habitats and biotopes
Biogeographical Regions
Habitats and biotopes
Statistical Units
Administrative Units
Administrative Units
Administrative Units
Administrative Units
Meteorological Spatial Features
Area Management
Elevation
Oceanographic Features
Natural Risk Zones
Protected sites
Natural Risk Zones
Natural Risk Zones
Soil
Geology
Natural Risk Zones
Land Cover
Hydrography
Hydrography
Hydrography
Geographical Grids
Geographical Grids
Geographical Names
Geographical Names
Sea Regions
Oceanographic Features
Zones and Reporting Units
Zones and Reporting Units
Zones and Reporting Units
Zones and Reporting Units
Zones and Reporting Units
Zones and Reporting Units
Population distribution - Demography
Population distribution - Demography
Transport Networks
Transport Networks
Transport Networks
Transport Networks
Transport Networks
Production and industrial facilities
Production and industrial facilities
Production and industrial facilities
GISCO data theme (Long name)
Farm Accountancy Data Network (FADN)
Natural Vegetation
Biogeographical Zones
Biotopes
Territorial Units for Statistics (NUTS + Statistical Regions)
Communes
Subcommunes
Administrative regions
Countries
Climate
Fishing Areas
Digital Elevation Model
Bathimetry
Land Quality
Designated Areas
Soil Erosion Risk
Geology Geomorphology ErosionTrend
Soil
Sediments Discharges
Coastal Erosion
Land Cover
Water Patterns
Lakes
Watersheds
Geographical Grid
LUCAS
Settlements
Gazetteer
Coastline boundaries
Sea Level rise
Inter Regional
Leader Zones
Less Favoured Areas
National Support
Structural Funds Zones
Urban Audit
Population
Degree of urbanisation
Airports
Ferry links
Ports
Road infrastructure
Railway infrastructure
Nuclear Power
Energy Production
26
URAU
POPU
DGUR
AIRP
FERR
PORT
ROAD
RAIL
NUPW
ENPR
ENTR
LAKE
WTSH
GGGR
LUCA
STTL
GAZZ
COAS
SELV
IREG
LEAD
LFAV
NTSU
STFU
CLIM
FISH
DEM
BATH
LNQU
DSIG
SOER
ERTR
SOIL
SDDS
COER
LCOV
WTPT
Short name
FADN
VEGT
BIOG
BIOT
NUTS
COMM
SCOM
ADRG
CNTR