Support for implementation

JSON-LD context file

The JSON-LD context file is downloadable here.

Validation

SHACL

To support the check whether or not a catalogue satisfies the expressed constraints in this Application Profile, the constraints in this specification are expressed using SHACL [[shacl]]. Each constraint in this specification that could be converted into a SHACL expression has been included. As such this collection of SHACL expressions that can be used to build a validation check for data.

It is up to the implementers to define the validation they expect. Each implementation happens within a context, and that context is beyond the SHACL expressions here.

The shapes can be found here.

RDF representation

UML representation

XML schema representation

The XML schema representation from which the Evidence Of Disability has been build is available here.

The XML schema is based on the OOTS requirements and it allows some flexibility to include fields that Member States can add in addition to those foreseen in the OOTS requirements.

The XML schema is based on 3 parts:

• The subject part, to indicate the Person subject of the evidence
• The event/status part, to indicate the data about the event related to the subject
• Optional additional part, to add optional fields (attributes) for the evidence type, such as issuing date or issuing authority

All the parts with their respective attributes are optional (min cardinality set to 0).

The XML schema is based on the SEMIC Core Criterion and Core Evidence (CCCEV) specification, and on the Core Person vocabulary. In CCCEV, the Evidence is about an Agent that is the subject in the provided Evidence; in the case of Evidence of Birth, the Agent is the Person. An EvidenceOfBirthType is then an OOTSEvidenceType (based on CCCEV Evidence) by having the 3 parts:

• cv:isAbout. Since the value of cv:isAbout is a generic AgentType, in SDG a PersonType is defined as an AgentType with cv:FamilyName, cv:GivenName, cv:Sex and sdg:AttributeSet, that it means that is possible to add additional fields to the subject.
• sdg:Birth, defined by the OOTSBirthType, that includes cv:CountryOfBirth, cv:DateOfBirth, cv:PlaceOfBirth (as foreseen in OOTS requirements) and sdg:AttributeSet
• sdg:AttributeSet, that can contains many attributes, where the name, language and type fields could be defined for each attribute

The design of the XML schema is based on the Garden Of Eden Pattern where complex types and elements are defined globals so they can be reused.

Restrictions on the presence of fields and on their values is delegated to schematron file, that can vary on the XML consumer and could be provided by XML providers, such as those on code list. OOTS provides certain code list in Genericode format that can be used via schematron. Additional code list, such as the one of Sex in he current evidence, could be take from the the Publications Office Authority Tables.

Governance

Versioning governance

The serialisation will have:

• a dct:isReplacedBy referencing the new assets used instead and
• an adms:status indicating its deprecated status.

Governance requirements for re-used assets

In order for an asset to be considered for reuse within a SEMIC specification it can be requested by a community member or it requires to adhere to the following requirements:

• The asset is part of a recommendation by a major standards body or an EU institution.
• The asset is actively being maintained.

After being taken into consideration the asset will be validated in three steps:

• Syntax validation will be performed on the relevant artefacts.
• Constraint validation will be performed on the relevant artefacts.
• The PURI will be validated.

Lexicalisation rules

SEMIC uses and will use the RDFS lexicalisation for all of its specifications. More specifically:

• rdfs:label is used to provide a human-readable version of a resource's name.
• The usage of certain resource can be clarified in a skos:usageNote.