Core Standards and Specifications Vocabulary

Abstract

CSSV is a vocabulary describing standards and specifications used in software development. It is used by ELIS, the EIRA Library of Interoperability Specifications. It is an European Commission solution.

Introduction back to ToC

The CSSV is the vocabulary used for the information exchange related to standards and specifications amongst software solutions. It is also the key element for the development and maintenance of the EIRA Library of Interoperability Specifications (ELIS). The CSSV addresses semantic interoperability by reusing existing generic ontologies and vocabularies. This way, the semantics of common concepts and properties are agreed without having to re-discuss them. When concepts or properties have not been identified nor defined for the purposes pursued, they must be proposed either as extensions or from scratch.

The methodological approach followed for the development of the CSSV reuses the following ontologies and vocabularies:

• Data Catalogue Vocabulary (DCAT)
• Friend of a Friend (FOAF)
• The Organization Ontology
• DCMI Metadata Terms (DCTerms)
• The Profiles Vocabulary (PROF)
• Schema

Core Standards and Specifications Vocabulary: Overview back to ToC

This ontology has the following classes and properties.

Classes

• Application Profile
• Family
• Specification
• Standard

Object Properties

• Combined in
• Combines
• Configured in
• Configures
• Contact point
• Creator
• distribution
• Is maintained by
• Is recommended by
• Previous version
• Theme

Data Properties

• Access rights
• Access URL
• Acronym
• Alternative
• description
• Download URL
• identifier
• license
• rights
• Theme
• title
• Type
• Version

Core Standards and Specifications Vocabulary: Description back to ToC

The main class of the CSSV model is the “Specification”. As represented in the conceptual model of the CSSV, a Specification is an asset, since it inherits from the dcat:Dataset, which inherits from the dcat:Resource, defined as ‘a collection of data published or curated by a single agent and made available in one or more representations.’. A Specification can serve to multiple function, not merely limited to semantic assets (as ADMS defines), but also describes requirements; and these requirements, depending on their purpose and context of use, can converge into a Standard, an Application Profile, a Family or a collection of other specifications.

The CSSV model defines the Specification and three additional specialisations:

• Specification, which describes precise requirements that are needed for the implementation of a solution. A specification is not necessarily a standard.


• A Standard as a Specification that has reached a certain maturity and widespread adoption and potentially endorsed, meaning that is recognised and supported by a community or sanctioned by an authority. Normally, a Standard is a Specification that is part of a interoperable solution implementation.


• An Application Profile Profile as customisation of one or more existing specifications potentially for a given use case or a policy domain adding an end-to-end narrative describing and ensuring the interoperability of its underlying specification(s). By customisation, we understand the “addition of more specificity by identifying mandatory, recommended, and optional elements, as well as by defining controlled vocabularies to be employed”.


• A Family as a collection of interrelated and/or complementary specifications, standards or application profiles and the explanation of how they are combined, used, or both.

Optionally, the use of the dct:type property in cssv:Specification indicates the “type” of a specification, whether it represents a data specification, data profile, data artifact, or reference model etc. The dct:type property, as defined in the DCT vocabulary, may serve to complement and classify a specification according to its particular kind, function, or purpose. There exist referenced codelists provided by ADMS-AP and the Publications Office of the EU (PO) that may be reused.

When one of the specialisations of Specification does not adapt to a specific context and needs to work in conjunction with a other Specifications, the use of a collection of Specifications is highly recommended through the dcat:DatasetSeries. The dcat:DatasetSeries class represents a collection of datasets that are published separately, but share some characteristics that group them. The specialisation of a Specification are linked to other Specifications by using the property dcat:inSeries (being dcat:hasPart the inverse relation to it). Note that a collection of Specifications can also be hierarchical, and such collection can be a member of another collection of Specifications.

The use of dcat:DatasetSeries is not always limited to representing a specialisation of a Specification, it can also be applied to a Specification. Unlike a Family of Specifications, the Specifications within a collection are grouped without requiring an explicit relationship among them, allowing for a more flexible and loosely coupled collection. There are occasions where collections of Specifications are applied to a context or a domain in a specific “configuration”. Thus application profiles may conform sets of “themed” specifications. For this, the CSSV model uses the property “configures/includedIn” and the dcat:theme property pointing at a skos:Concept (i.e. a code, see the DCAT model above). It is important to note that the descendants of the specifications are all “disjoint”. Thus, Application Profiles and Families are Specifications that refer to or put together with other Specifications and/or Standards, but cannot themselves be considered Standards. This entails that an individual of an application profile or family cannot be a standard, but does not preclude that, in time, the application profile or the family can become standards. If that were the case then individuals of cssv:Standard would be created to represent the standardisation of those specifications that are Application Profiles and Families.

Another aspect to consider is the evolution of a Specification. One Specification, in time, may become a Standard. In these cases, the authority (author) that defined the Specification may be different from the one that creates and maintains artefacts out of the Standard. Think, for example, of the artefacts produced, maintained and distributed by the Publications Office of the EU (OP) in its site EU Vocabularies: all these artefacts are defined by other authorities (e.g. the ISO), whilst the artefacts (e.g. the controlled vocabularies expressed in SKOS, XML, GeneriCode, XML, etc.) are supplied by the OP. For this, the CSSV uses the properties dct:creator and cssv:isMaintainedBy; where dct:creator (as for dct:publisher) DCT associates a URL as property range.

The maintainer of a Specification is a foaf:Agent, which allows great flexibility to the CSSV model as foaf:Agent is the base class in many ontologies. Moreover, a foaf:Agent may represent a member state that recommends the a Specification; the property cssv:isRecommendedBy is used for this end. The CSSV puts forward the reuse of the Core Person Vocabulary (CPV) and the Organization Ontology (W3C Org) for this purpose. Also, the foaf:Agent also provides the contact point of the specification.

Concerning the intellectual property rights (IPR), they are covered by the fact that a Specification which is a dcat:Resource and it allows to define the dct:license and dct:rights. Further extensions of licencing matters and derivation of IPR can be modelled using PROV-O.

A new shift to CSSV 2.0 is the discontinuation of cssv:ApplicationProfile as a subclass or direct specialisation of prof:Profile. While this interpretation is technically compatible with the definition provided in the PROF specification, where a profile is understood as, “a specification that constrains, extends, combines, or provides guidance or explanations about the usage of other specifications”, it surpasses the broader field of application foreseen for the CSSV. To overcome this, the CSSV introduces a more flexible and semantically neutral mechanism based on dcat:qualifiedRelation, allowing relationships between Specifications and a prof:Profile. This approach replaces the previous direct link between prof:Profile and cssv:ApplicationProfile, ensuring that the connection remains optional and context-driven rather than structural. This will avoid to not enforce to many constrains and links that are not semantically necessary. Since ideally CSSV wants to relate concepts that are similar to each other without enforcing how things are used, nor creating unnecessary restrictions for existing ontologies. To ensure clarity, the use of dct:relation within each dcat:qualifiedRelation instance is made mandatory.

In summary, this new structure ensures conceptual clarity and traceability within the CSSV model, allowing consistent classification and evolution of specifications across different levels of maturity and reuse.