Review Comment:
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 provided source code 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 report is well written and includes many examples. It also contains several references to related research (not only in section 3.4, but also in the introduction). I really liked how the URI patterns are explained in tables 1 to 5. Figures have a nice and simple design and are easy to understand. Authors describe the capabilities of SISSVoc in section 2. and comment some limitations related to REST behaviour in 3.2.
STRUCTURE
1. Introduction
2. SISSVoc design
2.1 SISSVoc API
2.2 Implementing SISSVoc
2.3 Deploying SISSVoc to meet use cases
2.4 SISSVoc deployments
3. Evaluation
3.1 URI Patterns
3.2 HTTP operations and REST behaviour
3.3 Applications
3.3.1 Water Data Transfer Format validation service
3.3.2 SISSVoc Search
3.4 Related Work
3.4.1 ONKI
3.4.2 Normalised Ontology Repository (NOR)
4. Conclusion
5. Acknowledgements
6. References
The structure of the report needs some changes. First, sections 2.3 and 2.4 should be merged. Second, the content and organization of section 3. Evaluation looks odd to me. I could not find a real evaluation of the tool. Section 3.1 talks about the SISSVoc pattern, which is based on Cool URI patterns, and some examples of Cool URI patterns (background/related work). Section 3.2 describes some limitations of SISSVoc, challenges of managing vocabularies, and some suggestions for this purpose. Then, sections 3.3 and 3.4 deal with applications built on top of SISSVoc and related work, respectively; thus, I do not see the reason for including them in an evaluation section. My suggestion is to move sections 3.3 and 3.4 out of section 3. Additionally, I would either rename section 3. or include a proper evaluation of the tool, e.g. a user-based evaluation or a use case evaluation for the different API requests.
MINOR REMARKS
Page 2:
- "But primarily SISSVoc also for machine-to-machine use,..." Anything missing here?
- "The SISSVoc API is (normally?) implemented using..."
Page 3:
- In the paragraph describing broader and narrower properties, all the properties have "/" at the beginning except broader. If you want to separate the properties using "/", remove the space after each property, i.e. broader/broaderTransitive/narrower/narrowerTransitive. If you want to list the properties like /[PROPERTY], add "/" to broader and commas between the elements in the list, i.e. /broader, /broaderTransitive, /narrower, /narrowerTransitive. My suggestion is to remove the "/" and add commas: broader, broaderTransitive, narrower, and narrowerTransitive.
- Table 2: The /collection pattern has half SPARQL query in page 2 and half one in page 3. If possible, try to rearrange the table to have the whole query in one page.
Page 4: Move the caption and header of table 5 to page 5 for the sake of readibility.
Page 6:
- Move URLs in first paragraph to footnotes.
- What does it mean that "the interfaces are distinct from the user's point of view."?
- "However, each interface uses the next one down for its configuration of real-time operation." I do not get the concept of "next one down". Please, rephrase.
- Section 2.4 should be merged to section 2.3.
Page 7: The reference to figure 3 appears in the text before the reference to table 6, so figure 3 should appear above table 6.
Page 8:
- Add a short section summary between heading 3. and 3.1.
- Use the same size and format for URI patterns throughout the paper. They are not underlined in page 3.
- There are more examples of unformatted URI patterns in the comparation between Cool URIs, DBPedia, and SISSVoc.
- Footnotes in this page are in a different format that in previous pages.
Page 9:
- "The standard interface provided by SISSVoc supports a wide (?) range of applications."
- Add a reference/footnote for Schematron.
- Redistribute text to fill the gap below figure 4.
Page 10: Add some content between 3.4 and 3.4.1.
Page 11: The NOR URI patterns should be formatted like the rest of URI patterns in the paper, and add some spaces above and below the patterns. The whole section 3.4.2 has an odd paragraph organization.
Acknowledgements and References are not regular sections and do not need to be numbered.
Revise the references, many of them look incomplete, e.g. [36] to [42]. In case of online resources, please add the URL.
|