Semantic web services: from automatic composition to shared vocabularies

Semantic web services were an idea from the 2000s: describe each online service in machine-readable terms drawn from an ontology, so that software could find it, combine it with others and call it without a person in the loop. Public administration was one of the hoped-for beneficiaries, because so many public services span several agencies. Fully automatic composition never became the way government works, but several of the building blocks, above all shared vocabularies, are now part of everyday digital government.

The idea: services that software could find and combine

Web services of that period were typically described in WSDL (the Web Services Description Language), which sets out the messages a service accepts and returns but not what they mean. Semantic web services set out to add that meaning by linking each part of a description to concepts in a shared semantic model, such as an ontology³. The OWL-S proposal named three tasks this would make possible¹:

• Automatic discovery: software locates services that offer a given capability and meet the user's constraints.
• Automatic invocation: a program calls a service using only its declarative description, without being pre-programmed for that particular service.
• Automatic composition and interoperation: software selects and combines several services to reach a high-level objective.

Its examples were commercial, such as buying an airline ticket or arranging travel to a conference¹. The public-sector version is easy to picture: a request to register a new business, answered by software that finds and chains the registration, tax and social security services involved.

OWL-S, WSMO and SAWSDL

Three specifications published by the World Wide Web Consortium (W3C) mark the main lines of work.

Sources for the table: OWL-S¹, WSMO² and SAWSDL³. The difference in status matters. A Member Submission is a proposal from W3C members that W3C publishes, and W3C states that doing so "indicates no endorsement of its content"¹.

SAWSDL went through the full standards process and deliberately did less. It "does not specify a language for representing the semantic models", and only gives a way to reference their concepts from existing service descriptions³.

Why it appealed to e-government

The WSMO submission put public administration alongside business from its first sentence, citing the promise of "dynamic, scalable and cost-effective infrastructure for electronic transactions in business and public administration"². On paper, public services fit the idea well. A single life event, such as a birth, a move or starting a business, can involve several agencies, each with its own systems, its own terms and, across borders, its own language.

WSMO's mediators were designed for that problem: resolving mismatches between terminologies, between ways of communicating and in how services are combined². Its goals described what the user wanted rather than which service to call². In principle, a citizen could state an outcome and software would assemble the services, across agencies and, through semantic interoperability, across countries.

What happened instead

Fully automatic discovery and composition did not become the normal way public services were built. Several practical obstacles help explain why. Writing and maintaining formal descriptions of every service needed scarce skills in logic and ontology design, and agreeing shared ontologies across agencies proved as hard as agreeing the data standards they were meant to bridge. Arguably the most basic obstacle was legal: handing a citizen's case to services chosen by software, with no official deciding, raises questions of responsibility, consent and trust that technology alone cannot settle.

Meanwhile, the wider web moved to simpler interfaces. The UK government's API standards tell teams to use the REST (representational state transfer) style, to return JSON (JavaScript Object Notation) where possible, and to describe each API with the OpenAPI Specification, which the government's Open Standards Board recommends⁴. An OpenAPI document is "both machine and human readable" and describes an API's formats and responses, while the same guidance calls XML (Extensible Markup Language) "increasingly uncommon"⁴.

Discovery became a job for people, supported by catalogues. The standards tell teams to look for existing APIs in internal catalogues and in the cross-government UK API Catalogue before building, and to add their own API once it has been tested⁴. Composition happens in code written by service teams, and portals present the result to citizens.

What survived

The part of the idea that lasted is shared, machine-readable description, used to help people find and build services rather than to let software do it alone. Four pieces stand out.

• Shared vocabularies. The EU Core Vocabularies give agencies common terms for people, businesses, places and public organisations.
• The Core Public Service Vocabulary. Its application profile, CPSV-AP, describes a service's inputs, outputs, responsible public authority and the events that trigger its use, and is designed for user-centric catalogues of public services from regional level up to a European federated catalogue⁶.
• Schema.org. This shared vocabulary for structured data on web pages has a GovernmentService type, "a service provided by a government organization", with properties for its jurisdiction and its operator⁵.
• Catalogues. API catalogues such as the UK's⁴, and data catalogues whose records can describe data services as well as datasets, covered in the guide to DCAT-AP.

SAWSDL's modest approach, pointing from an ordinary service description to a concept that others share, is close to how these tools are used today. The interface stays simple, and the meaning lives in a vocabulary that many public bodies agree on and maintain together.