Navigation path

Asset Description Metadata Schema (ADMS)

3.59/5 | 17 votes
Editor's choice

Public comments on ADMS Specification v0.8

Editor's Choice
15 message(s)
semic .eu
Public comments on ADMS Specification v0.8
Posted by Semic .eu on January 06, 2012 at 14:24.
( , Belgium ) - 08/12/2011
2.5/5 | 2 votes


On January 6, the ADMS Specification v0.8 was released for public comments. Members of the public are invited to download the specification from the releases section and share their public review by posting comments to this forum topic (registration required). The ADMS Specification v0.8 is open for public comments until February 6 2012.
Alternatively, comments can be sent via e-mail to the ADMS editor,Makx Dekkers (adms[at]makxdekkers[dot]com).  Please indicate in your comment as precisely as possible to which part of the specification your comment applies.
All comments are registered in an issues list that will be discussed by the Working Group in early February. Resolutions of those issues will be shared on Joinup, and will lead to a final version of the specification that will be submitted to the European Commission for endorsement by the EU member states.


Antoine Isaac
Re: Public comments on ADMS Specification v0.8
Posted by Antoine Isaac on January 10, 2012 at 12:31
(Europeana, Netherlands)

Dear all,

Makx raised my attention to this. Unfortunately I don't have much time to examine it, but I thought I would still send what I found out now...

The first impression is one of very good work. The main documentation is short, seem really readable, and the entire resources you publish (PDF, RDF files even with the RDF-to-HTML transformation!) make a nice package.

Then, the general approach is well-funded. The model is really concise and tries to re-use existing elements from other vocabularies, whenever possible. I have a couple of comments below on specific decisions, but this goes in a very right direction and would encourage the group to keep to it!

Finally, I'm not an expert in the domain of modelling datasets and the repositories that register them. But I am surprised to see no reference to CKAN/TheDataHub work. This community-based effort makes available hundreds of dataset descriptions, and its schema is freely extensible. I'd expect there is some valuable experience to get from them!

Now for some detailed description on the model:

1. The introduction of classes whose (informal) semantics embody the notion of a relation, like ExampleAsset or IncludedItem, puzzles me a bit.
I would think that minting an "example" property to relate to instances of Assets would be better than creating an instance of a specialized ExampleAsset. Unless an ExampleAsset turns out to have very specific attributes that distinguish it clearly from a regular Asset. But that does not seem to be the case. Plus, you already have a "Sample" property, so ExampleAsset really seems redundant in a schema. So you could represent an instance of adms:IncludedItem just using the adms:includedItem property and the basic adms:Item class. Representation of IncludedItem resources may similarly be simplified by using the property includedItem linking to instances of the basic Item class. Note that includedItem is maybe also "semantically overburdened" in turn. If you use a basic "includes" property to relate an Asset to a (basic) Item, you have the same information, roughly.

2. Countries (6.5): I am surprised to see no reference to GeoNames, besides DBPedia or FAO Geopolitical Ontology references.

3. Licence Type vocabulary (6.8): The Creative Commons vocabulary (CCrel, has things like "allows re-use", "needs attribution". Maybe some of the stuff from 6.8 can be re-used directly from there.

4. Customization and meta-modelling (8.2)
Just on the form: I think presenting the different options as a UML diagram may be confusing. This is not part of the ADMS--or at least it should not be part of ADMS, since this is meta-modelling.

5. Namespace: is really not ideal. I guess you will change it. As a matter of fact you will have to change it, as is a reserved namespace... It would be nice that you make a decision quick :-)

6. Interoperability between vocabularies. ADMS re-uses existing vocabularies, like Dublin Core, SKOS, and that is great. It's also very good that it relates to these vocabularies, when it goes on extending them.
But maybe there is more to do. For instance, couldn't adms:sample be equivalent to skos:Concept, adms:AssetType and adms:Subject be related to skos:Concept and adms:includedItem (if you keep it like that, cf. comment #1) be related to dcterms:hasPart?
I reckon that this last issue is much less urgent, but maybe you'll want to get it right in one future version of ADMS.

Best regards,

Antoine Isaac
Scientific Coordinator, Europeana


Søren Roug
Re: Public comments on ADMS Specification v0.8
Posted by Søren Roug on January 11, 2012 at 10:50
(European Environment Agency, Europe)

My concern is "how do I find the list of assets when I discover a new website?". VoID has a convention on using /.well-known/void (used to be /void.rdf or /void.ttl). The Semantic Sitemap extension adds a line to /robots.txt declaring where to download the sitemap. What mechanism is ADMS going to use?

Since an ADMS declaration is an RDF document, it is possible to include it in /void.rdf I suppose.

Pim van der Eijk
Re: Public comments on ADMS Specification v0.8
Posted by Pim Van Der Eijk on January 23, 2012 at 17:24
(OASIS, Netherlands)

I tried to use ADMS XSD to model the metadata for the OASIS ODF 1.2 standard, (attachment available on request). Here are some preliminary comments based on this:

Many elements have a required URI child element (which is probably needed for the alternate RDF representation) for which it is unclear what the value should be. The examples in are not really helpful and probably wrong. For example, what is the URI for "FileFormat" ? I doubt is a realistic value as the ADMS example wants us to believe. IANA publishes these values, and they are not URI-based. The URI element does not always seem useful and perhaps should not be mandatory in the XML schema.

A status value also looks strange. The "" site is not intended for this type of use. Instead of being URI-valued, a code list of regular status codes (not URIs) is likely to be more natural to most users except those familiar RDF.

Various elements have a required TypeCode element, but there is no codelist to choose values from. If these are free text fields, all providers of ADMS content will use different values and as a result the data quality and consistency of a federated ADMS repository will be poor.

Codes are listed in the ADMS specification, but the XSD does not validate these lists. If it is preferred to use Schematron instead of XSD for code lists, then those Schematron rule sets should be provided. Note however that Schematron is not as widely used as XML Schema, so using it (for a relatively simple schema like ADMS) is a bit overkill. Code lists for IANA media types exist (e.g. from the UNCEFACT XML schemas) and could be reused.

OASIS publishes a single release of a document in parallel in multiple formats (PDF, HTML, revisable). But in the XSD a release can only have one associated file format. So we can only model alternative file formats as distinct releases of an asset. It would be better to allow for multiple associated file representations.

For OASIS standards, it should be possible to annotate file formats to indicate that their status. For example, in OASIS, only one of the alternative file format representations is normative. (TCs can choose which format is normative, one TC may choose the PDF version to be normative and the other the source ODF version).

OASIS also sometimes provides ZIP files containing multiple files. This is not a distinct semantic asset, it is a package containing other assets. There should be a difference between logical/semantic inclusion and convenience packaging.

By that same logic, it looks as if the various stages of an OASIS product (wd, csd, cs, prd, os, os incorporating errata) need to be modelled as different assets. But ODF 1.2 is the functional successor ("next" functional version) of ODF 1.1. The various versions produced at various stages of the OASIS process are process stage successors (so a "cs" is the "next" process stage version of a "csd"). It should be possible to model this difference in ADMS, and the specification should provide guidance how it is to be used.

Stasinos Konstantopoulos
Re: Public comments on ADMS Specification v0.8
Posted by Stasinos Konstantopoulos on February 04, 2012 at 8:57
(NCSR "Demokritos", Greece)

Dear all,

first of all a big thumbs up for the effort you have put into this spec and for the quality of the result.

Please allow me to raise a concern: in Sect 5.6 you mention that the model does not attempt to declare any of the possible language versions the "main version" to allow flexibility on the side of the user interface in deciding which version to show to the user. You, then, proceed to describe a situation where alternative languages might be generated by automated translation tools.

Although I wholeheartedly agree with the idea that all alternative translations are listed so that the application can choose what is more suitable, I would have liked to see a way to indicate the quality of each translation, so that users can, for example, prefer the English original to a machine translation in their native language.

I see no need for excrutiatingly detailed annotation, but a binary differentiation between human-generated (or at least approved) translations and machine translation-generated ones would be useful.

Thank you,

Stasinos Konstantopoulos
Re: Public comments on ADMS Specification v0.8
Posted by Stasinos Konstantopoulos on February 04, 2012 at 9:06
(NCSR "Demokritos", Greece)

Another comment (I am breaking them up in different postings, which I assume helps their management and reference), concerns the RDF version of the spec.

In the RDF file I see no rdfs:domain declarations, even in situations where the UML diagram and the human-readable definition unambiguously has them. So, for example, adms:assetType is clearly a property of adms:AssetS, but that piece of knowledge is not there in the RDF file.

Is there a technical reason for such a decision?


Stasinos Konstantopoulos
Re: Public comments on ADMS Specification v0.8
Posted by Stasinos Konstantopoulos on February 04, 2012 at 9:11
(NCSR "Demokritos", Greece)

One can only assume that the sample Asset showcased by a Repository is one of the AssetS described by the repository.

This should be formalized by making adms:sample a subproperty of dcat:dataset


Stasinos Konstantopoulos
Re: Public comments on ADMS Specification v0.8
Posted by Stasinos Konstantopoulos on February 04, 2012 at 9:20
(NCSR "Demokritos", Greece)

The "Spatial coverage" property seems to be missing in the RDF version.


Robin Cover
Re: Public comments on ADMS Specification v0.8
Posted by Robin Cover on February 04, 2012 at 18:01
(OASIS, North America) - 17/01/2012

The v 0.8 draft spec for ADMS seems to be available in PDF format, but I'm in need of a format more accessible for string search.  Is there an editable source (e.g., XML, word processor format) or HTML version available?  I see these URIs as publicized:


Lyubomir Blagoev
Re: Public comments on ADMS Specification v0.8
Posted by Lyubomir Blagoev on February 04, 2012 at 18:59
(USW Ltd, Bulgaria)

Lost in semantic or lost semantic?

The idea of Asset Description Metadata Schema is intended “to describe semantic interoperability assets”. In such a way, those assets are defined as source of semantic, which is not truth.

The main problem of semantic interoperability is how to transfer the semantic from the semantic source into computer interpretable form. The ADMS does not concern the source of semantic and only because of them does not solve the problem of semantic transfer.

The ADMS envisage using XSD and RDF specifications together but each of them is not capable to achieve acceptable level of semantic description. Likewise ADMS- clearing process does not provide suitable estimation of that level. The clearing process does not affect the equivalence of the two types of descriptions. How the problems with potential lack of semantic and misunderstandings between the two descriptions will be solved?

In the same way the ADMS ignoring the semantic source, which means ignoring the real semantic, passes through uncontrollable quality of formal semantic descriptions and ends up into two competing formal descriptions with uncontrollable semantic equivalence.

The next reasonable question is related to the federation of semantic asset repositories. This federation will be based on the lack of real semantic and the possibility of existence of misunderstandings between doubled formal descriptions of semantic. What could be the results of such a federation?

Let’s define the model of semantic transfer from semantic source into computer interpretable form. This model should be applicable to different semantic sources. The scope of such model could be the field of e-Governance, which points out that the source for semantic is the relevant national legislation.

Having in mind that the national legislations differ in many data definitions it is obvious that the produced computer interpretable forms by the process of semantic transfer will differ as well. As a result the task for “federation of semantic asset repositories” will be replaced by the task for “translations of computer descriptions with well defined semantic”.

Lyubomir Blagoev





Robin Cover
Re: Public comments on ADMS Specification v0.8
Posted by Robin Cover on February 04, 2012 at 21:32
(OASIS, North America) - 17/01/2012

Would the draft ADMS specification benefit from revision to

clarify how the terms "implements"/"implementation" relate

to a "computer file"?

Spec v0.8 says (WRT "Release"):

1) 5.1 Domain Model

"A Release is a particular representation or concretisation of an

Asset in the form of a downloadable computer file that implements

the intellectual content of an Asset. A particular Release is

associated with one Asset.

2) 5.4.1 Concept: Asset

Release: [an] implementation of the Asset in a particular format

I found these two passages confusing because it seems to imply

that an Asset might typically have a textual description and other

metadata, but no "implementation" because it has no "Release".

In this case of an entity like a (prose) specification, this seems

confusing, expecially in light of the Domain Model example:

"As a concrete example of the relationship between an asset and

its releases, consider this specification of ADMS: the current

section describes the conceptual model of the semantic elements

and their relationships (the Asset), while the schemas that will be

developed in section 7 are the representations or concretisations

of the model in schemas that can be downloaded and integrated in

software (the Releases). The two schemas (one RDF schema

and one XML schema) are two releases of the Asset."


a) in what manner would a textual description of an Asset be

represented and stored, in the typical case, other than in

a "(downloadable) computer file"?

b) in the example above, is not the file named

"ADMS_Specification-v0.8.pdf" which contains the text of "this

specification of ADMS" also therefore an "implementation"

and a "Release"? If not, then I would need to conclude (?) that

the ADMS specification and the ADMS model (described in the

ADMS specification) are different Assets... Or... ?

Robin Cover
Re: Public comments on ADMS Specification v0.8
Posted by Robin Cover on February 05, 2012 at 22:03
(OASIS, North America) - 17/01/2012

I would like to register one key observation and
an extended comment on the ADMS v0.8 conceptual
model for Licence.  The perspective is especially
that of an SSO/SDO which produces implementation
specifications as Assets.


Observation: ADMS Spec page 13 sub metadata category
"availability" defines a "licence" as: "A legal
document giving official permission to do
something with a Resource."  The license ID is
to be a single URI identifying the license
(document).  This approach seems a bit awkward
because it seems to assume that a single license
(document) will be at hand (for reference) in
which different kinds of IP are involved:

* trademark
* copyright
* patent


In the technical work of SSOs/SDOs familiar to
me, the legal formulations which express the
conditions or restrictions governing "use" are
rarely instantiated in a single legal document
identifiable by a single existing URI reference.
More typically, several legal documents carry this
information, and in part, because the kinds of
"use", "reuse", "implementation" vary significantly
depending upon whether we are talking about
trademark, copyright, or patent terms.

I think this implies that SSOs/SDOs will be required
to create a new resource, identifiable and addressable
(under DNS + HTTP, using HTTP scheme) URI, which
points to various legal documents, on a case-by-case
basis for any (Asset) release. Boilerplate language
is often available for trademark and copyright, but
rarely for patent (implementation) issues.  The
new document would not be a "Licence" and it would
not be a "legal document": it would apparently be a
metadata document which contains two or more URI
references to documents that contain legal language.

Example: Specifiations developed in IETF and OASIS
are similar in that several relevant legal documents may
be published for

a) broad / generic terms presented in policies governing
   trademark, copyright, and patents
b) workgroup-specific legal terms governing patents
c) specification-specific rules governing patents
d) individual company disclosures/declarations
   relating to a single spec or spec family

In an example from IETF, a spec now has nine separate
patent disclosures, the legal terms for which ("License")
may or may not be expressed in detail in the published

Spec: Definition of the Opus Audio Codec
IPR disclosures: nine disclosures as of 2012-02-04
RFC 3979 "Intellectual Property Rights in IETF Technology"
RFC 4879 "Clarification of the Third Party Disclosure Procedure in RFC 3979"

In an example from OASIS, one Technical Committee has
published Patent Application Disclosures, but the
licenses per se are not published: implementers may
request a license, and the companies will issue
licenses consistent with current licensing practices
of the company.  But in addition to this, the Technical
Committee operates under a certain IPR mode which
expresses the broader terms for patent licensing under
that distinct mode.  In addition, the OASIS Patent
Policy provides legal formulations governing spec usage
across all Technical Committees.

XACML TC IPR disclosures
RF on Limited Terms Mode of the OASIS IPR Policy
(one of four Modes: RAND, RF on Rand, RF on Limited, Non-Assert)
Intellectual Property Rights (IPR) Policy

Summary: while it may not be considered onerous by the
SSOs/SDOs to create a new URI-addressable document for
a Release which points to applicable legal formulations
in several legal documehts (perhaps not to actual
licenses, but to information about how to obtain
licenses), the term ADMS "License" as a "legal document"
seems (?) infelicitious in these cases.  Would it be
worthwhile considering a different term (e.g., like



Vjeran Strahonja
Re: Public comments on ADMS Specification v0.8
Posted by Vjeran Strahonja on February 06, 2012 at 19:21
(University of Zagreb, Faculty of Organisation and Informatics, Croatia)

ADMS assumes a number of controlled vocabularies to be used for specific concepts in the ADMS model.  Most of them are taken from various standards, organizations and other bodies, which create them, modify, publish, and retreat. Basically, we reference to them, but we can not influence the life cycle of certain entity occurrences from foreign controlled vocabularies.

No doubt that all these code lists, taxonomies and other controlled vocabularies should have secured historicity, inside the ADMS. If it will not be provided, we will lose referential integrity, and we can imagine other inconsistencies.

Therefore all controlled vocabularies should be treated as all other semantic property. Maybe this recursion should be specified somewhere in the ADMS specification.


Ruediger Czieschla
Re: Public comments on ADMS Specification v0.8
Posted by Ruediger Czieschla on February 07, 2012 at 15:28
(City of Freiburg / Open Source Business Alliance OSBA, Germany)

Besides the many developers notes I´d like to underline the importance of metadata design from the researchers viewpoint. Would the main researchers issues be covered by the meta-catalogue? I miss a "scope of application/asset" field which sure should be linked to a catalog of sope definitions.

Public organisation need an overview FOSS Solutions concerning ERP. Search for ERP category/scope




Martijn Verhagen
Re: Public comments on ADMS Specification v0.8
Posted by Martijn Verhagen on February 08, 2012 at 10:02
(Deloitte Innovation Netherlands, Netherlands)

Dear all,

Being experts on the domain of XBRL we're trying to connect this metastandard to other developments in the field of efficient and transparant information exchange. From this perspective we are interested in the development of ADMS. With this post we would like to share our vision on the linkage between ADMS and XBRL. We hope this wil contribute to the further development of ADMS. Basis for this contribution are the following core questions:

  1. How does the ADMS initiative relate to XBRL?
  2. Can ADMS learn from the concepts of XBRL as a meta-standard?
  3. Can XBRL as a meta standard be beneficial for ADMS?

1) How does the ADMS initiative relate to XBRL?

In our opinion their are three main perspectives. XBRL as a standard for building taxonomies (especially in - but not restricted to - the financial reporting domain). XBRL-taxonomies as (formal) assets in the sense of description of sector specific definitions in taxonomies (IFRS, Dutch GAAP, etc.) and assets in the form of public data drived from XBRL-reports (instance documents).

2) Can ADMS learn from the concepts of XBRL as a meta-standard?


XBRL facilitates defining taxonomies in multiple languages. To promote comparability and exchangebility and extensibility english as a common language for building taxonomies is agreed upon. As a result  information in XBRL from differrent countries can always be compared (en presented) in English.

Definitions in context

Meaning comes from putting information in context. This is the core of XBRL-taxonomies and XBRL-documents to bring verbs like 'profit' in their legal context and give information about meaningfull relationships with other definitions.  The taxonomy, but also the definitions within taxonomies can be seen as assets in this way.


XBRL has a versioning specification. This is especially usefull when complex taxonomies change on a regularly basis. Changes can automatically identified, and - depending on the changes - automatically interpreted to convert existing information in XBRL to the new standard. This could lower maintenance cost of changes in the information chain with XBRL. Although we think the metastandard of ADMS won't change that often, it could be interesting to investigate if the principle of versioning could be beneficial to the standard of ADMS.

Built-in business rules

Beside XML-based rules, XBRL has an advanced formula specification which enables definition of (quality)controls within the taxonomy. This can be used to ensure that XBRL-information (in the case of ADMS repositories) are conform the standard.


A major principle of XBRL is extensibility. Organizations can extend common taxonomies with their own - for instance sector specific - taxonomies. This enables a step by step approach towards standardisation. In the context of ADMS this could help moving from sector specific repository definitions towards the definition of ADMS.

3) Can XBRL as a meta standard be beneficial for ADMS?

For the purpose of open automated searching and exploring of assets through the web XBRL will not be necessarily beneficial. The main reason for this is that XBRL-instance documents and taxonomies, are in most cases not easily queried. And relations between assets (definitions) can not be defined between taxonomies, only within taxonomies.

On the aspect of maintenance of repositories however XBRL could be beneficial, in the sense that:

  • standard XBRL-tools could be used to maintain repositories (these same tools could also be used for other functions of eservices (like ereporting, eforms))
  • the extensibility could help adoption and ultimately contribute to harmonization towards the ADMS standard. Extensions are easily detected and can give input for improvement and further harmonization - if necessaery
  • XBRL is meant for formal taxonomies.  Although a translation to RDF/OWL wil better suit searching and combinating information on the web, this relation to the proces of setting formal definitions could be beneficial for the quality of registered repositories. This formal proces is about making smart what information means in its (often legal) context.

We realize if – especially if not familiair with the concepts of XBRL - this comment might be some what conceptual to you. If further explanation is needed we will be glad to explain.

Yours sincerely,

Bas Groenveld, Martijn Verhagen

Deloitte Innovation, Netherlands

Jonathan Semple
Re: Public comments on ADMS Specification v0.8
Posted by Jonathan Semple on February 13, 2012 at 12:11
(Liberata UK Ltd, United Kingdom)

Hi Makx/Stijn/Vassilios,

Following our teleconference on Friday here are my comments on the ADMS v0.8 spec. As I said in the call I have a few elementary comments and one that is more substantive. I’ll tackle the easy ones first:

  1. P12 applicability and 6.11 – How will the valid vocabularies for ‘subject’ be defined and enforced?  In many areas there will not be an appropriate vocabulary.  How do we manage there such that contributors of content are not blocked by an absence of appropriate subjects. Should we require a subject vocabulary to be specified or do we allow self-defined dc:subject keywords to be used?
  2. P12 provenance – Although there could be Data Protection implications we should consider supplementing ‘publisher’ with email contact information or URL for an individual or group responsible for the asset.  It is remarkably difficult to find the right people responsible for an asset in a large government organizations.  Alternatively it may be appropriate to let CESAR consumers get to this information by accessing the asset in its original repository where, presumably, this information will probably be available.
  3. P13 usage – Recording organizations that use an asset is too vague and this information can become stale too easily.  The approach we have used in Listpoint (the Code List Management Service) is to encourage users to declare ‘Contexts’ that reference the assets they use.  More on this later.
  4. P13 defined concepts – How will enumerations of ‘core concept’ be defined and maintained?  If this could be managed somehow as a dynamic list this could be very useful but the challenges in getting the maintenance mechanism sufficiently responsive that contributors actually use it should not be underestimated.
  5. P16 UML model. Language should surely be 1..* rather than 0..*
  6. P16 UML model. Previous version and Next version should be 0..* rather than 0..1 as one asset may supersede more than one earlier asset and vice versa where reorganizations of asset contents occur during an asset’s multi-version lifecycle.
  7. P16 UML model. An asset can expose metadata referring to Previous Versions but once the service is operating in ‘Business As Usual’ state it will be difficult to expose reliable metadata on Next Versions as a decision on the Next Version of an asset is unlikely to have been made when the current one is published.  We could rely on previous assets being republished with updated Next Version metadata but this is somewhat clumsy.  It may be better to use Previous Versions exposed by newer assets to infer the corresponding Next Versions on older assets as this previous/next relationship between a pair of assets should be commutative

And finally:

  1. Contexts.  In Listpoint we publish a large number of Code Lists some of which are widely used national standards and some of which are specific to particular application systems.  Rather than running a central team of stewards to manage all code lists we devolve maintenance down to the people who are most closely involved with each Code List and do not actively promote any Code Lists as being ‘standards’ from the centre.  This is a somewhat different from the more usual centralized ‘de jure’ standards setting approach. Instead we encourage people who are trying to solve application integration problems (mostly Police Forces at present) to create a Context representing the application system at the source end of their integration and a Context representing the application system at the target end of their integration.  A Context is therefore a proxy or profile for the collection of Code Lists that are used by an application system.  If a large number of application systems all use a particular Code List (e.g. Gender v2) then we can say that Gender v2 has become a ‘de facto’ standard.  Listpoint is effectively trying to find order in an anarchic environment by crowd-sourcing. We started on this journey quite recently but already we are seeing people beginning to agree on standardisations they can make to their own code lists so they can be shared more effectively in other Contexts.
    There are standards groups within some organizations and we support them by allowing Contexts to be created to represent a Data Standard instead of an Application.  So standards can still be promoted but application developers are not obliged to use them – they still have freedom to do their own thing if they need to. Listpoint uses Contexts only to record the Code Lists that are used in a particular Application or Standards ‘Context’.  However, I think there may be scope to extend the range of content types that can be referenced to include all the other sorts of Asset that CESAR could hold.  Application and Standard developers can then reference any asset that they either depend upon or found useful in creating their product. In Listpoint we use these references to send out email alerts to the owners of all referencing Contexts when a new version of a code list is published on which they depend. This is part of the incentive for people to contribute information on their various Contexts. The other incentive is that Listpoint provides mapping tools allowing code lists in different Contexts to be mapped together.




Subscribe to newsletter

You will receive news and links to the most interesting developments...