SISSVoc: A Linked Data API for access to SKOS vocabularies

The paper has been extensively updated, along the lines that were suggested in earlier review. This is extremely positive, and in my opinion the paper is much stronger now and deserves publication.

One of the only negative points remains the handling of languages (for labels) in the API itself. The paper clarifies that SISSVoc relies on other components features, but this is not extremely satisfying for multilingual scenarios. And it is not really clear how it is done (LDA _lang is only briefly mentioned at the end).

I wish the authors would also give more detail (if just two or three lines) for the

- in section 2 TTL should be spelled out Turtle
- I believe that in several cases it would be clearer to spell out property lists instead of shortening them, e.g. [*Match]
- Table 6 (the one with the SKOS constructs) seems to be contradicted by the text. It says OrderedCollection is not present but the text mentions it.
- there are two table 6
- in 3.3 an number may be missing after one of the [interface ]. Actually I am not sure what that numbering contributes as it is not re used in other parts of the paper.
- I am not convinced that SISSvoc can claim to be implementing a ConceptScheme API. It seems to return lists of ConceptSchemes, but does not seem to allow finer-grained access to concepts that are in a concept scheme, as it does not include skos:inScheme.

The authors have addressed the majority of my concerns; their revisions have greatly improved the article. Specifically, I appreciate the effort in restructuring the article, summarizing the scope of the API (table 6), and providing relevant examples (in sections 3 and 4) and a comparison with related approaches (table 7). I have no further major comments, but only minor issues that should be addressed before the article can be considered acceptable.
1. Avoid one sentence paragraphs (e.g., see sections 1 and 3.1)
2. Section 2 (title) – Remove “motivation” (you have already addressed the motivation of developing SISSVOC in section 1).
3. Use the same term consistently (e.g., interfaces vs. layers vs. levels)
4. Section 3.3 – The interface number is missing – “….was loaded from the vocabulary document (interface ??)”
5. Check figure captions – “Fig.” vs. “Figure” vs. “.Figure 5”
6. Specify future work – (a) how do you plan to extend the API with the remaining SKOS vocabularies; (b) describe potential applications of the API

SUMMARY
This report describes the version 3.0 of SISSVoc, a Linked Data API for searching and retrieving RDF datasets based on SKOS. SKOS is commonly used to formalize vocabularies with a hierarchical structure. The methods of the SISSVoc API allow requesting SKOS resources, and filtering based on resource label and broader/narrower SKOS properties.

QUALITY, IMPORTANCE, AND IMPACT OF THE TOOL
The presented API provides abstraction in searches over RDF datasets organized by SKOS, which is a W3C recommendation. Authors claim that SISSVoc users do not need to worry about RDF, SKOS properties, or SPARQL. Therefore, this is a step forward to bring semantic technologies closer to non-expert users. Currently, the API is being used within the AuScope Portal in various environmental projects. Moreover, a validation service built on top of SISSVoc is presented in the report, which tells about its reusability.

The source code provided at https://github.com/jyucsiro/sissvoc-runner requires Windows OS. It would be great to have implementations for others operating systems, nevertheless there is no doubt that SISSVoc may have an impact on all those organizations using SKOS and the potential users of their data.

CLARITY, ILLUSTRATION, AND READABILITY
The paper is well written and easy to read. The tables and figures are helpful to illustrate the SISSVoc API. Additionally, the authors added examples of URIs to tables 1-5. Table 6 describes the coverage of the API and the limitations, which is relevant for users and developers that might want to extend it. Finally, the addition of table 7 (8!) enriches the Related Work section significantly.

Section 3.3 is difficult to follow, specially from the second sentence onwards; please, re-write.

In page 9, section 3.4 is splitted in two columns to accomodate table 6 (which should be numbered as table 7! Consequently, table 7 should be numbered to table 8). This change in the reading order is a bit confusing because according to the 2-column format of the article, I would have expected to follow the content of 3.4 below. The same applies to the part of section 4.1 included in the same page.

STRUCTURE
1. Introduction
2. Motivation: different interfaces for different users
3. Design and implementation
3.1 SISSVoc API
3.2 SISSVoc implementation
3.3 SISSVoc deployment
4. SISSVoc applications
4.1 Water Data Transfer Format validation service
4.2 SISSVoc Search
5. Analysis
5.1 URI Pattern for resource descriptions
5.2 URI Patterns for lists
5.3 URI Patterns for queries
5.4 REST behavior and vocabulary maintenance
5.5 Related Work
5.5.1 SKOSAPI
5.5.2 ASKOSI
5.5.3 Skosprovider
5.5.4 Poolparty
5.5.5 SKOSMOS
6. Conclusion

According to the provided comments in previous review, the structure of the report presents some improvements w.r.t. the first version. The section 2. Motivation helps the reader to understand why the SISSVoc API is necessary. In section 5.5, there is no need for so many subsections. The content could be better integrated, for instance, by describing each different related work in a paragraph.

MINOR REMARKS
- General: The capitalization of section titles is not consistent, e.g. 3.2 SISSVoc implementation vs. Related Work.
- Section 1: Check spelling of SISSVoc at "...and some client applications built on SISSvoc."
- Section 2: "There are accepted standards for three of these layers,..." -> Indicate which are these layers.
- Section 3:
- Missing a section introduction between heading 3. and 3.1.
- Section 3.2: "Figure 2 shows an example of this where..." -> Remove "of this"
- Section 4: "Here we describe two developed by the authors." -> Two applications or two user interfaces?
- Section 5
- The title of section 5 is ambiguous: "Analysis" of what? Additionally, there is no introductory text describing what is the section about between this heading and subsection 5.1.
- Section 5.5.4: "...update and other maintenance is REALIZED? through a SPARQL Update endpoint."
- Section 5.5.5: "SKOSMOS [22] is THE closest SOLUTION to SISSVoc,..."
- Section 6:
- Remove "(usually public)"
- Rephrase "...and multiple interfaces to the content are usually published, with each used as the basis of the interface next higher in the stack."
- Replace "The evaluation includes..." for "Section 5 includes..."
- "SISSVoc is probably the lightest-weight,..." -> If the authors cannot prove that SISSVoc is the lightest-weight implementation, I recommend to write that is a light-weight implementation. The use of "probably" is discouraged in these kind of comparisons in a scientific article.

The manuscript has been thoroughly revised and my concerns have been taken care of. The purpose, quality, and importance of the API are now clear and the text is as readable as it can get for a tool-description.

I would have preferred if the authors acknowledged that this type of contribution cannot really be evaluated and had not claimed to do so at all. Now that the section (5) has been renamed to Analysis (not sure that is an ideal term, but ok), why not get rid of the two remaining hints at evaluating.

Minor edits remain necessary:
- p.2, "have being" should be "have been"
- p.3, the formatting of the numbered list is messed up
- why does the acronym URI need curly brackets around it? {URI}
- most of the uses of "very" are not necessary