Improving Linked Data development experience with LDkit

The authors have addressed all the comments from my original review, providing detailed answers to all of them. Now the advantages and limitations of the tool are clear, and I look forward to using LDKit in the future. I think the paper should be accepted.

I highly appreciate that the reviewers addressed all my concerns and explained their revisions thoroughly.
My main concern was about the contribution of the article being too small, especially in relation to the authors' previous paper. While I of course would have preferred an extensive user experience study to verify the claims made in the previous version of the article, the authors' approach of removing those claims and emphasizing and extending the other contributions is also valid. All in all the authors added some more features to LDkit and better described the new features compared to the previous version, extended the description of LDkit's architecture, added three new, independent projects to the Usage section and added a whole new evaluation of the performance, which should be a sufficient contribution for this article.
My other concerns have also either been addressed (choosing the singular value, name of lenses, ...) or the authors provided a good justification for their choice (placement of the comparison of different tools).
Thus I would suggest to accept the article in its current form.

I have read the new version of the paper and I think it is an improvement over the previous one. The authors addressed most of my comments in a positive way and I think the paper can be published.

Some minor comments:
- Page 3, “Section 4 that provides thorough overview…”
- Page 8, “provides programming interface to query RDF…”
- Listing 1 shows an example of a BookSchema and listing 2 shows a very similar example (from a structural point of view) of a PersonSchema…adding a bit more information…I wonder if it would be better to just show the same running example about a PersonSchema or in case the authors want to show some extra features of LDKit, maybe show the examples with a different structure so they can showcase more features with both examples…maybe using some multilanguage value, an array value or 4 attributes instead of 3…
- In Listing 3, I wonder if it should be possible to use IRI as the value for $id instead of a string…does the library have an specific type for IRIs or are they treated as plain strings?
- The previous question was emphasized by the presence of Iri in listing 4 for “@id”, I am not sure why in listing 3 it is a string and in listing 4 it is an Iri…
- The example in Listing 5 is a bit poor compared with the previous examples which are using Persons or Books and here it is “MyClass” and “MyOtherClass”, I would try to find something which has more meaning in the domain chosen by the authors…maybe “Book” and “LibraryObject” or something like that…
- Page 11, “a data primitive based on XSD”, I think it should be “a primitive data based on XSD”. Nevertheless, it seems that later in the paper the authors indicate that they support other datatypes apart from the XSD ones…is that possible?, I mean, is it possible for the library to support now or in the future other primitive datatypes?
- In section 3.3.2 about properties definition, I wonder if it is possible to specify that the set of properties is closed or not. That feature is available in ShEx and is quite powerful. In ShEx it is also possible to add an EXTRA qualifier to specify that some properties can have values defined with extra types apart from the ones defined in the definition.
- Section 3.3.3 about supporting recursion seems to me a bit constrained and I wonder if it could be improved in the future. I understand that it is good enough for now, but I think the sentence that says “First, the schema must be finite to prevent infinite recursion in the resulting data” is a bit misleading. Having recursive schemas is quite common and that doesn’t imply that the data should be infinite. For example, having a Schema that says that a Person can know zero or more other Person’s, is very useful to model graph data, and although it represents potential infinite data, the data to validate a social graph doesn’t need be infinite and can be validated. I think the justification not to include recursion in the current version of LDKit can be pragmatic but could probably be marked as future work instead of saying that it raises infinite schemas or infinite data.
- In listing 7, I am not sure where it is said that the author should be a Person or Organization…as those values only appear as comments…maybe I missed something in the discussion…
- After reading the last example of section 3.3.3, I wonder if it would be possible to model the example of PersonOrOrganization using union types in TypeScript. Is it possible? If it is not in the current version, it seems it would be nice as future work…
- The algorithm presented in section 3.7 seems to require that the root nodes in the graph should have a rdf:type declaration with the value ldkit:Resource. It seems to me a strong limitation for adopting the library in real world scenarios where the data comes from heterogeneous resources and we cannot modify the data, I wonder if that constraint could be lifted by using some language technology like Shape Maps [https://shexspec.github.io/shape-map/] which have the concept of node selectors. A node selector could be used to define the root nodes from which the algorithm could start avoiding that constrain…notice that in some of the ShEx implementations of shape maps, node selectors can be SPARQL queries…so those node selectors can be quite general.
- The first sentence of section 3.9 says: “LDKit is implemented in TypeScript and requires TypeScript version 5.5 or higher…”. Thinking in the long term, LDKit could be updated in the future, so I would say, “The current version of LDKit is implemented in…” or “LDKit v2 is implemented in…” because in future versions of LDKit, the implementation language or the need for TypeScript 5.5 could change.