DSP Application Profile

dcat:Dataset

dcat:Dataset represents a collection of data, published or curated by a single agent or identifiable community. The notion of dataset in DCAT is broad and inclusive, with the intention of accommodating resource types arising from all communities. Data comes in many forms including numbers, text, pixels, imagery, sound and other multi-media, and potentially other types, any of which might be collected into a dataset.

– DCAT spec

We use Datasets for each conceptual group of data.

Each dataset should be part of a dcat:Catalog, which should be specified using dcat:dataset on the dcat:Catalog.

Temporal datasets are ones which only relate to, or are only valid for, a specific period of time. For temporal datasets, dcterms:temporal must be used to indicate that period of time.

A dcat:Dataset may also be a skos:ConceptScheme.

When we import versioned datasets, if each version of dataset also contains data from previous versions, we should import and keep only the latest version.

Otherwise, we should make multiple versions of a dataset available. The related datasets should be linked together using dcat:previousVersion and dcat:nextVersion. The latest version should be linked to using dcat:hasCurrentVersion in the dcat:Catalog which contains the versioned datasets.

dcterms:temporal [
  a dcterms:PeriodOfTime ;

  # Start date is inclusive, end date is exclusive.
  # Dataset does not apply from 2026-01-01 onwards.

  dcat:startDate "2025-01-01"^^xsd:date ;
  dcat:endDate "2026-01-01"^^xsd:date ;
];

dcterms:source [
  rdfs:label ""@en
]

skos:editorialNote "Missing data for X due to Y.
Data applies for the year 2020 but 2020-12 is
present in 2021's dataset due to Z."@en

dcat:DataService

A collection of operations that provides access to one or more datasets or data processing functions.

– DCAT spec

A dcat:DataService may also be a dcat:Catalog. The distinction between a plain catalogue and a data service is fuzzy. A general rule of thumb is, if the catalog provides access to dcat:Distributions, a catalogue is probably also data service. If properly representing the dataset would require using dcterms:temporal, dcterms:spatial, or dcat:inSeries, it should be represented with a dcat:Dataset.

dcat:Catalog

dcat:Catalog represents a catalog, which is a dataset in which each individual item is a metadata record describing some resource; the scope of dcat:Catalog is collections of metadata about datasets, data services, or other resource types.

– DCAT spec

Each dataset should be part of a dcat:Catalog, which should be specified using dcat:inCatalog on the dcat:Dataset.

A Catalog is a specialisation of dcat:Dataset, adding only the predicate dcat:dataset to specify its members.

dcat:Distribution

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).

– DCAT spec

Catalogue JSON-LD mapping

dcat:contactPoint [
  a vcard:Organization ;

  vcard:hasTitle "The"@en ;
  vcard:hasOrganisationName "Environment Agency"@en ;
  vcard:hasURL <https://www.gov.uk/ea> ;
  vcard:hasEmail <mailto:enquiries@environment-agency.gov.uk> ;
  vcard:hasRole "Executive non-departmental public body"@en ;
] ;

Our modelling approach using DCAT3

The diagram above visualises how we model dcat:Catalogs and dcat:Datasets. At the top level is environment.data.gov.uk which is a dcat:Catalog, it contains other dcat:Catalogs such as the ecology-and-fish or the data-requirements catalog. Each of these sub-catalogs generally contain dcat:Datasets, but they can also contain other dcat:Catalogs. In the diagram above the only distinct dcat:Catalog is the environment.data.gov.uk catalog, and the only distinct dcat:Datasets are the skos:ConceptSchemes. While we explicitly type each dcat:Datasets only as a dcat:Datasets the use of certain predicates such as dcat:inCatalog or dcat:themeTaxonomy results in the dcat:Dataset being inferred (by an RDF reasoner) to also be a dcat:Catalog, we have made this choice as they should be seen as a dcat:Dataset resource first and foremost.

skos:ConceptScheme

A SKOS concept scheme can be viewed as an aggregation of one or more SKOS concepts

– SKOS spec

A skos:ConceptScheme must also be a dcat:Dataset.

A skos:ConceptScheme must also contain at least one skos:Concept using the skos:topConceptOf predicate.

skos:Concept

A SKOS concept can be viewed as an idea or notion; a unit of thought. However, what constitutes a unit of thought is subjective, and this definition is meant to be suggestive, rather than restrictive.

– SKOS spec

A skos:Concept must be linked to at least one skos:ConceptScheme using skos:inScheme, and may be linked to any number of those same concept schemes with skos:topConceptOf.

A skos:Concept should use skos:broader and skos:narrower to indicate hierarchy.

skos:Collection

SKOS concept collections are labeled and/or ordered groups of SKOS concepts.

Collections are useful where a group of concepts shares something in common, and it is convenient to group them under a common label, or where some concepts can be placed in a meaningful order

– SKOS spec

When appropriate, skos:Concepts are grouped together into skos:Collections with skos:member. This can be nested, such that a skos:Collection may contain other skos:Collections.

A collection can be treated as a dataset, therefore it may be a dcat:Dataset.

Collections do not support hierarchy. If relationships are required between skos:Concepts across multiple skos:ConceptSchemes, those concepts should be duplicated into another scheme, and skos:exactMatch used to indicate they are equivalent, then skos:narrower and skos:broader indicate as usual the hierarchy.

Concept JSON-LD mapping

Concepts worked example

As of writing, the UK's administrative geographies are hierarchically organised according to the following diagram:

We would represent this with the following skos:ConceptScheme:

• The UK is broken down into Countries, each being a skos:topConceptOf of the UK, one of which being Wales

• Wales is broken down into many skos:narrower Unitary Authorities

• Each Unitary Authority is broken down into many skos:narrower Electoral Wards

• Each Electoral Ward is broken down into many skos:narrower Communities

A subgraph of this relationship could be represented by the following RDF, using Government Statistical Service (GSS) codes for notation:

@prefix ex: <http://www.example.org/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

ex:UnitedKingdomAdministrativeRegions a skos:ConceptScheme ;
    skos:prefLabel "United Kingdom Administrative Regions"@en .

ex:W92000004 a skos:Concept ;  # Country
    skos:inScheme ex:UnitedKingdomAdministrativeRegions ;
    skos:notation "W92000004" ;
    skos:prefLabel "Cymru"@cy, "Wales"@en ;
    skos:note "Established in 1057"@en ;
    skos:topConceptOf ex:UnitedKingdomAdministrativeRegions .

ex:W06000015 a skos:Concept ;  # Unitary Authority
    skos:inScheme ex:UnitedKingdomAdministrativeRegions ;
    skos:broader ex:W92000004 ;
    skos:notation "W06000015" ;
    skos:prefLabel "Cyngor Caerdydd"@cy, "Cardiff Council"@en .

ex:W05001274 a skos:Concept ;  # Electoral Ward
    skos:inScheme ex:UnitedKingdomAdministrativeRegions ;
    skos:broader ex:W06000015 ;
    skos:notation "W05001274" ;
    skos:prefLabel "Cathays"@cy, "Cathays"@en .

ex:W06000011 a skos:Concept ;  # Unitary Authority
    skos:inScheme ex:UnitedKingdomAdministrativeRegions ;
    skos:broader ex:W92000004 ;
    skos:notation "W06000011" ;
    skos:prefLabel "Cyngor Abertawe"@cy, "Swansea Council"@en .

ex:W39000434 a skos:Concept ;  # Electoral Ward and Community
    skos:inScheme ex:UnitedKingdomAdministrativeRegions ;
    skos:broader ex:W06000011 ;
    skos:notation "W39000434" ;
    skos:prefLabel "Castell"@cy, "Castle"@en .

Each region, regardless of their position in the hierarchy, is skos:inScheme the skos:ConceptScheme containing “administrative regions". Their hierarchical relationships are in this case represented by the lower administrative regions using skos:broader to refer to the higher region they belong. Equally valid, the higher administrative regions could use skos:narrower to refer to all the lower regions contained within them.

geo:FeatureCollection

A collection of individual Features

– OGC GeoSPARQL spec

An instance of geo:FeatureCollection should have at least one outgoing rdfs:member relation

– OGC GeoSPARQL spec

We use geo:FeatureCollections to group related geographic features, such as water quality sampling points, or administrative regions.

Each geo:FeatureCollection must also be a dcat:Dataset, and follow all requirements of a dcat:Dataset.

When a geo:FeatureCollection represents commonly understood geographies, e.g. cities or countries, geo:FeatureCollection should also be a skos:ConceptScheme, in which case it should follow all requirements of a skos:ConceptScheme.

geo:Feature

Feature represents a uniquely identifiable phenomenon, for example a river or an apple. While such phenomena (and therefore the Features used to represent them) are bounded, their boundaries may be crisp (e.g., the declared boundaries of a state), vague (e.g., the delineation of a valley versus its neighboring mountains), and change with time (e.g., a storm front). While discrete in nature, Features may be created from continuous observations, such as an isochrone that determines the region that can be reached by ambulance within 5 minutes

– OGC GeoSPARQL spec

We use geo:Features to represent individual geographic features or regions, such as a city, or an administrative region.

When a geo:Feature represents a commonly understood geography, e.g. a city or country, it should also be a skos:Concept, in which case it should follow all requirements of a skos:Concept.

Where a conceptual geography has inexact or unavailable boundaries, it is typed as a skos:Concept rather than a geo:Feature. Its spatial nature can be inferred from context: where other geo:Feature instances are declared geo:sfWithin it, users may treat it as an implicit geo:Feature.

geo:Geometry

A coherent set of direct positions in space. The positions are held within a Spatial Reference System (SRS).

– OGC GeoSPARQL spec

We use geometries to store the precise bounding area of a geography, in well-known text format using the geo:asWKT predicate. Usually, this geometry should be encoded as a MultiPolygon, to support geographies composed of multiple distinct shapes. For example, islands

For convenience, we should provide the bounding box and centroid of a geography with geo:hasBoundingBox and geo:hasCentroid respectively.

Geometries should be provided with the following shapes and anchors if coined:

geo:asWKT "<http://www.opengis.net/def/crs/EPSG/0/4326> POINT(-1.150 52.9534)"^^geo:wktLiteral"

Geography JSON-LD mapping

GeoJSON mapping

When transferring geographies via our APIs, we may support using GeoJSON (MIME application/geo+json) to encode them, if it is requested via the Accept header.

RDF resources and attributes and should be provided in the properties of the GeoJSON object, according to the following mapping:

Each skos:Concept assigned to the geo:Feature should also be present in the properties of the GeoJSON object, with the camelCase name of its skos:ConceptScheme used as the key, and the skos:Concept's URI as the value. See the worked example below.

The properties should generally not contain complex data types such as objects. Arrays may be used when appropriate.

Geography worked example

The Ecology and Fish (Benthic dataset) sampling point endpoint for the sampling point 135967-v1 returns the following JSON-LD response, which has been cut down for simplicity:

{
  "id": "http://environment.data.gov.uk/ecology-and-fish/benthic/sampling-point/135967-v1",
  "@type": "sosa:FeatureOfInterest",
  "geometry": {
    "@id": "http://environment.data.gov.uk/ecology-and-fish/benthic/sampling-point/135967-v1#Geometry",
    "@type": "geo:Geometry",
    "asWKT": "<http://www.opengis.net/def/crs/EPSG/0/27700> POINT(430031 606343)"
  },
  "seaArea": "http://environment.data.gov.uk/ecology-and-fish/benthic/sea-areas/Concept/northumberland",
  "notation": "135967-v1",
  "agencyArea": "http://environment.data.gov.uk/ecology-and-fish/benthic/agency-areas/Concept/national-marine",
  "reportingArea": "http://environment.data.gov.uk/ecology-and-fish/benthic/reporting-areas/Concept/north-east",
  "waterbodyType": "http://environment.data.gov.uk/ecology-and-fish/benthic/waterbody-types/Concept/wbcw",
  "wfdWaterbodyId": "http://environment.data.gov.uk/ecology-and-fish/benthic/wfd-waterbodies/Concept/GB650301500001"
}

The same subject is transformed into the following GeoJSON when requested:

{
  "type": "Feature",
  "geometry": {
    "coordinates": [
      -1.527978174,
      55.350201484
    ],
    "type": "Point"
  },
  "properties": {
    "notation": "135967-v1",
    "@type": "sosa:FeatureOfInterest",
    "seaArea": "http://environment.data.gov.uk/ecology-and-fish/benthic/sea-areas/Concept/northumberland",
    "agencyArea": "http://environment.data.gov.uk/ecology-and-fish/benthic/agency-areas/Concept/national-marine",
    "reportingArea": "http://environment.data.gov.uk/ecology-and-fish/benthic/reporting-areas/Concept/north-east",
    "waterbodyType": "http://environment.data.gov.uk/ecology-and-fish/benthic/waterbody-types/Concept/wbcw",
    "wfdWaterbodyId": "http://environment.data.gov.uk/ecology-and-fish/benthic/wfd-waterbodies/Concept/GB650301500001"
  }
}

Classes

A new class is of type owl:Class and the following predicates are used to describe it:

Below is the pattern that we would use for defining an owl:Class

@prefix ex: <http://example.org/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .

ex:CustomClass a owl:Class ;
    rdfs:label "Custom Class"@en ;
    rdfs:comment "A domain-specific class" ;
    rdfs:subClassOf ex:ParentClass .

Predicates

A new predicate can be of type owl:ObjectProperty (the range of the predicate is a URI) or of type owl:DatatypeProperty (the range of the predicate is a literal)

Below is the pattern that we would use for defining an owl:ObjectProperty and an owl:DatatypeProperty

@prefix ex: <http://example.org/> .
@prefix owl: <http://www.w3.org/2002/07/owl#> .
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

ex:customObjectProperty a owl:ObjectProperty ;
    rdfs:label "Custom Object Property"@en ;
    rdfs:comment "A custom object property" ;
    rdfs:domain ex:DomainClass ;
    rdfs:range ex:RangeClass .

ex:customDatatypeProperty a owl:DatatypeProperty ;
    rdfs:label "Custom Datatype Property"@en ;
    rdfs:comment "A custom datatype property" ;
    rdfs:domain ex:DomainClass ;
    rdfs:range xsd:string .

DEFRA Linked Data Domain Model

The 'DEFRA Linked Data Domain Model' is an effort to create a linked data domain model for the Defra Group. It aims to provide a structured, machine-readable representation of regulatory and water-related data, supported by a core ontology. The model is currently under development and can be viewed at https://github.com/agrimetrics/defra-ontology

sosa:FeatureOfInterest

the entity whose property is being estimated by an Observation, or whose property is being manipulated by an Actuation, or which is being sampled or transformed by an act of Sampling

– SOSA/SSN 2023 spec

sosa:FeatureOfInterests that have a geographical location should also be a geo:Feature. Generally they should have a Point or MultiPolygon geometry. For example, a sampling point in the water quality explorer is a single location where samples are consistently taken from. This geo:Feature should be described by a Point.

sosa:Procedure

workflow, protocol, plan, algorithm, or computational method specifying how to make an Execution

– SOSA/SSN 2023 spec

We use sosa:Procedure to provide additional information about the sosa:Sampling method. The sosa:Procedure should either be a blank node or an anchor e.g. http://environment.data.gov.uk/ecology-and-fish/benthic/sampling-point/135967-v1/sample/514432-v1-rA-a527041#procedure. Where it makes sense to create a vocabulary of sosa:Procedures then each sosa:Procedure will be defined as a skos:Concept within a skos:ConceptScheme.

sosa:Property

identifiable quality of features of interest that can be observed or acted upon

– SOSA/SSN 2023 spec

A sosa:Property must also be a skos:Concept, to provide additional contextual information about the property, as well as its relationships to other properties. skos:notation should be used to indicate the code of the property, if one exists.

A sosa:Property must also be a iop:Variable.

sosa:Sampling

act of carrying out a SamplingProcedure using a Sampler to create one or more Samples of a FeatureOfInterest

– SOSA/SSN 2023 spec

A sosa:Sampling represents a snapshot from which sosa:Samples can be taken, and those in turn are observed to produce sosa:Observations.

sosa:Sample

Samples are typically subsets or extracts from an entity or feature. Every sample is expected to (eventually) be the feature of interest of an Observation

– SOSA/SSN 2023 spec

A sample is a result of a sampling of a feature of interest, from which observations can be made.

Each sample must have a related sosa:Sampling to provide additional contextual information about the sample.

sosa:ObservationCollection

An instance of ObservationCollection represents a container for a set of data derived from observations. This broadly corresponds with the class dcat:Dataset from the Data Catalog Vocabulary

– SOSA/SSN 2023 spec

A sosa:ObservationCollection must group all sosa:Observations made on a single sosa:Sample, if there is more than one observation for the given sample.

sosa:Observation

act of carrying out an ObservingProcedure using a Sensor to estimate or calculate a value of an observable Property of a FeatureOfInterest

– SOSA/SSN 2023 spec

An observation has a result from a sample for a property of a given feature of interest.

sosa:hasResult [
  a qudt:QuantityValue ;
  qudt:hasUnit unit:DEG_C ;
  qudt:value 24.9 ;
] ;

iop:VariableSet

An aggregation class to group a set of variable for a specific purpose.

– I-ADOPT Framework ontology

Together with sosa:ObservationCollections, we use iop:VariableSets to describe all possible variables that may be observed from a single sample.

iop:Variable

A description of something observed or derived, minimally consisting of an ObjectOfInterest and its Property.

– I-ADOPT Framework ontology

A variable is directly associated with a sosa:Observation to describe the meaning of its sosa:hasResult.

Describes an iop:Property of an iop:Entity, potentially involving an iop:Constraint, a contextually related iop:Entity, and iop:StatisticalModifier.

iop:Property

A type of a characteristic of the ObjectOfInterest.

– I-ADOPT Framework ontology

For example: depth, temperature, sex, width.

A iop:Property must also be a skos:Concept. This allows us to describe them in a consistent manner to other concepts.

A iop:Property should be a qudt:QuantityKind. We should extensive vocabulary it provides when possible, and define our own qudt:QuantityKinds when necessary.

iop:Entity

An object or process that has a role in an observation.

– I-ADOPT Framework ontology

For example: a river, or a fish.

A iop:Entity must also be a skos:Concept. This allows us to describe them in a consistent manner to other concepts.

iop:Constraint

A Constraint limits the scope of the observation and confines the context to a particular state. It describes properties of the involved entities that are relevant to the particular observation.

– I-ADOPT Framework ontology

A iop:Constraint must also be a skos:Concept. This allows us to describe them in a consistent manner to other concepts.

iop:StatisticalModifier

The statistical modifier describes which statistical measure has been applied.

– I-ADOPT Framework ontology

For example: mean, average, minimum, maximum, count.

We prioritise the use of SDMX CL_STATISTICAL_OPERATION definitions for statistical operations. When referring to statistical modifiers or aggregation methods, these always point to our own Concept Scheme for statistical methods or operations. Each concept within this scheme implicitly aligns with SDMX notations. If SDMX is not applicable and a precise URI definition exists, such as those provided by DDI, we use skos:exactMatch to link our concept to the corresponding DDI URI.

If no suitable term exists within SDMX, we fall back to the DDI Controlled Vocabulary for Aggregation Methods. Where no appropriate definition is available there either, we create a new concept. Such concepts are defined as both a skos:Concept and an iop:StatisticalModifier.

Observation JSON-LD mapping

Observation worked example

The Ecology and Fish API currently in development describes observational data using the SOSA/SSN, QUDT and I-ADOPT vocabularies. The cut down example below describes an observation describing the count of a particular taxon of fish in a given sample. The sosa:hasResult block breaks down the raw result into its value, units and other additional information. The sosa:observedProperty block breaks down the observation property into individual components using I-ADOPT.

 {
 "id": "http://environment.data.gov.uk/ecology-and-fish/benthic/sampling-point/135966-v1/sample/514427-v1-rA-a527036/observation/taxon=NBNSYS0100049570@abundance,statistical-modifier=count",
 "@type": "sosa:Observation",
 "hasResult": {
   "id": "http://environment.data.gov.uk/ecology-and-fish/benthic/sampling-point/135966-v1/sample/514427-v1-rA-a527036/observation/taxon=NBNSYS0100049570@abundance,statistical-modifier=count#result",
   "@type": "qudt:QuantityValue",
   "hasUnit": "unit:INDIV",
   "numericValue": 2,
   "standardUncertainty": null
 },
 "observedProperty": {
   "id": "http://environment.data.gov.uk/ecology-and-fish/benthic/sampling-point/135966-v1/sample/514427-v1-rA-a527036/observation/taxon=NBNSYS0100049570@abundance,statistical-modifier=count#observedProperty",
   "@type": [
     "sosa:Property",
     "iop:Variable"
   ],
   "hasProperty": "quantitykind:Count",
   "hasConstraint": [],
   "hasObjectOfInterest": "http://environment.data.gov.uk/ecology-and-fish/benthic/taxa/Concept/NBNSYS0100049570",
   "hasStatisticalModifier": "https://environment.data.gov.uk/ecology-and-fish/statistical-modifiers/Concept/count"
 }
}

CSV-W

CSV-W (CSV on the Web) is a standard for describing and clarifying the content of CSV tables. While CSV is one of the most common formats for sharing tabular data, it contains very little information about the meaning or structure of the data it holds. CSV-W addresses this by allowing datasets to be accompanied by structured metadata (a .json metadata file). This metadata file can describe column data types, identifiers, relationships between tables, and links to external vocabularies. As a result the data becomes more interpretable and reusable across systems. CSV-W enables tabular data to be transformed into RDF by defining how rows and columns map to RDF triples.

Our datasets will be accessible through a CSV endpoint e.g. https://environment.data.gov.uk/water-quality/sampling-point/TH-PBRR0047.csv, and if users require the JSON metadata file then the JSON file will be accessible via a HTTP GET request with an Accept header of application/csvm+json.

Cubes worked example

Consider the following CSV table containing water quality observations:

Using the table above we would define a JSON metadata file to describe this CSV as follows:

{
  "@context": "http://www.w3.org/ns/csvw.jsonld",
  "url": "https://environment.data.gov.uk/water-quality/sampling-point/TH-PBRR0047.csv",
  "dcterms:title": "Sample Dataset",
  "dcterms:description": "A dataset containing observations at the TH-PBRR0047 Sampling Point.",
  "dcterms:publisher": "https://environment.data.gov.uk",
  "dcterms:license": "https://www.nationalarchives.gov.uk/doc/open-government-licence/version/3/",
  "dcterms:created": "2026-03-17T14:32:05Z",
  "tableDirection": "ltr",
  "tableSchema": {
    "columns": [
      {
        "name": "id",
        "titles": "id",
        "datatype": "string",
        "aboutUrl": "{id}"
      },
      {
        "name": "samplingPoint.notation",
        "titles": "samplingPoint.notation",
        "datatype": "string"
      },
      {
        "name": "Area",
        "titles": "Area",
        "datatype": "string",
        "propertyUrl": "http://purl.org/linked-data/sdmx/2009/dimension#refArea"
      },
      {
        "name": "Phenomenon Time",
        "titles": "Phenomenon Time",
        "datatype": "dateTime",
        "propertyUrl": ["http://purl.org/linked-data/sdmx/2009/dimension#refPeriod", "http://www.w3.org/ns/sosa/phenomenonTime"]
      },
      {
        "name": "determinand.prefLabel",
        "titles": "determinand.prefLabel",
        "datatype": "string"
      },
      {
        "name": "result",
        "titles": "result",
        "datatype": "decimal",
        "propertyUrl": ["http://purl.org/linked-data/sdmx/2009/measure#obsValue"]
      },
      {
        "name": "unit",
        "titles": "unit",
        "datatype": "string",
        "propertyUrl": ["http://purl.org/linked-data/sdmx/2009/attribute#unitMeasure", "http://qudt.org/schema/qudt#hasUnit"]
      }
    ]
  }
}

Catalogue data endpoints

Concept data endpoints

Geography data endpoints

Custom data endpoints

Observation data endpoints

Key patterns:

• Nested access: Drill down from sampling point → sample → observation

• Bulk access: Query parameters for filtering (e.g. /data/observation?pointNotation={id})

• Pagination: All endpoints paginated using Hydra; in-memory formats (JSON-LD, GeoJSON) have lower max limits than streaming formats (CSV, JSON-Lines)

Cube data

Protected endpoints

The following paths are reserved and cannot be used as dataset names, class names, or instance names.

Hydra

We use Hydra to support pagination in our RESTful API endpoints, to assert that the pagination objects are all of a set type.

Hydra's memberAssertion functionality is used to conveniently inject additional predicates into members of collections, when it would be tedious or error-prone to add the triple explicitly for each member.

Hydra must not be used for pagination for GeoSPARQL data, instead we must use the query parameter system as defined in the GeoSPARQL specification, section F.2.

JSON-LD contexts

JSON-LD context worked example

In Turtle syntax:

@base <http://example.org/> .
@prefix skos: <http://www.w3.org/2004/02/skos/core#> .

<Some-Concept> a skos:Concept ;
  skos:notation "some-concept" ;
  skos:prefLabel "An English name"@en, "Enw Cymreig"@cy ;
  skos:altLabel "Alternative name"@en ;
  skos:broader <Parent-Concept> .

<Parent-Concept> a skos:Concept ;
  skos:notation "parent-concept" ;
  skos:prefLabel "Parent concept name"@en ;

JSON-LD representation:

{
  "@context": "http://example.org/context.json-ld",
  "id": "http://example.org/Some-Concept",
  "type": "skos:Concept",
  "notation": "some-concept",
  "prefLabel": [
    { "value": "An English name", "language": "en" },
    { "value": "Enw Cymreig", "language": "cy" }
  ],
  "altLabel": { "value": "Alternative name", "language": "en", "direction": "ltr" },
  "broader": {
    "id": "http://example.org/Parent-Concept",
    "type": "skos:Concept",
    "notation": "parent-concept",
    "prefLabel": { "value": "Parent concept name", "language": "en", "direction": "ltr" }
  }
}