{'fraction_non_alphanumeric': 0.021142857142857144, 'fraction_numerical': 0.0, 'mean_word_length': 5.209219858156028, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
An extension of OWL-S with quality standards

With the increasing amount of Web Services available on the Web, Web Services discovery issues are becoming increasingly important. Since current Web Services standard technologies (e.g. UDDI) only provide syntactic descriptions of Web Services (mainly their signatures), semantic discovery approaches based on ontologies (e.g. OWL-S) have been developed. These approaches lead to more precise descriptions of Web Services functionalities, but they provide few mechanisms to capture non functional aspects of Web Services collectively referred as Quality of Services (QoS). To fill this gap, some works have proposed Web Services discovery approaches based on QoS ontologies. However these approaches do not take into account existing standards about software quality and the relationships that can be established between them. Yet, these standards could be used as a shared understanding between services providers and customers and thus, they would ease the Web Services discovery process. In this article we first propose an extension of OWL-S to describe QoS according to one or many quality standards. Then, we develop an approach based on this extension of OWL-S to improve the Web Services discovery process. This approach is based on an extension of SPARQL that simplifies expression of Web Services discovery queries. Relationships between standards are used to return Web Services even if they are described with quality properties defined in an other standard that the one used to express queries. Finally, non functional requirements can be expressed as user preferences. Thus, they can be used to rank Web Services fulfilling functional requirements during the Web Service discovery process.