Review Comment:
This paper describes Components.js, a dependency injection framework for Javascript applications that uses the Linked Data principles to describes their configurations.
The paper is well written (maybe a little specific when discussing certain aspects of the framework, assuming that the reader is a developer) and relevant for the Semantic Web Journal.
On the positives aspects of the paper, this work shows that the authors have done substantial work to eat their own dog food and use their tooling as a core component of their infrastructure.
In addition, Components.js enables the description of configuration files in a machine readable manner in order to capture the dependency of Javascript-based applications. The authors have even described 475,000+ npm JavaScript libraries already.
There are, however, some points that need clarification or improvement in the paper:
- The novel contributions of the paper are not clear. Is it the framework/tool in itself? Are the companion vocabularies also a contribution? The dump of LSD dependencies is also something that goes with the framework? The project that helps initializing component descriptions is also a contribution? It is difficult to understand what is proposed as novel versus what exists already in related literature. I think the authors should clarify this.
- Reproducibility: The authors emphasize that their descriptions help reproducing experiments/applications, although there are no experiments to show whether this is true or not. I tend to agree that having the configurations would help enormously when comparing components, and trying to re-run them in the future. However, there are several alternatives that describe components and computational environments in much depth than the one presented here. For example, Nix (https://www.nmattia.com/posts/2018-03-21-nix-reproducible-setup-linux-ma..., https://nixos.org/manual/nix/stable/) is a community based initiative to reproduce full environments from scratch that is gaining an increasing amount of followers. Then you have Docker containers that capture and encapsulate everything needed to run an application, but may be difficult to combine as the authors propose in the paper for dependency injection. Having some comparison distinguishing this work from existing approaches will help readers to understand why this approach is not reinventing the wheel.
- Related work: The authors list a series of existing ontologies and claim that they cannot be completely reused in this domain. However, it is unclear to me whether they can be reused partially or not (and why); and which ones have been used (I see e.g., doap is used). The following paper: https://arxiv.org/abs/2002.09440 may be useful, as they describe functions and their parameters and outputs in a KG.
- Additionally, I believe CWL (common workflow language) proposes a YAML description to describe inputs, invocation and parameters of a component to execute (I was reminded of this when reading the module dependencies in listing 1).
- I would like to understand better why the authors ended up creating their own framework instead of reusing an existing DI framework. This is different from how it differs from existing frameworks.
- derreferenceability: While I appreciate having derreferenceable entities as someone with semantic web background, I am not sure if it really adds a lot of value in this context. As a developer I would always try to download the configuration of a component, which already encapsulates all the descriptions needed to run it. What do I gain from querying e.g., the parameters using LOD? Is this something that a developer would do to understand how to use a configuration without having to download it every time? Having some examples in the paper would really help here.
- Impact: one of the limitations that I see is that despite the relative "long" life of the project (4 years) there is no significant community contributing to its development, besides the main authors. The authors report on some projects and usages, but it is not clear 1) Whether these are tests or fully engaged projects using the tool; 2) Whether there are researchers or industry external to the authors' circle that are using and contributing to the project. It's nice to see a statement on sustainability, but I wonder what would happen if the main two creators of the project (two PhD students collaborating with postdoctoral researcher) move to other institutions.
- There are also examples of projects using the tool, which is great, but I have not seen examples on whether the community is using Components.js for their own purposes. It would be nice to discuss if there are projects of that nature.
- Another potential issue for impact is the need for separate components to deploy and maintain. If I understood correctly, you need the LSD service to take care of the derreferenceability, then the Components.js framework for dependency injection, then the Component-Generator in case a developer wants to support their descriptions. All that on the dependency on npm to deploy the package. Have the authors done (or plan to do) a survey among potential adopters to see whether they would comply to all these requirements? For example, I have always found resistance from developers when using external services out of their control (e.g., for content negotiation)
- Paper claims versus results: In the introduction, the authors claim that Components.js can be used for obtaining provenance trails, for discovering conflicts and for automatically creating semantic workflows. However, none of these claims seem to be backed by any evidence or examples.
- How does this framework allow for more flexibility than other existing frameworks? It's not reported.
- Resources: Tags have been created in GitHub but code is not available as Zenodo releases. Dumps of data were stored in the authors' servers, which does not guarantee long term preservation (as Zenodo does)
Minor issues:
- Many frameworks are not referenced: Spring, Guice, Dagger... And also companies like Inrupt and imec.
- It would help showing real examples, rather than "ex:myModule" in the paper. It brings more credibility to this work, and there are plenty of examples from the LSD dump.
- ObjectMapping vocab does not have examples/human readable doc, which makes it a little difficult to browse.
- UML diagrams are non readable at regular size (printed version).
- For OPMW-PROV please cite the workshop paper:
@inproceedings{garijo2011new,
title = {A new approach for publishing workflows: abstractions, standards, and linked data},
author = {Garijo, Daniel and Gil, Yolanda},
year = 2011,
booktitle = {Proceedings of the 6th workshop on Workflows in support of large-scale science},
pages = {47--56},
doi = {10.1145/2110497.2110504},
organization = {ACM}
}
|