Service Requests and Specifications in a Semantic Web with Relevant States

Tracking #: 1617-2829

Francisco J. Galan
Ahmed Riveras

Responsible editor: 
Marta Sabou

Submission type: 
Full Paper
A new language for specifying the functionality of semantic web services is defined in this paper. The proposed language is based on the concept of sequence of relevant states and it is more expressive than the so-called IOPE specification language. The writing of the relevant state distinguishes two kinds of statements: positive statements (i.e. sentences expressing true conditions) and negative statements (i.e. sentences expressing false conditions). A formalization based on OWL ontologies is proposed for the relevant state. Once established the definition of the new language, two notions of service request satisfaction from sequences of relevant states are defined: (a) satisfaction at publication time and (b) satisfaction at exploitation time. Both notions are useful for the definition of matchmaking policies. The notion of satisfaction at publication time is defined for generic requests and it does not depend on concrete states in the web. The notion of satisfaction at exploitation time is defined for concrete requests and it depends on concrete states in the web. We have tested the mechanization of the proposal with the construction of a prototype. The prototype compiles service requests and service specifications and it solves request satisfaction problems at publication time in a completely automatic manner. Numerous experiments with realistic descriptions included in the collection OWLS-TC4 have been performed with promising results.
Full PDF Version: 


Solicited Reviews:
Click to Expand/Collapse
Review #1
Anonymous submitted on 03/Jun/2017
Review Comment:

Within this submission, the authors propose a new specification for semantic web services (SWS). The authors aim at the explicit integration of service states into the service descriptions (and service requests). While this initially sounds like an interesting idea, there are several reasons why I recommend to reject the paper. I will not comment in detail on the actual technical content of this paper, which is (as far as I can judge) fine.

First, I have to ask why the authors see a reason for yet another SWS specification/standard. Since there are too many specs/standards out there which nobody uses, a new spec should really be well-motivated and there should be a clearly defined, well-accepted use case for it, which could be interesting and important for many researchers/users. Maybe I got it wrong, but the concept of states as proposed by the authors could also simply be reached by using, e.g., OWL-S, and defining separate states as separate services, which are then composed. In fact, the authors briefly discuss this aspect in the related work and claim that service compositions are not identical to their own approach, but this aspect is not discussed in enough detail. By using service compositions, reusability would even be higher then in the case of service-specific states.

Second, SWS have gotten a lot of attention by the research community until 5-6 years ago, but these days, the research topic is pretty much dead. Therefore, this paper will not get a lot of attention. Actually, the fact that SWS is an outdated research field can also be seen by the literature list of this submission, where (apart from some specifications and standards) almost all references are from <=2010. It is unfortunately not true that there is a (semantic) web of services out there (as claimed by the authors in the introduction). In fact, the number of SWS in the real world is negligible for a number of years now.

Third, the paper is not easy-to-follow. While the text itself is readable (despite quite a number of grammar mistakes), the submission is simply way too long and needs to be shortened to under 30 pages. There are a lot of unnecessary repetitions in the paper. For instance, the examples from the introduction as well as almost the complete Section 2 could be deleted without really loosing a lot of content. I really appreciate the usage of examples in papers, but in this submission, the paper simply gets too long by extensive examples. Also, parts of Section 3 are in my opinion not really necessary, since the knowledge should be available by interested readers. (BTW: There is surely no need to repeatedly state "This could be calculated with a DL Reasoner").

Fourth, the evaluation (presented in Sections 4+5) is weak. One could ask if the evaluations in Sections 4.1 and 4.2 are really necessary. Then, the work presented in Section 3 has unfortunately not been fully implemented yet. Last but not least, there is no real discussion of the outcomes of the results. The discussion of the related work is okay, but could surely be shortened a little bit. If possible, the authors should discuss more recent work, but as written above, there is a lack of more recent approaches.

Review #2
By Maria Maleshkova submitted on 17/Dec/2017
Review Comment:

The authors present a formalisation framework for describing service requests and advertisements (specifications), taking into consideration the sequence of states that have to be satisfied, in addition to considering the required inputs and outputs. Based on theses formalisation they introduce how a match can be achieved and test the results within a prototypical implementation. The problem addressed is a relevant one, since with the growing number of services available online, automation for discoing and determining suitable services becomes a necessity.

Even though the contributions and quality of work a sufficient for a journal publication, the reasons for recommending a rejections are the following:
1. The presentation in terms of structure, logical order of contributions, logical conclusions, building up on what has already been described need to be improved significantly. Currently, the paper is really difficult to read and follow not because of the content but because of the way the content is delivered. Some sections look more like an annex, while others a detailed but not necessarily relevant for the overall storyline.
2. The scope of the paper goes beyond what is suitable for a journal publication. It almost looks like the authors tried to squeeze a complete thesis into one journal paper. One can either cover a broad range of topics, but sacrifice to some extent the depth, or cover a fewer topics but go into depth. Doing both is not really practical for such a publication. This becomes obvious from the fact that the paper has 52 pages.
2. There should be a clear distinction between example, definition and assumption. One maple cannot serve as that basis for a general definition and in the same way one example does not prove that an assumption is correct. It should be clearly distinguished between what is a definition, what is only an example and what is being assumed. These three are currently very mixed.
3. Service descriptions (even the ones that take states into consideration) and service matches are not a novel topics. There is a lot of already existing work and it is curricula that the authors show that they are aware of this work and clearly state what is being reused and what is new. This is especially true for the definition of request and advertisement (in this paper referred to as specification), and matching approaches. The work on pi-calculus for service description and matching (S. Agarwal), Paulucci for service matching, J. Cardos, is completely ignored.

Detailed comments:
1. The abstract should shortly introduce the context of the work. Also the abstract uses a lot of terms that have not yet been introduced, in this way the reader cannot directly understand what is to be expected. Do you really introduce a new language?
2. The introduction has a completely different level of assuming what the reader already knows in the domain. While the abstract uses very specific items, the introductions starts by talking about RDF and OWL… Where does the definition of ontology come from? Note that there is a difference between service and a web service. What Oberle talks about are services (that can be realised by a web service). You cannot use the two terms as though they have the same meaning.
3. The introduction is not clearly structured, it contains a general overview but the continues with specific examples and statements that almost sound like definitions. The introduction should contain a summary of the contributions and a description of the remainder of the paper. This is especially important for longer papers such as this one, so that the user know what to expect.
4. The examples should be part of a new section that described the used scenario.
5. It is not clear (page 2) why we need negative statements. This comes a bit surprising.
6. A service is described as a set of parameters and relevant state. What about the functionality of a service. Most service searches are defined based on the type of functionality expected.
7. Page 3, there is a mix of examples and definitions/use of terms (over-satisfaction). This is very confusing, since you are using a term that has not been defined yet. At this point it is still not clear why you need negative statements.
8. Page 4 — a concrete state, mark this clearly as a definition
9. Example 6. It would make more sense to first introduce the ontology used. Currently, the reader has to guess what the oncology looks like based on the annotations.
10. page 6, bottom listing keyword “belongs” m belongs isInStock… is this standard terminology. Same listing, page 6, line 4, right-side isInStock value false. Why? Are you assuming that there is only one car of each type??? So if either one honda or one yamaha is sold, then isInStock is false?
11. Make sure that you are using the standard terms used in the literature. What is the difference between service specification, description and advertisement? You most probably mean advertisement (the thing that is being matched against).
12. page 7, wehre does the definition of a match come from? This is not really new (Paulicci). Why do the inputs have to be equivalent? An AmericalCustomer, as a subtype of Customer, would still be a valid input.
13. What about the order of the states? How is it taken into consideration (page 7, table on the right)
14. There is a lot of repetition between sections 1 and 2. Clearly divide the examples from the definitions. Currently the two a mixed. One example cannot serve as the basis for an overall valid definition. You need compare the definitions in section 2, to already existing ones. Use standard terms and do not try to introduce new terms for the same things.
15. Page 9, what is the difference between output and data properties. What is only vehicle output but not also payment? How do you make this distinction?
16. page 11, where does the notion of non-optional parameters suddenly come from? This has not been discussed until now.
17. page 12, the notion of satisfaction in terms of matches is not a new one. What is the innovation here? comparison to exact match, subsume match, plugin match… same definitions…
18. page 12, what of the sequence of states in not relevant but only the sates are. What is there are alternative states or optional states? You need co clearly state what you take into consideration and what not.
19. page 19, why are the negative sentences important for the approach? You can do matching without them. Who comes up with the negative statements?
20. page 31, the definition of fresh individuals, this is something that can be omitted in order to reduce the scope of the paper.
21. page 38, how do the results compare to other matching approaches?
22. The related work should be moved to the beginning of the paper and it should clearly be stated what is reused and what is newly defined.
23. For the next resubmission, focus either on the formalism or on the matching. Describing both in depth is too much for one publication.