---
title: 'AutoWS: Automatic Web Service Semantic Annotation'
url: https://www.emergentmind.com/topics/autows
type: topic
---

# AutoWS: Automatic Web Service Semantic Annotation

AutoWS denotes the automatic semantic annotation of Web services, specifically the task of converting large repositories of syntactic service descriptions in WSDL and XSD into semantically enriched collections suitable for evaluating discovery, composition, mediation, and interoperability methods. In the formulation associated with MATAWS, the “Multimodal Automatic Tool for the Annotation of WS,” AutoWS is a fully automatic pipeline that focuses on data semantics at the level of service inputs and outputs, exploits latent semantics from parameter names, type names, and XML Schema structures, and emits OWL-S descriptions linked to SUMO concepts through Sigma’s WordNet-to-SUMO mapping [1305.0194].

## 1. Problem setting and benchmark motivation

AutoWS emerged from a methodological bottleneck in semantic Web services research: available semantic service corpora were either too small or insufficiently realistic for robust evaluation. Dataset2 in ASSAM was realistic but very small, while OWLS-TC3 and SAWSDL-TC were larger yet partly resampled in undocumented ways, and SWS-TC was poorly documented. At the same time, larger repositories of real syntactic Web services existed, notably the ASSAM Full Dataset with 816 real-world services and 7,877 operations, but these collections lacked semantic annotations and were too large for manual treatment [1305.0194].

Within that context, AutoWS addresses a scaling problem rather than a purely representational one. Manual tools such as Radiant and WSMO Studio required direct human intervention, and semi-automatic systems such as ASSAM and MWSAF depended on a training or assistance phase. The practical requirement was therefore not merely to annotate Web services, but to do so with zero human intervention during batch processing while preserving the realism of the original WSDL corpus.

A common misconception is to treat AutoWS as a general-purpose semantic interpretation system for all aspects of service descriptions. The first version is narrower. It focuses on data semantics, namely the semantic characterization of input and output parameters, rather than non-functional semantics or full behavioral modeling. This focus is central to its automation strategy.

## 2. Multimodal annotation architecture

MATAWS operationalizes AutoWS through a multimodal pipeline. The central design choice is that semantic evidence should not be extracted only from parameter names. Instead, the system also uses XML Schema type names and type structures, particularly the fields of complex types. When direct annotation from a parameter name fails, the system recursively descends into the type hierarchy to mine additional lexical context from nested subparameters and their types [1305.0194].

The end-to-end pipeline comprises five components. The Input Component parses WSDL and both inlined and linked XSD material, extracting operations, parameters, parameter names, type names, and type structures such as `complexType` sequences. The Preprocessor converts extracted names into lexical units suitable for concept association. The Associator queries Sigma, which returns candidate SUMO concepts for a token through the WordNet mapping. The Type Explorer is invoked when name-based association fails; it tries the type name first, and if that remains inconclusive, it traverses first-level subparameters and then deeper levels recursively. The Output Component generates OWL-S files mirroring the original WSDL structure while enriching parameters with SUMO concepts.

This architecture is “multimodal” in a specific sense: it fuses multiple lexical sources, not multiple learned encoders or similarity scores. The implemented behavior is a decision cascade. Parameter names are preferred; type names are fallback evidence; type structures are a deeper fallback. This suggests that AutoWS treats schema structure as semantic redundancy that can compensate for weak or noisy naming conventions.

## 3. Lexical preprocessing and Sigma-based concept association

AutoWS relies heavily on preprocessing because raw WSDL and XSD identifiers are often unsuitable for direct lexical lookup. The paper formalizes preprocessing for any name $x$ as

$$
T(x) = F_{\text{stop}}(N(D(x)))
$$

where $D(x)$ performs decomposition, $N$ normalization, and $F_{\text{stop}}$ stop-word filtering [1305.0194].

Decomposition splits concatenated identifiers by CamelCase, underscores, hyphens, dots, and digits, while removing non-letter characters and diacritics. The examples given are representative: “WhiteMovesNext” becomes `[white, moves, next]`, “Number_3Format” becomes `[number, format]`, “AUsername” becomes `[username]`, and “User name” becomes `[user, name]`. Normalization lowercases tokens and expands abbreviations through a configurable list, such as “no” to “number” and “id” to “identity.” Filtering removes configurable domain stop-words, including terms such as “parameter,” “body,” and articles like “a.” Stemming and lemmatization are not explicitly applied in the first version.

After preprocessing, concept association is delegated to Sigma. For a token $w$, if Sigma returns a ranked candidate set $C(w)=\{c_1,\dots,c_n\}$, MATAWS selects the top-ranked concept,

$$
f(w) = \arg\max_{c \in C(w)} \text{rank}_{\sigma}(c)
$$

and uses that SUMO concept directly unless it is filtered as a stop-word. No explicit word sense disambiguation threshold is used; the top Sigma concept is taken verbatim when available.

This choice is operationally simple but semantically fragile. The paper records characteristic misassignments: “user” mapped to `DiseaseOrSyndrome`, “name” to `HoldsRight`, “address” to `SubjectiveAssessmentAttribute`, “date” to `DateFruit`, and “value” to `ColorAttribute`. These errors do not arise from parsing failure but from WordNet sense ambiguity combined with the absence of context-sensitive disambiguation.

## 4. Type exploration, recursion, and the implemented decision rule

The distinctive contribution of AutoWS lies in Type Explorer. When the parameter name yields no usable concept, the system inspects the XSD type name. If that still fails and the type is complex, it inspects first-level subparameters, then their type names and structures, recursing until a concept is found or the hierarchy is exhausted [1305.0194].

The implemented decision rule is sequential rather than score-based. The paper formalizes the behavior as follows. First try tokens from the parameter name, $T_{\text{name}} = T(\text{name})$. If no concept is produced, try the type name, $T_{\text{type}} = T(\text{type\_name})$. If no concept is produced and the type is complex, collect tokens from subparameters,

$$
T_{\text{struct}} = \bigcup_{s \in \text{subparams}} T(s.\text{name}) \cup T(s.\text{type\_name})
$$

and recurse deeper if needed. An abstract fusion score

$$
S = \alpha S_{\text{name}} + \beta S_{\text{type}} + \gamma S_{\text{structure}}
$$

can be written as shorthand, but the paper explicitly states that no numeric weights or similarity functions are defined. The actual behavior is a gating cascade: if $S_{\text{name}}=1$, use the name-derived concept; else if $S_{\text{type}}=1$, use the type-derived concept; else if $S_{\text{structure}}=1$, use the structure-derived concept; else fail.

The article’s examples clarify the mechanism. For a WSDL operation `GetCustomerByCity` with inputs `customerId` and `cityName`, preprocessing yields `[customer, identity]` and `[city, name]`; the stop-word filter removes “name,” and Sigma maps `customer` to `Customer`, `identity` to `TraitAttribute`, and `city` to `City`. In a structure-driven example, an input part `category` has type `categoryDetail`, which contains `singer` and `composer`. If `category` is treated as a stop-word and `categoryDetail` produces no concept, Type Explorer descends into `singer` and `composer` and uses the resulting concepts discovered from the structure.

A second misconception follows from the term “multimodal”: the first version does not perform learned or joint disambiguation across multiple words. Type- and structure-derived tokens provide additional lexical anchors, but they are still processed by the same top-concept Sigma lookup.

## 5. Semantic output and empirical performance

AutoWS uses SUMO as the target ontology, accessed through Sigma. SUMO is described as comprising upper, mid-level, and domain ontologies, with example concepts such as `City`, `Computer`, and `Customer`. The attachment format implemented in the paper is OWL-S; support for SAWSDL and WSDL-S is described as planned via appropriate APIs [1305.0194].

Evaluation was conducted on the ASSAM Full Dataset, consisting of 816 WSDL files and 7,877 operations. The reported metric is the proportion of parameters successfully annotated, defined as assigning at least one concept to a parameter. No gold standard is used, and no precision, recall, or end-task evaluation is reported in this first version. Qualitative relevance is instead assessed by inspecting frequent words and their associated concepts.

The ablation results are central to understanding the system’s behavior:

| Configuration | Success rate |
|---|---:|
| No preprocessing (lowercasing only) | 39.63% |
| + Decomposition | 41.94% |
| + Normalization | 90.01% |
| + Filtering | 69.06% |
| + Type Explorer | 72.04% |

These figures show that normalization, especially abbreviation expansion, produced the largest gain, while stop-word filtering reduced raw annotation coverage. The reduction does not imply that filtering is intrinsically detrimental; rather, it indicates that many previously matched tokens were low-information or spurious. Type Explorer then recovered a modest additional gain of 2.98 percentage points, yielding a final annotation rate of 72.04%.

Qualitative inspection estimated approximate concept relevance at about 83% for frequent tokens. Correct mappings included `computer` to `Computer`, `month` to `Month`, `city` to `City`, `customer` to `Customer`, and `password` to `LinguisticExpression`. The previously noted misassignments remained a major failure mode. This suggests that the system’s principal weakness was not lexical sparsity alone, but context-insensitive sense selection.

The paper does not report runtime, but the design is explicitly intended for batch processing at collection scale. Implementation is in Java, with a custom WSDL/XSD parser, a Preprocessor, a recursive Type Explorer over `complexType` sequences, Sigma API access, and output generation through a Java OWL-S API.

## 6. Relation to prior tools, limitations, and prospective extensions

AutoWS differs from earlier semantic Web service annotation environments chiefly in automation level and evidence usage. Radiant and WSMO Studio are fully manual. ASSAM and MWSAF are semi-automatic and require a training or assistance phase. MATAWS is fully automatic, performs zero-intervention batch annotation, exploits names, type names, and type structures, and outputs OWL-S. At the same time, it is less flexible than assisted tools for fine-grained disambiguation and remains restricted to data semantics [1305.0194].

Its limitations are explicit. First, there is no advanced word sense disambiguation. Sigma’s top concept is accepted without a context model. Second, domain-specific jargon and abbreviations require curated expansion lists; otherwise tokens may remain unrecognized or be misinterpreted. Third, complex types are not always informative: some have shallow or empty structures, which constrains the usefulness of recursive exploration. Fourth, stop-word lists can both remove noise and suppress informative context if defined too broadly.

The paper identifies several future directions. One is to improve disambiguation by comparing multimodal word sets against WordNet textual definitions. Another is to incorporate additional lexicon-to-ontology mappings such as DBpedia. A third is to use operation names, message names, and natural-language descriptions present in WSDL as additional modalities. Planned engineering extensions include SAWSDL and WSDL-S output. The discussion also raises the possibility of machine-learning-based scoring or contextual fusion while preserving full automation.

In that sense, AutoWS occupies a pragmatic position in the semantic Web services literature. It does not solve semantic annotation in the strong sense of context-aware conceptual interpretation. It provides a scalable, fully automatic mechanism for transforming large real-world WSDL corpora into semantically enriched benchmarks, with approximately 72% parameter coverage on the reported dataset. Its significance lies less in semantic sophistication than in enabling realistic large-scale evaluation settings that were previously difficult to construct.

Source: https://www.emergentmind.com/topics/autows