Create service definition that works for most use-cases

[lukeshope]

Currently thinking...

• receiver service
  • redirection to other interested parties
  • queue management
• adapter services
  • pull data from other systems and services (e.g. sensor manufacturers' systems)
  • transform data
  • create records in the discovery and descriptor service
  • auto-generate links to the context service
  • send data to be archived
  • perform updates as necessary based on policies (i.e. not all upstream changes should propagate)
• archival service
  • efficient storage of timeseries data of varying types
  • json
  • numeric
  • string
  • events
  • boolean
  • generation of bulk download files (to keep ODI types happy)
  • access via API to data from date ranges with JSON-LD and CSV serialisations
  • access via API to thresholds, exceedances, etc.
  • very basic rollups and aggregation
• discovery and descriptor service
  • API and potentially very simple UI (more like a HTML serialisation from the API)
  • spatial lookups (radius, bbox, etc.)
  • filtering based on triples
  • catalogue
  • compatibility or some alignment with other systems (e.g. Hypercat?)
  • API with JSON-LD serialisations
  • W3C SSN ontology
  • potential for alignment with W3C WoT thing description
• context service
  • needs spatial and filtering functionality from discovery and descriptor service
  • could be provided at a national level instead of each UO?
  • not intended to hold UO data, but to provide static/semi-static link targets
  • descriptions and IRIs for
  • roads, postcodes, buildings
  • administrative geographies
  • institutions and organisations
  • should provide links to other LD sources (e.g. Ordnance Survey, Wikidata)
• apps
  • domain-specific functionality (e.g. air quality) should be handed off to more appropriate systems

[lukeshope]

Most of these issues have now been addressed in the skeleton standard document.