Add reply letter

reply-letter.txt

@@ -0,0 +1,213 @@
+To the Editors of the Semantic Web Journal
+
+Dear Editors and Reviewers,
+
+Thank you for your detailed and insightful comments.
+Please find attached to this letter a revised version of our submission entitled
+"Components.js: Semantic Dependency Injection"
+in which we have addressed your comments.
+
+Hereafter, you can find detailed answers to your questions and remarks.
+Should you have any further questions or concerns, please do not hesitate to contact us.
+We look forward to hearing back from you and thank you in advance.
+
+The full diff of all changes to the article is available here:
+https://github.com/LinkedSoftwareDependencies/Article-System-Components/compare/48b676b436593f4dc4b6d9800d86972a8445558b...master
+
+Sincerely,
+Ruben Taelman
+on behalf of the authors
+
+imec - Ghent University - IDLab
+Technologiepark-Zwijnaarde 15
+B-9052 Gent
+Belgium
+
+
+
+# Review 1
+
+> The title of subsection 4.1, "Architecture", should be taken seriously, and
+most implementation details should be replaced by e.g. more analysis on the
+capabilities and limitations of the architecture of Components.js on a higher
+abstraction level.
+
+In order to improve the explanation the architecture on a higher level, we now discuss the functional and non-functional requirements that were taken into account when designing the architecture in section 4.
+
+> All URLs should be moved into footnotes or converted into proper references.
+
+We have moved all inline URLs to references.
+
+> Increase font size in figures, it should be around the same size as in the captions.
+
+We have increased the font sizes in the vocabulary figures, and the UML diagrams have been moved to a (single-column) appendix so that they are better readable.
+
+> Subsection 2.3, last paragraph: expand the paragraph(s) and explicate more
+clearly how Components.js differs from other DI frameworks.
+
+The last paragraph of section 2.3 has been extended with a more in-depth discussion about the differences with other DI frameworks.
+
+> Section 3: "This is equivalent to a Node module" First time Node.js is
+mentioned, explain what it is.
+
+We now briefly explain Node.js in a new related work section (2.4).
+
+> Subsection 4.1.3: "which is primarily used by the Node.js framework"
+Node.js is a runtime environment, I wouldn't call it a framework.
+
+We have rephrased the description as suggested.
+
+> Subsection 3.3. Could you add some speculation on the long-term
+sustainability of the Linked Software Dependencies service? Minting and
+maintaining IRIs for for all future npm packages is a key issue for the whole
+idea of semantic DI for JavaScript.
+
+We have appended a new paragraph to section 3.3 to discuss this long-term sustainability.
+
+
+
+# Review 2
+
+> I think the state of the art should mention Deno (https://deno.land/),
+which uses URL for loading local or remote dependencies, addressing the
+derefenceability issue (and thus promoting "configuration as code").
+
+We have added a new related work section (2.4) to discuss both Node.js and Deno.
+
+> I am surprised that the oo: ontology does not have a notion of Interface,
+which is an important notion in DI. Or are interfaces modeled simply as
+superclasses? This should probably be explained.
+
+The OO vocabulary does not include the notion of an interface because JavaScript does not have interfaces, they can only exist before transpilation in TypeScript code.
+However, the vocabulary contains an oo:AbstractClass, which is equivalent to an interface at the level of dependency injection, so that class can be used if needed.
+We now explain this in section 3.1.
+
+> it is not clear to me why you need both "parameters" and
+"constructorArguments". Why not directly declare the parameters (uniqueness,
+range) inside the "constrictorArgument"? This redundancy seems burdensome for
+the user, for no obvious reason.
+
+We have separated the definition of parameters and their mapping to constructor arguments to allow parameters to be reused across different classes, while constructor mappings are more tightly coupled to classes. Since these declarations are automatically generated in most cases, this decoupling does not cause an extra burden in practise.
+
+> at then end of §3.3, it is not clear whether
+linkedsoftwaredependencies.org aims to be 1) a centralized source of
+dereferenceable component descriptions, or 2) as a fallback for people that
+have do not have the will/ability to make their description dereferenceable.
+I assume it is the 2nd one, but this should be more explicit.
+
+LSD indeed has the second aim. We have clarified this in section 3.3
+
+> is linkedsoftwaredependencies.org running Components-Generator
+automatically on NPM TypeScript packages that miss a component description?
+If not, is it only because it would be too costly, or are there other
+obstacles in doing it?
+
+That is an interesting suggestion, and should be possible in theory, but there may be some performance considerations to take into account. We have now added a sentence about this as future work within the conclusions section.
+
+> I am not convinced that the number of downloads reported by NPM is a lower
+bound of the number of usages. Some downloads may be due to bots who create
+mirrors or do other things, that do not correspond to actual usage...
+
+That is a good point. We have rephrased section 5.1 to take this into account.
+
+
+
+# Review 3
+
+> The novel contributions of the paper are not clear.
+
+We now explicitly list the contributions near the end of the introduction section.
+
+> Reproducibility: The authors emphasize that their descriptions help
+reproducing experiments/applications, although there are no experiments to
+show whether this is true or not.
+
+We consider reproducibility just one of the potential use cases of Components.js, without Components.js offering a complete solution to it. We have added a paragraph near the end of the introduction section to explain this, and refer to tools such as NixOS that can offer more complete replications.
+
+> 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).
+
+We did indeed reuse (parts of) the ontologies where possible, such as DOAP as RDFS. The other ontologies had conflicting modeling needs that made it difficult to reuse them for our specific requirements. We now also explicitly mention this at the end of section 2.2.
+
+> The following paper:
+https://arxiv.org/abs/2002.09440 may be useful, as they describe functions
+and their parameters and outputs in a KG.
+
+We have now included this work in our related work section.
+
+> Additionally, I believe CWL (common workflow language) proposes a YAML
+description to describe inputs, invocation and parameters of a component to execute
+
+We decided to not include CWL in our related work section, as we consider the DI configuration files from other frameworks (such as Spring’s XML files), and the existing semantic software description ontologies more closely related to our needs.
+
+> 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.
+
+The existing (JS) DI frameworks have conflicting requirements regarding the decoupling of the dependency injection layer and the software implementation, which is why we opted to create a new framework. The last paragraph of section 2.3 has been extended with a more in-depth discussion about this.
+
+> 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.
+
+The developer would indeed not gain much from this dereferenceability. There are however other people that could benefit from this, such as for example researchers that want to analyze which config parameters had the largest influence on the performance of a system. Or people using the follow-your-nose principle to analyze class inheritance chains of certain modules. We have added a new paragraph to discuss this in section 3.3.
+
+> 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.
+I wonder what would happen if the main two creators of the project (two PhD students
+collaborating with postdoctoral researcher) move to other institutions.
+
+Components.js is part of the newly founded Comunica Association, which is a non-profit that aims to ensure the long-term sustainability of certain open-source projects. We have updated the paper and sustainability plan to reflect this.
+Furthermore, since companies such as Inrupt and Digita strongly depend on this tool within their products (discussed in the usage section), they have a strong incentive to make sure that this project is maintained in the long-term, even if the current developers would move on.
+
+> There are also examples of projects using the tool, which is great, butI
+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.
+
+I may be misunderstanding the question, but the usage section already discusses two projects (Handlers.js and Digita Identity Proxy) that we as authors have no direct relationship with. These are examples of the existence of a usage community broader than just our own.
+
+> Another potential issue for impact is the need for separate componentsto deploy and maintain
+
+Each of these components can in fact be used independently. The Components.js framework can be used separately without developers even being aware of the LSD service. Optionally, the Components.js-Generator can be used if they want to automatically create their components, which significantly simplifies maintenance. Furthermore, developers are not required to publish their project to npm, as the framework will function fully without it. This is only needed if they want to enable the dereferenceability functionality of LSD. This is now explained in section 3.3.
+
+> 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.
+
+This claim was indeed too strong, our goal was merely to give usage examples. We do however have concrete evidence of the provenance trails use case, which we now point to in the conclusions section.
+
+> How does this framework allow for more flexibility than other existing
+frameworks? It's not reported.
+
+Our goal was not to claim that Components.js was more flexible than other DI frameworks (which it isn’t). Instead, DI frameworks in general provide more flexibility to applications, as they can be rewired more easily, so it is an inherent property of DI. We revised the paper to find mentions of Components.js claiming to be more flexible than other DI frameworks, but we were unable to find those.
+
+> 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)
+
+We did in fact already have a Zenodo DOI for Components.js, which was linked as a badge in the project’s README. We now also explicitly link to it within the paper. Since we do not provide a dump of the LSD service dataset, we can not give it a DOI, as this data is being updated live, and the ability to export dumps was not in scope of this work. But this is something we may consider in future work.
+
+> Many frameworks are not referenced: Spring, Guice, Dagger... And also
+companies like Inrupt and imec.
+
+We now added proper citations for these.
+
+> 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.
+
+To keep the examples as simple as possible, and the fact that real-world examples take up too much space, we decided to make use of such artificial examples. However, we now add links to real-world examples in sections 3.2 and 3.4.
+
+> ObjectMapping vocab does not have examples/human readable doc, which makes
+it a little difficult to browse.
+
+Listing 3 contains a usage example of the OM vocabulary. Due to the minimal nature of this vocabulary, we consider the Turtle representation sufficient for browsing.
+
+> UML diagrams are non readable at regular size (printed version).
+
+The UML diagrams have been moved to a (single-column) appendix so that they are better readable.