Facilitating Filtering of Web Feature Services with their Automated Description

This paper proposes semantic descriptions of OGC Web Feature Services (WFS) using a set of well-established ontologies (with some additional classes, properties, and mappings). While such semantic descriptions can definitely be useful, this paper unfortunately fails to convince the reader that they would actually provide an added value. The way these descriptions are discussed here, they are simply translations from elements in XML documents generated by a standards-compliant WFS (the responses to the GetCapabilities and DescribeFeatureType requests, respectively) to a set of classes and properties from a set of ontologies. The queries listed in section 4.3 can all be answered directly from those XML documents, which is mostly because they do not make any use of the semantics introduced by using the ontologies. Other papers, such as [1,2], which have dealt with similar approaches, make a better case for such a semantics-based approach (they are also missing from the very brief -- i.e., too short and incomplete -- related work section). The main reason for my recommendation is hence that the paper fails to make a convincing case for the use of ontologies to describe WFS. Moreover, since the paper mostly discusses mappings between existing ontologies (with some unusual design choices, see below), I am not sure whether it presents a substantial enough contribution for an ontology description paper.

Some smaller issues that also need to be addressed before the paper can be published:

- As mentioned above, the related work section is quite brief and lacks some relevant publications, which should also help address the main problem.
- The introduction sounds like the documents produced by a WFS are meant to be read and processed manually, which is not the case. It should be clarified that these XML documents are usually requested by other services (within a Spatial Data Infrastructure) or by desktop GIS applications, which automatically process them and present them to the user in a more digestible form. This fact makes it even more imperative that the paper clarifies the utility of semantic descriptions.
- Section 3 seemed quite lengthy, and made me wonder why no single, concise method has been chosen?
- What would be different in the solution if it had to support WFS versions > 1.0.0?
- Several references are not resolved, showing "[?]" in the paper
- Reference [1] in section 5.3 is a bit outdated; there has been quite some progress with the implementation of GeoSPARQL in the past years, so I'm not sure the statement that "full scalable implementation has not yet been achieved" is still valid.
- Fig 2: Why is organization a subClassOf vCard? Seems counterintuitive.
- Next page: Why is wso:Metadata rdfs:subClassOf process:Input?
IMO it could as well be a process output.
- Likewise, why is FeatureType a subclass of SpatialObject (Figure 3)?
- Other than those few mappings that made me wonder, I was happy to see that the authors tried to make sure that logical consistency between the ontologies is retained.
- Having said that, what are the benefits of the HttpAtomicProcessGrounding (explain/give examples)? What would you lose without it?
- Sec. 7.1, first sentence: "the minimum queries this ontology needs to be able are demonstrated" -> "the minimum queries this ontology needs to be able to answer are demonstrated"
- P. 12: "What are the filters a particular WFS service" -> add "has"

[1] Janowicz, K. et al., 2010. Semantic Enablement for Spatial Data Infrastructures. Transactions in GIS, 14(2), pp.111–129.
[2] Jones, J. et al., 2014. Making the web of data available via web feature services. In Lecture Notes in Geoinformation and Cartography, pp.341–361.

The authors introduce an ontology for interconnecting OGC web services, especially the WFS to OWL-S. They explain their modeling approach and showcase the use of the result by exploring the offerings of three different services. Overall they make a good use of the English language with a few editorial issues (see below) that would need to be resolved before a possible publication.

Nevertheless, before considering accepting the article, I see several needs for improvement. These primarily include more argumentation about design choices (details below), some of which I could not follow in the current version of the article. I am not suggesting to necessarily change the approach for all of these points, but ask for reasonable explanations of the choices taken. This would increase the overall value and the interest of the SWJ audience in this work. In addition, it would add value to the paper if the overall motive could be better explained and illustrated, i.e. showcases not only how three WFSs can be accessed, but also detailing one real application for which this is important. Last but not least, further value could be added by an example that does not only consider OGC services, but also services that are already covered by the original OWL-S groundings. All in all, this works reminds me of the PhD that a colleague (Micheal Lutz) completed several years ago on “Ontology‐based retrieval of geographic information”. Some of the related publications might provide useful inputs to modeling considerations, too.

Due to the above reasons, I recommend to ask for a major revision before reconsidering the article for publication. I encourage the authors to take these comments into account and to provide a more detailed description of their work.

Arguable design choices:
- Why not follow the general OWS elements (such as GetCapabilities) before then specializing to WFS in order to make it easy to extend to WCS, SOS and other OGC services later on.
- The description has a valid focus on OWL-S but SWSO is mentioned, too. What are the exact links to SWSO?
- Why is the new ontology called Web Service Ontology (which may anyway introduce some possible confusions with SWSO and is a very generic term), where it is exclusively for OGC services and (currently for WFS only)? I would call this OWS Ontology.
- In section 3 it is said that “a specific term can only be represented with a specific data type”. When would this be the case?
- In section 4.4 GeoSparql is introduced for the geospatial content, but in 4.5 another name space is introduced for content. For me, the latter makes perfect sense, but this needs an explanation in the paper.
- In section 5.1.1, why is wso:Geometry introduced given that there is geo:Geometry?
- The argument of not having to be WSDL compliant and that the extensions do not violate OWL-S is not enough of an argument to explain why WSDL has not been followed. More explanation is needed.
- In addition to the above, why was the extension directly mage to OGC HTTP and not any the HTTP first?
- The NeoGeo ontology is briefly mentioned. Why exactly? It is used in any way? If not, why not?
- The introduction of geo:FeratureAttribute and geo:FeratureProfile may be better explained by directly giving an example.
- The filtering might be explained in a bit more detail by explicitely referring to the geof name space.
- The authors speak of “Modification to the GeoSparql” and “Modifications to the HTTP ontology”. Are these real modifications of the original ontologies (which would need to be explained in more detail) or actual extensions (i.e. the issue could be resolved by changing one work in the article)? If not, i.e. real modifications are made (as e.g. Figure 5 suggests) then this might be more described as identified limitations of e.g. GeoSparql in respect to web service descriptions and as possible change proposals. It would be best to explain possible alternatives without changing existing ontologies.
- The decisions to make all feature types of GeoSparql a subclass of owls:Input, especially while introducing a WSO-own Geometry in order to link to the owls Output needs much more explanation.

Editorial issues:
- The different steps described in section 3 would be easier to follow if there would be a figure illustrating them.
- Missing references in the text, where there is already a placeholder “?”, especially in section 3.
- Reference to the statement that WFS 1.0.0 is the most widely used version.
- Adding all name spaces to the classes that are included in the figures.
- The gray ellipses in the figures should be already explained together with figure 3.
- Reference to figure 4 is missing in the text.
- The question below table 2 might be rephrased.

This paper proposes the Web Service Ontology (WSO) ontology which facilitates the semantic description of web services providing geospatial data, also known as Open Geospatial Consortium Web Services (OWS). More precisely, the focus is on describing a particular type of OWS, namely Web Feature Services. The authors reuse a variety of existing ontologies (e.g., OWL-S, vCard) to create their ontology.

This manuscript was submitted as 'Ontology Description' and therefore was reviewed along the following dimensions:

(1) Quality and relevance of the described ontology (convincing evidence must be provided).
Low.

The work of the authors has a very narrow scope (that of semantically describing a particular type of geospatial services). This raises the question of relevance, i.e., whether there is a need for such an ontology at all. The paper is unclear about such need – e.g., by pointing to a high number of services, or a large user base that could benefit from the automation granted by this ontology. There is also no evidence of (wide-spread) usage of the ontology outside the group of authors: the current application of the ontology focuses on its use for describing three WFS.

Section 2 on Background only weakly argues for the novelty of the presented work, focusing primarily on the issue of grounding these services. This by itself does not constitute a good enough motivation for building a new ontology rather than reusing and extending other similar efforts such as those in references [6, 14, 23].

(2) Illustration, clarity and readability of the describing paper, which shall convey to the reader the key aspects of the described ontology.

Low.

The paper is longer than the typical ontology description paper, and contains far too many details while omitting the key aspects of the ontology (e.g., size, complexity class, design patterns used if any). In particular, Section 3 on methodology is practically a survey of various ontology engineering methodologies, with most details being unnecessary for the audience of this journal (e.g., Uschold’s three methods for describing class hierarchies).

The overall quality of the paper is under the standard expected for a journal submission: several unsolved references in the text (“[?]”), incomplete references (e.g., [14]), several typos and text paragraphs that are hard to understand. It is also rather unusual that the paper includes large portions of Turtle syntax and several SPARQL queries. These should be reduced for demonstrating aspects of the ontology that are of interest from a research perspective.

Taking these considerations into account, the paper is, at this point not suitable for a journal venue. A workshop or specialised conference might be more suitable for this material.