Sitemorse checks that the HTML keywords and description metadata fields have some content and that the phrases are separated by commas.

UK government websites are assessed for eGMS metadata compliance. The terms listed are checked against the eGMS required schemas for both mandatory and recommended matches.

Version 3.0 of the eGMS required that web pages specify one or more categories from the GCL using the 'eGMS.Subject.Category' metadata field. Version 3.1 of the eGMS now requires one or more categories from IPSV term instead, using the 'DC.Subject' field.

The tests for the Subject field are as follows;

1. Is the correct scheme in use?
2. Does the ‘content’ field contain information?
3. Is the information in the ‘content’ field from approved terminology?

Approved Terminology

For an interim period, Sitemorse will be checking for both 'eGMS.Subject.Category' and 'DC.Subject', and both GCL and IPSV - sites using either eGMS 3.0 or eGMS 3.1 will be able to achieve full marks on the eGMS Sitemorse Mark.

Please note however that at some future date (to be announced), we will discontinue support for eGMS 3.0 and sites not using 'DC.Subject' with IPSV will be marked down.

Assigning more than one category

If multiple category terms belong to the same schema they may be included in a single Subject field, separated with a semicolon. Alternatively each field may be placed in separate meta tags to assign additional categories.

Example meta data that would pass eGMS Version 3.1:

<meta name="DC.Subject" scheme="eGMS.IPSV" content="Advertising">

Example meta data that would fail eGMS Version 3.1 - Missing mandatory field

<meta name="DC.Subject" scheme="eGMS.IPSV" content="">

Example meta data that would fail eGMS Version 3.1 - Bad data supplied

<meta name="DC.Subject" scheme="eGMS.IPSV" content="incorrect chosen term here">

The 'eGMS.Subject.Category' (eGMS Version 3.0) and 'DC.Subject' (eGMS Version 3.1) fields are intended to be machine-readable, rather than human-readable, and therefore terms should be taken from the standard version of the appropriate category list. For example, IPSV terms should be provided in English.

This does not mean, of course, that categories as displayed to the user cannot be translated. For example, an automatically-generated navigational menu created from English IPSV tagging can easily be presented in an alternative language by using a translation table when the menu is displayed.

IPSV is a tree structure. However, software that uses the IPSV metadata is expected to have prior knowledge of the tree, so it is not necessary to include the entire 'path' on every document that uses it.

Indeed, it is actually wrong to do so, because the IPSV tree is deliberately designed with duplicate entries. For example, the term "Common Agricultural Policy" appears under

• "Environment":"Farming"
• "Environment":"Horticulture"
• "International affairs and defence":"European affairs":"European Union"

The intent of these duplicates is that a user can locate a document in multiple ways. For example, a user looking for a "Common Agricultural Policy" document as described above could find it by navigating down the tree via any of the routes listed.

Take for example "Environmental health", the correct way to tag an HTML document is simply:

<meta name="DC.subject" scheme="eGMS.IPSV" content="Environmental health">

Any IPSV-aware software reading the page will already know that "Environmental health" comes under "Health, well-being and care":"Health", and so you do not need to indicate this explicitly in the page.