1. QoS Metadata Status 106th OGC Technical Committee Orléans, France
Ilkka Rinne
21st March 2018
Copyright © 2018 Open Geospatial Consortium

2. XML Schemas (Common, WMS, WFS)
Current draft versions are available at
A couple of examples of WMS 1.3 and WFS 2.0 Capabilities documents with QoS metadata are available at
Content:
Operating info (when the service is stated to be available and is it operational = stable & reliable).
General QoS statements applicable to the whole service.
Operation-specific QoS statement with restricted “representative” example operations.
Link to maintenance window / break feed (iCalendar, RSS, Atom etc.)
Copyright © 2018 Open Geospatial Consortium

3. Copyright © 2018 Open Geospatial Consortium
UML Diagrams
Some initial reverse-engineering (XML Schema -> UML) done, but this is still too much of work-in-progress to present.
Useful exercise to clarify the XML Schema types and elements.
Possibly the right level to express the QoS metadata content and structure, if the XML Schemas are too detailed of not applicable (WFS 3 / JSON)
Will continue this work, any ideas how to collaboratively do UML Class Diagrams using Github?
Copyright © 2018 Open Geospatial Consortium

4. Copyright © 2018 Open Geospatial Consortium
Metrics Definitions
Initial definitions of a few QoS metrics and the operational status expressed in SKOS (RDF) are available at
and
A beta version of OGC definitions service is up at this is probably the right place to publish the metrics and other QoS code lists eventually.
Copyright © 2018 Open Geospatial Consortium

5. WFS 3.0 and the new OGC Service Architecture – QoS Implications
106th OGC Technical Committee
Orléans, France
Ilkka Rinne
21st March 2018
Copyright © 2018 Open Geospatial Consortium

6. Copyright © 2018 Open Geospatial Consortium
WFS 3.0 Overview
Break free of the HTTP-RPC-with-XML-only-payloads legacy and specify a modernized service that aligns with the current architecture of the Web and the Spatial Data on the Web Best Practices.
No content encoding mandatory in the core, designed with HTML, GeoJSON and GML Simple Features in mind.
Dataset & resource oriented: a WFS 3 core endpoint is one distribution of a dataset, may provide several collections of features originating from the dataset with very basic filter/search capability (bbox & time).
OpenAPI or similar API definition instead of OGC Capabilities document. Minimize OGC/WFS specific components.
Highly modular: minimal core with many extensions expected. Machine-readable conformance statements provided.
WFS 3 endpoint can be decorated over an existing API or combined with other resources & operations.
Copyright © 2018 Open Geospatial Consortium

7. Copyright © 2018 Open Geospatial Consortium
QoS Implications
Reusing OpenAPI and other widely used Web API standards and technologies requires / enables the use of non-OGC specific QoS metrics.
How QoS metadata could/should be expressed for generic OpenAPI services?
QoS Requirements/recommendations need to implementable by both current style OGC Web Services and OpenAPI-like services.
QoS metadata for WFS 3 not likely to be included in the core.
WFS 3 QoS extension would probably introduce a dedicated API endpoint providing the QoS metadata.
Formats to support: HTML, JSON, (XML?)
Preferable not to bind it tightly to OpenAPI
Copyright © 2018 Open Geospatial Consortium

8. Discussion: QoS Metadata
QoS Metadata contents:
Communicate expected QoS metric values for a service in a machine readable form, including expected QoS metric values for “representative requests” optionally with example/limited ranges of request parameter values.
Use well-defined QoS metric definitions.
Communicate the operating hours of the service (if not 24/7/365).
Link to maintenance windows / breaks feed / calendar? (operation anomaly feed)
Goal: enable automatic QoS evaluation/monitoring for the conformant service endpoints.
Define an abstract data model applicable to both current OWS Common (Capabilities document) and future WFS 3 style services?
Copyright © 2018 Open Geospatial Consortium

9. Copyright © 2018 Open Geospatial Consortium
DWG Role - QoS Metadata?
Create an OGC Best Practice Document within the QoSE DWG:
Keep it clear of W*S specific implementation details.
Include user centric use cases and expected client-server communication scenarios using the provided QoS metadata.
Include abstract requirements for the content and structure of QoS metadata conformant services have to be able provide to the service users.
Include Admin UI requirements for the conformant software products to insert and modify the provided QoS metadata for the specific W*S service endpoints?
Use the Best Practice process within the OGC to discuss and agree on the applicability of requirements with the relevant SWGs.
Scope the requirements in a way that does not require changes in the existing Standards, if possible.
Create an OGC Discussion Paper capturing only the key use cases and user requirements for QoS metadata.
Do not go into details on the QoS metadata to provide, or the technical requirements for publishing and maintaining the data.
Use the Discussion Paper to communicate the user need across the OGC SWGs
Leave it up to the SWGs on if and how to proceed with the W*S specific implementation of the QoS Metadata provision.
Copyright © 2018 Open Geospatial Consortium

10. Review of the 1st Year of the QoSE DWG and the Work Plan for 2018
106th OGC Technical Committee
Orléans, France
Ilkka Rinne
21st March 2018
Copyright © 2018 Open Geospatial Consortium

11. Copyright © 2018 Open Geospatial Consortium
Work planned for 2017
Common QoSE terms and concepts (done)
QoS metrics, indicators and capabilities extensions for OWS, phase I (in progress)
QoSE API and reporting language (not started?)
Discussion paper/best practice for ensuring QoE of OGC Web Services (done)
OGC member survey - methods and metrics for evaluating QoS (done)
Copyright © 2018 Open Geospatial Consortium

12. Copyright © 2018 Open Geospatial Consortium
Achievements in 2017
Initial list of Terms & concepts voted for and accepted internally in July 2017, see
QoS metrics survey for the OGC members announced in August, ~ 20 responses received.
OGC “Ensuring Quality of User Experience with OGC Web Mapping Services – Discussion Paper” was approved for release by the TC in Feb 2018, release expected in late March – early April.
Copyright © 2018 Open Geospatial Consortium

13. Copyright © 2018 Open Geospatial Consortium
Work for 2018?
QoS Metrics and Indicators
What metrics to use to indicate QoS of OGC Web Services?
Is there anything geospatial/OWS specific here? Is this in the context of OGC at all?
Define the metrics as SKOS / RDF Concepts?
QoS Service Metadata
Follow-up and dissemination of the QoE Discussion Paper
Collect feedback from the Testbed 14 and other sources.
Start working on a Best Practice
Other work items?
Copyright © 2018 Open Geospatial Consortium