Das DCAT-Anwendungsprofil für Datenportale in der Schweiz (DCAT-AP CH) ist ein Anwendungsprofil
des Data Catalog Vocabulary [[VOCAB-DCAT]] und dient zur Beschreibung der in Schweizer Datenportalen (z.B. opendata.swiss)
verzeichneten Daten. Seine Zielgruppe sind die Betreiber von Datenportalen in der
Schweiz (gemäss DCAT Terminologie “Data Receivers”) und die Anbieter dieser Daten,
welche Datenkataloge führen (gemäss DCAT Terminologie “Data Sender").
Datenportale stellen in der Regel nicht die Daten selbst bereit, sondern nur Metadaten zu den Daten. Diese dienen dem Zweck,
die Daten auffindbar und wiederverwendbar zu machen. So fokussiert DCAT-AP CH primär auf die Beschreibung von Metadaten.
DCAT-AP CH soll ebenfalls die Kompatibilität mit dem Anwendungsprofil für Datenportale in Europa (DCAT-AP) sicherstellen.
Denn dies mit der Version 1 nicht mehr gegeben war, wurde im Rahmen der eCH-Fachgruppe “Open Government Data” die
vorliegende Version 2 definiert, welche die höchstmögliche Kompatibilität mit [[DCAT-AP]] (aktuelle Version 2.1.0) sicherstellt.
Einleitung
Status des Dokuments
In Arbeit: Der Gebrauch ist nur innerhalb der Fachgruppe, bzw. im Expertenausschuss zugelassen.
Entwurf: Das Dokument wurde von den zuständigen Referenten aus dem Expertenausschuss zur
öffentlichen Konsultation freigegeben und entsprechend publiziert.
Vorschlag: Das Dokument wird dem Expertenausschuss zur Genehmigung TT-MM-JJJJ vorgelegt, ist aber normativ noch nicht gültig.
Genehmigt: Das Dokument wurde vom Expertenausschuss genehmigt. Es hat für das definierte Einsatzgebiet
im festgelegten Gültigkeitsbereich normative Kraft.
Abgelöst: Das Dokument wurde durch eine neue, aktuellere Version ersetzt. Die Benutzung ist zwar noch möglich,
es wird aber empfohlen, die neuere Version einzusetzen.
Aufgehoben: Das Dokument wurde von eCH zurückgezogen. Er darf nicht mehr genutzt werden.
Sistiert: Das Dokument wurde von eCH zurückgezogen. Es darf nicht genutzt werden. Es hat den Status «Genehmigt» nicht erreicht.
Area of application
The DCAT Application Profile for data portals in Switzerland (DCAT-AP CH) is an Application Profile of the DCAT vocabulary
and a Subprofile of the European Application Profile DCAT-AP.
DCAT (“Data Catalog Vocabulary”) is a semantic definition to describe data by the means of an RDF vocabulary.
It allows for a decentralized approach regarding the publication of data by enforcing interoperability
via the use of a common language to describe the data.
Being DCAT a generic language, it can be applied in various contexts.
An Application Profile specifies its utilization within a specific domain, context or application,
with the goal of facilitating data exchange. In Europe the application profile DCAT-AP was defined,
which assumed the role of a de facto standard within Europe. Many European Countries defined based on
DCAT-AP their own localized, tailored to their specific needs, Application Profiles.
The Swiss community defined DCAT-AP CH to provide guidance for Swiss data publishers on how to specify their data
catalogues and to data portal managers on how to process data catalogues, in a DCAT-AP CH and DCAT-AP conformant manner,
so that interoperability with DCAT-AP is assured.
It should be always kept in mind that both DCAT-AP CH and DCAT-AP primarily focus on metadata.
Metadata is by definition secondary information on the data: when and by whom were they published,
which usage conditions apply, how often are they updated, whom to contact about them and where
and how can they be accessed.
Überblick der Änderungen gegenüber v1
The main focus of the eCH Expert Group by the creation of DCAT-AP CH v2 was to ensure the compatibility to DCAT-AP.
All mandatory and recommended properties of DCAT-AP (v2.1.0) were adopted in DCAT-AP CH (v2).
The cardinality and requirement levels were updated to make them compatible with DCAT-AP (see chapter 4).
First DCAT and then DCAT-AP introduced the new class “Data Service”, which is used to
describe “a collection of operations that provides access to one or more datasets
or data processing functions.” In the v2 of DCAT-AP CH adopts this new class too
The informational structure defined by DCAT-AP CH v1 to inform about the legal
framework (see in particular dct:accessRights, dct:rights, dct:license
and their relationships) of data was aligned to the one utilized in DCAT-AP.
The Requirement level “conditional” was replaced by the “recommended”, to align with the DCAT-AP’s notation
The custom class dct:coverage on dcat:Dataset was removed, since it was considered
to be redundant to other properties defined by DCAT-AP, in particular dct:spatial and dct:temporal
The custom class rdfs:seeAlso on dcat:Dataset was removed, since it was considered to
be redundant to other properties defined by DCAT-AP, in particular dct:relation
DCAT-AP CH: Building Blocks
DCAT as a universal vocabulary
The Application Profile specified in this document is based on the specification of the Data Catalog Vocabulary (DCAT)
developed under the responsibility of the Government Linked Data Working Group at W3C. DCAT is an RDF vocabulary
designed to facilitate interoperability between data catalogues published on the Web. Additional
classes and properties from other well-known vocabularies are re-used where necessary.
The DCAT vocabulary consists of classes and properties.
Classes are things on the internet: Not all of them have URIs, but it is recommended to provide a URI for them.
They are complex things like a person, an organization, a dataset, a website or a downloadable data file.
Classes have properties: The properties are the attributes describing these things. Some properties occur
in more than one class, a title for example is a common attribute. Other properties are very specialized such
as a file format that only makes sense for a data file.
Properties can be simple or complex: Some properties are classes. For example, an organization can have a website. Or a dataset can have a data publisher. In general, a class can be recognized by its spelling: A property name starts with a lowercase letter such as dcat:dataset , while a class starts with a capital letter such as dcat:Dataset.
Classes and properties are used to deliver the metadata in a structured way.
The core structure of DCAT-AP CH v2 replicates the core structure of DCAT-AP
Being a Subprofile of DCAT-AP, DCAT-AP CH replicates its core structure and concepts.
Classes
The Swiss Application Profile (“DCAT-AP CH”) as well as the European Application Profile (“DCAT-AP”)
are structured around the following main 4 classes:
Note that in the previous versions of DCAT-AP and DCAT-AP CH, classes were categorised to be mandatory,
recommended and optional, like it’s currently the case for properties. This categorisation has been removed
in favour of the above overview and guidelines to create a common expectation for DCAT-AP catalogues.
To improve the coherency by the description of shared Dataset, Distribution and the new introduced class Data Services,
DCAT-AP provided guidelines on their usage:
[[DCAT-AP-USAGEGUIDE]].
DCAT-AP CH defines four requirement levels for data receivers and senders:
Mandatory property: a receiver MUST be able to process the information for that property;
a sender MUST provide the information for that property.
Recommended property: a receiver MUST be able to process the information for that property;
a sender SHOULD provide the information for that property if it is available.
Optional property: a receiver MUST be able to process the information for that property;
a sender MAY provide the information for that property but is not obliged to do so.
Deprecated property: a receiver SHOULD be able to process information about instances
of that property; a sender SHOULD NOT provide the information about instances of that property.
The meaning of the terms MUST, MUST NOT, SHOULD and MAY in this section and in the following sections are as
defined in RFC 2119.
In the given context, the term "processing" means that receivers MUST accept incoming data and transparently
provide these data to applications and services. It does neither imply nor prescribe what applications and
services finally do with the data (parse, convert, store, make searchable, display to users, etc.).
Controlled vocabularies of DCAT-AP CH v2
In the table below, a number of properties are listed with controlled vocabularies (CV) that MUST be used for
the listed properties.
Where possible the same controlled vocabularies as DCAT-AP were utilized.
However not every vocabulary proposed by DCAT-AP is currently applied for DCAT-AP CH v2.
In some cases, the eCH-Expert Group is still evaluating the application of the proposed vocabulary,
while in other cases the eCH-Expert Group decided to evaluate the introduction of a new, Swiss-specific vocabulary.
In particular for the property dct:publisher, which refers to an entity (organisation) responsible for making
a Catalogue, a Dataset or a Data Service available, a CV is still being discussed within the eCH-Expert
Group “Open Government Data” - its introduction will be evaluated for the next iterations of
this standard eCH-0200.
Property URI
Used for Class
URI
Usage note
dcatap:availability
Distribution
[[VOCAB-EU-AVAILABLITY]]
The list of terms for the availability levels of a dataset distribution in the DCAT-AP specification.
The values to be used for this property are the URIs of the concepts in the vocabulary.
A possible (non-normative) “mapping” to the current themes on opendata.swiss is proposed here:
[[VOCAB-CH-THEME]]
The value to be used for this property is the URI of the vocabulary itself, i.e.
the concept scheme, not the URIs of the concepts in the vocabulary.
Multilingualism
Switzerland is a multilingual country. Therefore, supporting multiple languages is particularly
important. For this reason, DCAT-AP CH defines guidelines regarding the content and the technical
publication of this content in different languages.
In terms of content:
Organisations at the federal level MUST provide metadata in at least
2 official languages , for instance German and French or Italian and German.
Every other organisation MUST provide this metadata in at least one of the following four
languages: English, German, French or Italian. The specification in other languages is optional.
From a technical perspective multilingualism SHOULD be handled as follows:
Multilingual literals: Properties of Range rdfs:Literal can be provided in
multiple languages by adding so called language encoded strings: these add the language as an
[[ISO 639-1]] two letter code after the string in the way that is shown in the example below:
Content negotiation: Properties of Range rdfs:Resource SHOULD be URIs.
It is important to use URIs that are language independent. Then the data publisher
in the process of dispatching these URIs can use content negotiation.
The table lists multilingual properties of DCAT-AP CH and the translation strategies that apply to them:
Content negotiation for the URI and language encoded string for the name
DCAT-AP-CH: Properties per Class
Notation
Property: denotes the Property that the class or property is given in DCAT-AP and/or
DCAT-AP CH.
URI: denotes the property URI.
Range: specifies the range of values that is expected for the property.
ReqLevel (“Requirement level”): denotes whether the class / property is mandatory, recommended or optional.
Card (“Cardinality”): specifies the minimum number of values that MUST be provided for that
property and the maximum number of values that MAY be provided.
Usage Note: specifies custom usage instructions and provides background information.
CV (“Controlled Vocabulary”): defines which controlled vocabulary SHOULD be used.
Class: Catalog
A Catalogue or repository that hosts the Datasets or Data Services being described.
DCAT-AP CH allows Catalogues of only Datasets, but also Catalogues of only Data Services,
but usually it will be a mixture of both.
This property links the Catalogue with a Dataset that is part of the Catalogue.
As empty Catalogues are usually indications of problems, this property SHOULD be combined
with the property service to implement an empty Catalogue check.
This property refers to a language used in the textual metadata describing
titles, descriptions, etc. of the Datasets in the Catalogue.
The properties title and description of Catalogues, Datasets or Distribution
can be provided in multiple languages. In that case, it makes sense to also list
these languages on the Catalogue level.
This property refers to a site or end-point (Data Service) that is listed in the Catalogue.
As empty Catalogues are usually indications of problems, this property SHOULD be combined
with the property Dataset to implement an empty Catalogue check.
This property refers to a geographical area covered by the Catalogue.
CV to be used: The EU Vocabularies Name Authority Lists MUST be used for continents, countries and places that are in those lists; if a particular location is not in one of the mentioned Named Authority Lists, Geonames URIs MUST be used:
[[VOCAB-EU-CONTINENT]],
[[VOCAB-EU-COUNTRY]],
[[VOCAB-EU-PLACE]],
[[GEONAMES]]
This property contains the most recent date on which the Catalogue was modified.
Class: Dataset
A Dataset is a collection of data, published or curated by a single source and related by a common
idea or concept. In contrast to a Data Service a Dataset is expected to be a collection of data that is
available for access or download in one or more formats, as Distributions. Distributions belonging to
the same Dataset should not differ in regards to the idea of the data that they represent. They may differ
in regards to the physical representation of the data such as format or resolution. Or they may split the
data of the dataset into portions of comparable size such as data per time period or location.
DCAT-AP provides guidelines about the usage of Data services and Distribution in relation to Datasets:
[[DCAT-AP-USAGEGUIDE]].
This property contains a free-text account of the Dataset.
This property can be repeated for parallel language versions of the
description (see ). On the user interface of
data portals, the content of the element whose language corresponds to the
display language selected by the user is displayed.
This property links the Dataset to an available Distribution.
In exceptional cases, a Dataset for which no distribution form exists (yet) can
be described in the Catalogue. In this case, the element dcat:distribution may be omitted.
This property refers to a geographic region that is covered by the Dataset.
CV to be used: The EU Vocabularies Name Authority Lists MUST be used for continents,
countries and places that are in those lists; if a particular location is not in one of
the mentioned Named Authority Lists, Geonames URIs MUST be used:
[[VOCAB-EU-CONTINENT]],
[[VOCAB-EU-COUNTRY]],
[[VOCAB-EU-PLACE]],
[[GEONAMES]]
This property contains the most recent date on which the Dataset was changed or modified.
No value may indicate that the Dataset has never changed after its initial publication,
or that the date of the last modification is not known, or that the
Dataset is continuously updated
This property MUST only be set if the distributions (the actual data) that
the Dataset describes have been updated after it has been issued. In this case the property
MUST contain the date of the last update. That way a person or institution using the data
for an analysis or application will know when to update the report or application on their side.
This property refers to an implementing rule or other specification.
This property SHOULD be used to indicate the model, schema, ontology, view or profile
that this representation of a Dataset conforms to. This is (generally) a complementary concern
to the media-type or format.
A thumbnail picture illustrating the content of the dataset.
Usage Note
A thumbnail picture illustrating the content of the Dataset.
For distributions that consist of visual content (photographs, videos, maps, etc.)
it makes sense to add a limited number of thumbnails to the metadata.
It’s a DCAT-AP CH Custom Class (not present in DCAT-AP)
This property refers to a related resource where the relationship cannot be further specified as a
dcat:qualifiedRelationship. This may be additional material such as an article, example or
documentation helpful in the context of the Dataset.
The element can also be used to link to legal foundations that apply to the publication or usage
of the Dataset.
Class: Distribution
A metadata entry of this class describes a distribution of the data, which is a specific representation
of a Dataset. A Dataset might be available in multiple serializations that may differ in various ways,
including natural language, media-type or format, schematic organization, temporal and spatial resolution,
level of detail or profiles (which might specify any or all of the above).
The distribution can contain all the data of the Dataset or it can contain just a part of the data.
For example: it can contain all data about the population in Switzerland or it can contain just one year of
this data, say the year 2018. It can also contain the data in an alternative data format, for example a
graphical presentation of the data for the years 1990 up to 2010.
DCAT-AP allows the representation of various relationships within Dataset or between Datasets: The simplest
relationship is the aggregation of various physical representations of data (“Distributions”) into a Dataset.
One possible such Dataset would be a time series where each distribution covers one year of the data and the
Dataset spans several years.
A distribution represents a general availability of a Dataset. It implies
no information about the actual access method of the data, i.e. whether by direct download or
through a Web page. The use of dcat:downloadURL property indicates directly downloadable distributions.
DCAT-AP provides guidelines about the usage of Data services and Distribution in relation to Dataset:
[[DCAT-AP-USAGEGUIDE]].
This property contains a URL that gives access to a Distribution of the Dataset. The resource at
the access URL may contain information about how to get the Dataset.
This property refers to the file format of the Distribution.
CV to be used: [[VOCAB-EU-FILE-TYPE]]
If a format is not available:
a) media type ([[IANA-MEDIA-TYPES]]) should be used
b) If necessary, a discussion to evaluate the adoption within the EU should be
launched (Contact point: [[VOCAB-EU-OP-CONTACT]]).
This property contains a name given to the Distribution. This property can be repeated for
parallel language versions of the description
(see ).
The title MUST be given if the distribution contains only part of the data offered by the Dataset
The title can be given in several languages. In multilingual data portals, the title in the
language selected by a user will usually be shown as title for the distribution.
If a dataset contains distributions that differ regarding their content beyond just differences
in format or resolution this property can be used to specify temporal or spatial coverage of the
data that the distribution contains.
It’s a DCAT-AP CH Custom Class (not present in DCAT-AP).
In case of a downloadable file, it is good practice to repeat the mandatory accessURL
in this more specific property, to indicate to the data user that the distribution has this
extra characteristic of being downloadable. The downloadURLs MAY thus be the same as the
accessURLs but they MAY also differ.
A thumbnail picture illustrating the content of the Distribution.
For distributions that consist of visual content (photographs, videos, maps, etc.) it makes
sense to add a limited number of thumbnails to the metadata.
It’s a DCAT-AP CH Custom Class (not present in [[DCAT-AP]]).
This property refers to a language used in the Distribution.
This property can be repeated if the metadata is provided in multiple languages.
The property MUST be set if the distribution is language-dependent, or if it is given in
some of the languages German, French, Italian and English but not in all four languages.
This property refers to the format of the file in which one or more data files are
grouped together, e.g. to enable a set of related files to be downloaded together.
It SHOULD be expressed using a media type as defined in the official register of media types managed by IANA.
This property refers to the minimum time period resolvable in the Dataset distribution.
Class: Data Service
A Data Service is a collection of operations that provides access to one or more Datasets or data
processing functions. If a dcat:DataService is bound to one or more specified Datasets, they are
indicated by the dcat:servesDataset property.
DCAT-AP provides guidelines about the usage of Data services and Distribution in relation to
Datasets:
[[DCAT-AP-USAGEGUIDE]].
This property contains a description of the services available via the end-points,
including their operations, parameters etc.The property gives specific details of the actual
endpoint instances.
This property refers to a web page that provides access to the Data Service and/or
additional information. It is intended to point to a
landing page at the original data provider, not to a page on a site of a third party, such as an aggregator.
Conformance to DCAT-AP
DCAT-AP CH is a Subprofile of DCAT-AP and DCAT-AP is an application profile of DCAT.
The DCAT-Profile Guidance states that application profiles may form hierarchies.
There is a close collaboration between DCAT-AP and DCAT-AP CH which takes place mostly as an
online discussion on GitHub at [[DCAT-AP-GITHUB-ISSUES]].
The following diagram captures the relationship between DCAT, DCAT-AP and DCAT-AP CH:
classDiagram
DCAT --> DCAT_AP: is_profile_of
DCAT_AP --> DCAT_AP_CH: is_subprofile_of
DCAT --> DCAT_AP_CH: is_profile_of
class DCAT {
- defines classes
- defines properties
- base vocabulary
}
class DCAT_AP {
- uses classes of DCAT
- specifies requirement levels
- specifies controlled vocabulary
}
class DCAT_AP_CH {
- localizes DCAT-AP for Swiss context
- can restrict more but not less than DCAT-AP
}
For the previously mentioned interoperability reasons, DCAT-AP CH aims to stay a sub-profile of [[DCAT-AP]].
Furthermore, this way it can be assured that metadata structured as DCAT-AP CH can be efficiently
harvested by [[DATAPORTAL-EU]].
DCAT-AP CH also aims for completeness, in the way that a data provider that only uses DCAT-AP CH
as guidance should be able to form a data catalogue that automatically conforms to DCAT-AP.
Therefore:
DCAT-AP CH contains all core classes currently known to be in DCAT-AP (Version 2.1.0, Chapter 3)
DCAT-AP CH contains all currently known recommended and mandatory properties of DCAT-AP (Version 2.0.1).
For these mentioned properties the usage conditions of DCAT-AP CH apply.
Properties of DCAT-AP or DCAT that are not mentioned in DCAT-AP CH are considered to be optional. For
these properties the usage conditions of DCAT-AP and DCAT apply in the following order: if the property
is part of DCAT-AP, DCAT-AP’s usage conditions apply, if it is a property of DCAT only,
then DCAT’s usage conditions apply.
Custom properties in DCAT-AP CH
DCAT-AP CH MAY introduce Swiss specific properties and vocabulary, such as the list of cantons of Switzerland,
which don't exist in the DCAT or DCAT-AP vocabulary. It SHOULD however not introduce its own (custom) properties
that can already be expressed in DCAT with different vocabularies. In those cases, the
DCAT-AP or DCAT vocabulary have to be used.
Therefore, some properties that were custom in Version 1 have been removed in Version 2 of DCAT-AP CH:
dct:coverage on dcat:Dataset can be now be expressed by dct:temporal and dct:spatial
rdfs:seeAlso on dcat:Dataset can now be expressed by dcat:qualifiedRelation
DCAT-AP CH still defines custom properties where a replacement by DCAT-AP or DCAT vocabulary is currently
not considered possible or useful (in DCAT-AP Version 2.1.0):
schema:image on dcat:Dataset and dcat:Distribution: this property is used to provide
thumbnails for Distributions that contain visual data
dct:coverage on dcat:Distribution is needed to model distributions of datasets as a series of data
Conformance to DCAT-AP CH
Data Provider requirements
A data catalogue conforms to DCAT-AP CH if:
An RDF description of the catalogue is available
All classes and properties defined in DCAT-AP CH v2 are used in a way consistent with the
semantics declared in this specification.
Properties not mentioned in this specification MAY be used if they are included in either
DCAT-AP or DCAT and their usage conforms to DCAT-AP if they are
included in DCAT-AP or to DCAT if they are only included in DCAT.
Receiver requirements
An application (data portal) conforms to DCAT-AP if:
It is able to process RDF catalogues that conform to DCAT-AP CH.
Processing means that it MUST accept incoming data and transparently provide this
data to applications and services.
Processing does not prescribe whether and how the metadata is stored internally,
displayed or made searchable.
This processing of metadata also applies to classes and properties not mentioned in DCAT-AP CH that are part of
DCAT-AP or DCAT. A DCAT-AP CH conformant receiver MUST also be able to process these classes and properties].
Haftungsausschluss
eCH-Standards, welche der Verein eCH dem Benutzer zur unentgeltlichen Nutzung zur Verfügung stellen oder
welche eCH referenzieren, haben nur den Status von Empfehlungen. Der Verein eCH haftet in keinem Fall
für Entscheidungen oder Massnahmen, welche der Benutzer auf Grund dieser Dokumente trifft und / oder ergreift.
Der Benutzer ist verpflichtet, die Dokumente vor deren Nutzung selbst zu überprüfen und sich gegebenenfalls
beraten zu lassen. eCH-Standards können und sollen die technische, organisatorische oder juristische
Beratung im konkreten Einzelfall nicht ersetzen.
In eCH-Standards referenzierte Dokumente, Verfahren, Methoden, Produkte und Standards sind unter Umständen
markenrechtlich, urheberrechtlich oder patentrechtlich geschützt. Es liegt in der ausschliesslichen
Verantwortlichkeit des Benutzers, sich die allenfalls erforderlichen Rechte bei den jeweils berechtigten
Personen und/oder Organisationen zu beschaffen.
Obwohl der Verein eCH all seine Sorgfalt darauf verwendet, die eCH-Standards sorgfältig auszuarbeiten, kann
keine Zusicherung oder Garantie auf Aktualität, Vollständigkeit, Richtigkeit bzw. Fehlerfreiheit der zur
Verfügung gestellten Informationen und Dokumente gegeben werden. Der Inhalt von eCH-Standards kann jederzeit
und ohne Ankündigung geändert werden.
Jede Haftung für Schäden, welche dem Benutzer aus dem Gebrauch der eCH-Standards entstehen ist, soweit
gesetzlich zulässig, wegbedungen.
Urheberrechte
Wer eCH-Standards erarbeitet, behält das geistige Eigentum an diesen. Allerdings verpflichtet sich
der Erarbeitende, sein betreffendes geistiges Eigentum oder seine Rechte an geistigem Eigentum anderer,
sofern möglich, den jeweiligen Fachgruppen und dem Verein eCH kostenlos zur uneingeschränkten Nutzung
und Weiterentwicklung im Rahmen des Vereinszweckes zur Verfügung zu stellen.
Die von den Fachgruppen erarbeiteten Standards können unter Nennung der jeweiligen Urheber von eCH
unentgeltlich und uneingeschränkt genutzt, weiterverbreitet und weiterentwickelt werden.
eCH-Standards sind vollständig dokumentiert und frei von lizenz- und/oder patentrechtlichen
Einschränkungen. Die dazugehörige Dokumentation kann unentgeltlich bezogen werden.
Diese Bestimmungen gelten ausschliesslich für die von eCH erarbeiteten Standards, nicht jedoch
für Standards oder Produkte Dritter, auf welche in den eCH-Standards Bezug genommen wird. Die
Standards enthalten die entsprechenden Hinweise auf die Rechte Dritter.
Mitarbeit & Überprüfung
Änderungen gegenüber Vorversion
Verzeichnis der referenzierten Namensräume
Namespaces and prefixes used in normative parts of this recommendation are shown in the following table: