Sitemorse checks that the HTML keywords and description metadata fields have some content and that ...
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 ...
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 ...
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;
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:
Example meta data that would fail eGMS Version 3.1 - Missing mandatory field
Example meta data that would fail eGMS Version 3.1 - Bad data supplied
The 'eGMS.Subject.Category' (eGMS Version 3.0) and 'DC.Subject' (eGMS Version 3.1) fields are intended to be ...
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 ...
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
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:
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.
The Sitemorse Knowledge base is the repository of knowledge about the Sitemorse system.
Every time a new feature is added, a question asked or anything our technical team believe might be appropriate is recorded here.
- Understanding the tests conducted by Sitemorse
- Interpreting Sitemorse Reports
- Useful Technologies
- Sitemorse Surveys
- Function Diagnostics
- Accessibility Diagnostics
- Code quality
- Code quality Diagnostics
- Email Diagnostics
- Metadata Diagnostics
- Customer Service and Billing Questions
- Updates and development within Sitemorse