Ontologies have become the de-facto modeling tool of choice, employed in a variety of applications and prominently in the Semantic Web. Nevertheless, ontology construction remains a daunting task. Ontological bootstrapping, which aims at automatically generating concepts and their relations in a given domain, is a promising technique for ontology construction. Bootstrapping an ontology based on a set of predefined textual sources, such as Web services, must address the problem of multiple concepts that are largely unrelated. This paper exploits the advantage that Web services usually consist of both WSDL and free text descriptors. The WSDL descriptor is evaluated using two methods, namely Term Frequency/Inverse Document Frequency (TF/IDF) and Web context generation. We propose an ontology bootstrapping process that integrates the results of both methods and validates the concepts using the free text descriptors, thereby offering a more accurate definition of ontologies.
Ontologies are used in an increasing range of applications, notably the Semantic Web,
and essentially have become the preferred modeling tool. However, the design and
maintenance of ontologies is a formidable process [
The Web service ontology bootstrapping process proposed in this paper is based on the advantage that a Web service can be separated into two types of descriptions: i) the Web Service Description Language (WSDL) describing “how” the service should be used and ii) a free text description of the Web service describing “what” the service does. This advantage allows bootstrapping the ontology based on WSDL and verifying the process based on the Web service free text descriptor.
The ontology bootstrapping process is based on analyzing a Web service using three different methods, where each method represents a different perspective of viewing the Web service. In particular, the first method analyzes the Web service from an internal point of view, i.e., what concept in the text best describes the document content. The second method describes the document from an external point of view, i.e., what most common concept represents the answers to the Web search queries based on the WSDL content. Finally, the third method is used to resolve inconsistencies with the current ontology. An ontology evolution is performed when all three analysis methods agree on the identification of a new concept or a relation change between the ontology concepts. The relation between two concepts is defined using the descriptors related to both concepts. Our approach facilitates automatic building of an ontology that could assist in expanding, classifying, and retrieving relevant services, without the prior training required by previously developed approaches. 2
The field of automatic annotation of syntactic Web services contains several works
relevant to our research. [
Ontology evolution has been researched on domain specific Web sites [
The bootstrapping ontology model proposed in this paper is based on the continuous
analysis of WSDL documents and employs an ontology model based on concepts and
relationships [
Token Extraction
Web Context Retrieval TF/IDF Ranking
Concept Evocation
Service Description
Ontology Evolution The analysis starts with token extraction, representing each service, , using a set of tokens called descriptors. Each token is a textual term, extracted by simply parsing the underlying documentation of the service. The descriptor represents the WSDL document, formally put as
= { 1, 2, . . . , }, where is a token. WSDL tokens require special handling, since meaningful tokens (such as names of parameters and operations) are usually composed of a sequence of words, with the first word lowercase, followed by first letter of other words capitalized (e.g., getInstitutionNameFromDomain). Therefore, the descriptors are divided into separate tokens. Figure 2 depicts a WSDL document with the tokens bolded.
The extracted token list serves as a baseline. These tokens are extracted from the WSDL document of a Web service that determines whether an email address or domain name belongs to an academic institution. The service is used to illustrate the initial step in building the ontology. All elements classified as name are extracted, including tokens that might be less relevant. 3.2
TF/IDF is a common mechanism in IR to generate a robust set of representative keywords from a corpus of documents. The method is applied here to the WSDL de( , ) . We define scriptors. By building an independent corpus for each document, irrelevant terms are more distinct and can be thrown away with a higher confidence. To formally define TF/IDF, we start by defining
( , ) as the number of occurrences of the token within the document descriptor . We define the term frequency of each token to be the corpus of WSDL descriptors. The as: ( ) = tf( ) × idf 2( ). inverse document frequency is calculated as the ratio between the total number of documents and the number of documents which contain the term: idf( ) = log Here, is defined generically, and its actual instantiation is chosen according to the origin of the descriptor. The TF/IDF weight of a token, annotated as ( ), is calculated ∣∣ ∣{ : ∈ }∣ .
The token weight is used to induce ranking over the descriptor’s tokens. We define that
⪯ / the ranking using a precedence relation ⪯ / , which is a partial order over , such if ( ) < ( ). The ranking is used to filter the tokens according to a threshold which filters out words with a frequency count higher than the second standard deviation from the average frequency. Figure 3 on the left circle of every concept presents the list of tokens which received a higher weight than the threshold. Several tokens which appeared in the baseline list (see Figure 2) were removed due to the filtering process. For instance, words such as “response” and “get” received below-the-threshold TF/IDF weight, due to their high frequency. 3.3
We define a context descriptor from domain ℳ a record of information, which in our case is a Web service. A weight ∈ ℜ identifies the importance of descriptor in relation to the Web service. For example, we can have as an index term used to identify a descriptor 1 =
and 1 = 42. A descriptor set {⟨ , ⟩} is defined by a set of pairs, descriptors and weights. Each descriptor can define a different point of view of the concept. The descriptor set defines all the different perspectives and their relevant weights, which identify the importance of each perspective.
By collecting all the different view points delineated by the different descriptors we obtain the context. A context
= {{⟨ , ⟩} } is a set of finite sets of descriptors, where represents each context descriptor and represents the index of each set. For example, a context may be a set of words (hence ℳ is a set of all possible character combinations) defining a Web service and the weights can represent the relevance the word is repeated times in the Web service descriptor document. of a descriptor to the Web service. In classic IR, ⟨ , ⟩ may represent the fact that
The context recognition algorithm was adapted from [
= { 1, 2, ..., } be a set of textual propositions representing a Web service, where for all there exists a collection of descriptor sets forming the context = {⟨ 1, 1⟩, ..., ⟨ , ⟩} so that relation ( , ), asserting that a proposition
( , ) is satisfied. McCarthy [
AcademicVerifier TF / IDF
Web Context
Concept Evocation
Web Service
AcademicVerifier TF / IDF
Web Context
Database
IP Code Picture
Key Zip City
Descriptor
Results Con Concept
Subclass
Relation ? URnedleaftiinoend the contexts describing the WSDL as descriptors with their associated weight .
The context recognition algorithm identifies the outer context ( , ∩ =1 ( , )).
The context recognition algorithm consists of three main phases: 1) selecting contexts for each text, 2) ranking the contexts, and 3) declaring the current contexts. The result of the token extraction is a list of keywords obtained from the text. The selection of the current context is based on searching the Web for relevant documents according to these keywords and on clustering the results into possible contexts. The output of the ranking stage is the current context or a set of highest ranking contexts. The set of preliminary contexts that has the top number of references, both in number of Web pages and in number of appearances in all the texts, is declared to be the current context and the weight is defined by integrating the value of references and appearances. The input to the algorithm is a stream of information in text format. Figure 3 shows the result of the Web context extraction in the right circle of each concept. The figure shows the context that includes only the highest ranking descriptors which pass the cutoff to be included in the context. For example, Domain, Software, Registration, and Domain Name are the context descriptors selected to describe the AcademicVerifier service. 3.4
Concept evocation identifies a possible concept definition which will be refined in the ontology evolution. The concept evocation is based on context intersection. An ontology concept is defined by the descriptors which appear in the intersection of both the Web context results and the TF/IDF results. We defined one descriptor set from the TF/IDF results, /
, based on extracted tokens from the WSDL text. The context, , is initially defined as a descriptor set extracted from the Web representing the same document. As a result, the ontology concept is represented by a set of descriptors, , which belong to both sets: = { 1, ..., ∣ ∈ / AcademicVerifier Web service, the concept is based on the intersection of both descriptor sets is identified as Domain. The concept can consist of more than one descriptor (e.g., DomainSpy Web service is identified by the descriptors Domain and Address). Concepts can be evoked as a result of partial overlapping concepts. This example can be seen by Address and the set of Domain, Address, and XML.
A context can consist of multiple descriptor sets and can be viewed as a metarepresentation of the Web service. The added value of having such a meta-representation is that each descriptor set can belong to several ontology concepts simultaneously. For example, a descriptor set {⟨ , 23⟩} can be shared by multiple ontology concepts (Figure 3) that have interest in domain registration. The different concepts can be related by verifying whether a specific domain exists, domain spying, etc., although the descriptor may have differing relevance to the concept and hence different weights are assigned to it. Such overlap of contexts in ontology concepts affects the task of Web service ontology bootstrapping. The appropriate interpretation of a Web service context that is part of several ontology concepts is that the service is relevant to all such concepts. This leads to the possibility of the same service belonging to multiple concepts based on different perspectives of the service use.
The concept relations can be deduced based on convergence of the context descriptors. The ontology concept is described by a set of contexts, each of which includes descriptors. Each new Web service that relates to the concept adds new context descriptor sets. As a result, the most common context descriptors which relate to more than one concept can change after every iteration. The sets of descriptors of each concept are defined by the union of the descriptors of both the Web context and the TF/IDF results. The context is expanded to include the descriptors identified by the Web context, the TF/IDF, and the concept descriptors: { 1, ..., ∣ ∈ /
∪ ∈ } . For example, in Figure 3, the context of service AcademicVerifier includes the descriptors: Software, Registration, Domain
The relation between two concepts, and , can be defined as the context descriptors common to both concepts, for which weight is greater than a cut off value of : ( , > }. However, since multiple context descriptors can belong to two concepts, the value of for the relevant descriptors needs to be predetermined. A possible cutoff can be defined by TF/IDF, Web Context, or both. Alternatively, the cutoff can be defined by a minimum number or percent of Web services belonging to both concepts based on shared context descriptors. The relation between the two concepts Domain and Domain Address in Figure 3 can be based on Domain or Registration. The example takes a minimum number of appearances in a document as the cutoff of both the TF/IDF and Web Context methods. 3.5
The ontology evolution consists of four steps including: 1) building new concepts, 2) determining the concept relations, 3) identifying relations types, and 4) re-setting the process for the next WSDL document. Building a new concept is based on refining the possible identified concepts. The evocation of a concept in the previous step does not guarantee that it should be integrated with the current ontology. Instead, the new possible concept should be analyzed in relation to the current ontology.
The descriptor is further validated using the textual service descriptor. The analysis is based on the advantage that a Web service can be separated into two descriptions: the WSDL description and a description of the Web service in free text. The WSDL descriptor is analyzed to extract the context descriptors and possible concepts as described previously. The second descriptor,
= { 1, 2, . . . , }, represents the text 10: 11: 12: 13:
Extract tokens from WSDL 9: For each concept pair / If( If( Else ⊆
⊆ = / = / = / , ) = ∩ description of the service supplied by the service developer in free text. These descriptions are relatively short and include a sentence or two to describe the Web service. The verification process includes matching the concept descriptors in simple string matching against all the descriptors of the textual service descriptor. We use a simple stringmatching function, ℎ
, which returns 1 if two strings match and 0 otherwise.
Continuing the example in Figure 3, analysis of the AcademicVerifier service yields only one descriptor as a possible concept. The descriptor Domain was identified by both the TF/IDF and the Web Context results and matched with a textual descriptor. It is similar for the Domain and Address appearing in the DomainSpy service. However, for the ZipCodeResolver service both Address and XML are possible concepts but only Address passes the verification with the textual descriptor. As a result, the concept is split into two separate concepts and the ZipCodeResolver service descriptors are associated with both of them.
To evaluate the relation between concepts, we analyze the overlapping context descriptors between different concepts. In this case, we use descriptors which were included in the union of the descriptors extracted by both the TF/IDF and Web context methods. Precedence is given to descriptors which appear in both concept definitions over descriptors which appear in the context descriptors. In our example, the descriptors related to both Domain and Domain Address are: Software, Registration, Domain, Name, and Address. However, only the Domain descriptor belongs to both concepts and receives the priority to serve as the relation. The result is the relation which can be identified as a subclass, where Domain Address is a subclass of Domain.
The process of analyzing the relation between concepts is performed after the concepts are identified. The identification of a concept prior to the relation allows in the case of Domain Address and Address to again apply the subclass relation based on the similar concept descriptor. However, the relation of Address and XML concepts remains undefined at the current iteration of the process since it would include all the descriptors that relate to ZipCodeResolver service. The relation described in the example is based on descriptors which are the intersection of the concepts. Basing the relations on a minimum number of Web services belonging to both concepts will result in a less rigid classification of relations. The process is performed iteratively for each additional service which is related to the ontology. The iterations stop once all the services are analyzed. Alternatively, an ontology administrator can decide to suspend the ontology evolution at any given time.
To summarize, we give the ontology bootstrapping algorithm in Figure 4. The first step is extracting the tokens from the WSDL for each Web service (line 2). The next step is applying the TF/IDF and Web Context to extract the result of each algorithm (lines 3-4). The possible concept, , is based on the intersection of tokens of the results of both algorithms (line 5). If tokens appear in the document descriptor, , is defined as concept, . The union of all token results is for concept relation evaluation (lines 6-8). Each pair of concepts, and , is analyzed for whether the token descriptors are contained in one another. If yes, a subclass relation is defined. Otherwise the concept relation can be defined by the intersection of the possible relation descriptors, and (lines 9-13).
This paper proposes an approach for bootstrapping an ontology based on Web service descriptions. The approach analyzes Web services from multiple perspectives and integrates the results. Web services usually consist of both WSDL and free text descriptors. This allows bootstrapping the ontology based on WSDL and verifying the process based on the Web service free text descriptor. The approach enables the automatic construction of an ontology without the prior training required by previously developed methods. As a result, ontology construction and maintenance efforts can be substantially reduced. Our ongoing work includes further performance study of the proposed ontology bootstrapping approach. We plan to apply the approach in other domains in order to examine the automatic verification of the results.