corrections from andreas + style changes to make it easier to read

0.2.1.x/whitepaper.md

@@ -1,24 +1,27 @@
 # RO-Crate Schema Plus - Origins, Specification, Implementation and Considerations
 
 Juan Fuentes - Principal Software Developer, Scientific IT Services, ETHZ
+Andreas Meier - Principal Software Developer, Scientific IT Services, ETHZ
 
 This document guides the reader through the complete thought process done to reach the current RO-Crate Schema Plus specification.
-This is done in one hand to attempt to explain its inner works to the less knowledgeable and on the another to allow the most knowledgeable to provide feedback.
+This is done to explain its inner workings to less knowledgeable readers while also allowing more knowledgeable ones to provide feedback.
 
 ## Origins
 [RO-Crate Schema Plus](http://researchobjectschema.org/), is born from the simple idea of bundling not only files and metadata related to those files, something RO-Crate already does, but also the schema definition of such metadata.
 
-At the end of 2024, Representatives of Scientific Information Services from the ETHZ and other representatives of ETHZ institutes like PSI and EMPA contacted the RO-Crate community since they wanted to use RO-Crate to exchange data and metadata together without the need of custom Profiles.
+At the end of 2024, representatives of Scientific Information Services at ETHZ, along with representatives from other ETHZ institutes such as PSI and EMPA, contacted the RO-Crate community because they wanted to use RO-Crate to exchange data and metadata together without the need for custom profiles.
 
 ### Why is this necessary?
-This is not a new idea, readers may be familiar with formats like CSV, when opening a CSV the user not only need to **guess** what are the content separators but also what are the data types of the columns of the CSV file, and if you have several CVS files, how are they connected between them. To **stop guessing** [CSVW](https://csvw.org/) was born, providing a secondary file that answers those questions.
+This is not a new idea. Readers may be familiar with formats like CSV. When opening a CSV file, users not only need to guess what the content separators are, but also what the data types of the columns are, and, if several CSV files are present, how they are connected to each other. To **stop guessing** [CSVW](https://csvw.org/) was created, providing a secondary file that answers those questions.
 
-The main RO-Crate Schema Plus goal is to provide the same extra information within the **ro-crate-metadata.json** file.
+The main goal of RO-Crate Schema Plus is to provide the same kind of additional information within the ro-crate-metadata.json file.
 
 ### JSON-LD limitations
-RO-Crate provides a file, **ro-crate-metadata.json**, written using JSON-LD, it uses by default [schema.org]([http://schema.org) types plus some added by RO-Crate itself.
+RO-Crate provides a file, **ro-crate-metadata.json**, written using JSON-LD. By default, it uses [schema.org]([http://schema.org) types, along with some types added by RO-Crate itself.
 
-RO-Crate uses JSON-LD to represent its metadata and, as a result, also shares its limitations. JSON-LD provides a context, this context provides **semantics**, can tell you what things are, but it doesn't tell you their schema fields, data types, relationships, etc. In other words **semantics don't substitute schema**.
+RO-Crate uses JSON-LD to represent its metadata and, as a result, also shares its limitations. JSON-LD uses a context to provides **semantics**, can describe you what things are, but it does not define their schema fields, data types, relationships, and so on. In other words **semantics do not substitute schema**.
+
+RO-Crate provides a file, ro-crate-metadata.json, written using JSON-LD. By default, it uses schema.org types, along with some types added by RO-Crate itself.
 
 This shortcomings are best illustrated with an example.
 
@@ -65,21 +68,21 @@ This shortcomings are best illustrated with an example.
 }
 ```
 
-On the example above, the provided URL on the context leads on this case to a second document [https://w3id.org/ro/crate/1.1/context](https://w3id.org/ro/crate/1.1/context). This second document provides another context, this time leading to schema.org URLs. Sadly URLs like ["http://schema.org/CreativeWork"]("http://schema.org/CreativeWork")  are not only **not machine actionable** but may be gone for the time a user wants to read those URLs, the so called **link rot** problem.
+In the example above, the provided URL in the context leads, in this case, to a second document [https://w3id.org/ro/crate/1.1/context](https://w3id.org/ro/crate/1.1/context). This second document provides another context, this time leading to schema.org URLs. Unfortunately, URLs such as ["http://schema.org/CreativeWork"]("http://schema.org/CreativeWork")  are not **machine-actionable** and may no longer be available when a user attempts to access them, a problem known as **link rot**.
 
 ### Community Segregation
-The shortcomings of the format illustrated on the previous section leads RO-Crate users to need to create their own contexts with their own types and requirements only custom parsers have knowledge about. This is what RO-Crate labels as [profiles](https://www.researchobject.org/ro-crate/profiles.html).
+The shortcomings of the format illustrated in the previous section lead RO-Crate users to create their own contexts, with their own types and requirements, which are only understood by custom parsers. This is what RO-Crate refers to as [profiles](https://www.researchobject.org/ro-crate/profiles.html).
 
-This could be considered a strength because it makes the format quite extensible, but in practice also makes it a weakness, to exchange general information within a domain a new Profile may be required to add new types to the context and such context would need to be available, creating a new sub community that will more likely be segregated from the main community.
+This could be considered a strength, as it makes the format highly extensible. However, in practice, it also represents a weakness: to exchange general information within a domain, a new profile may be required to add new types to the context, and that context must be made available. This can result in the creation of a new subcommunity that is more likely to become segregated from the main community.
 
 ## Specification
-How can JSON-LD limitations and profile limitations be addressed? Or in other words, how could a schema/profile be specified within RO-Crate?
+How can the limitations of JSON-LD and profiles be addressed? In other words, how could a schema or profile be specified within RO-Crate?
 
-Since RO-Crate provides a single file, **ro-crate-metadata.json**, written using JSON-LD, it would be a requirement to be provided within such file and using JSON-LD.
+Since RO-Crate provides a single file, **ro-crate-metadata.json**, written using JSON-LD, any such schema or profile would need to be provided within that file and expressed using JSON-LD.
 
-Quickly looking at how schema.org distributes its schema, we find it [downloads](https://schema.org/docs/developers.html) using a variety of formats, including a [JSON-LD download](https://schema.org/version/latest/schemaorg-current-https.jsonld). How can they manage this? Because schema.org specifies its schema in RDF that is serializable in different formats including JSON-LD.
+Looking at how schema.org distributes its schema, we find that it [downloads](https://schema.org/docs/developers.html) in a variety of formats, including a [JSON-LD download](https://schema.org/version/latest/schemaorg-current-https.jsonld). How is this possible? Because schema.org specifies its schema in RDF, which can be serialized in different formats, including JSON-LD.
 
-How this looks in practice?
+How does this look in practice?
 
 *Example from [JSON-LD download](https://schema.org/version/latest/schemaorg-current-https.jsonld).*
 
@@ -121,51 +124,51 @@ How this looks in practice?
 }
 ```
 
-As the example above shows, schema.org provides a list of RDF classes and properties formatted as JSON-LD. This content could easily fit into the RO-Crate object graph inside **ro-crate-metadata.json**, without additions to the current RO-Crate standard, so this addition is backwards compatible.
+As the example above shows, schema.org provides a list of RDF classes and properties formatted as JSON-LD. This content could easily fit into the RO-Crate object graph inside ro-crate-metadata.json without requiring any changes to the current RO-Crate standard, making it backwards compatible.
 
 ## Implementation
 
 ## Writing the schema
-Here comes the most challenging part: both class and property descriptions in RDF are too complex for end users to be expected to understand. Furthermore if you would understand them RO-Crate imposes additional restrictions, like it's object graph should be a list of objects without nesting what makes definitions hardly human readable. This challenges make the use of extra tools unavoidable.
+Here comes the most challenging part: both class and property descriptions in RDF are too complex for end users to be expected to understand. Furthermore, RO-Crate imposes additional restrictions, like it's object graph should be a list of objects without nesting what makes definitions hardly human readable. These challenges make the use of extra tools unavoidable.
 
-Ideally, users should rely on platforms that can import and export RO-Crate Schema Plus packages implementing this structure. Even though the complexity shifts to the system integrators of this extension, software libraries that provide an abstraction layer while hiding the underlying RDF details can greatly support adoption.
+Ideally, users should rely on platforms that can import and export RO-Crate Schema Plus packages implementing this structure. Although the complexity shifts to system integrators, software libraries that provide an abstraction layer while hiding the underlying RDF details can greatly support adoption.
 
 ## Interpreting the schema
-Considering two systems trying to integrate with each other, implementing correctly embedding schema withing their RO-Crate Schema Plus metadata files.  Now with different systems having the possibility to exchange different schemas on the fly, a disparity of schemas that other systems may or not be able to interpretate surfaces, at the end every system has its own internal data model that will be translated more or less directly to what is shared.
+Consider two systems attempting to integrate with each other, each correctly embedding a schema within their RO-Crate Schema Plus metadata files. With different systems now able to exchange schemas dynamically, disparities between schemas may arise that other systems may or may not be able to interpret. Ultimately, each system has its own internal data model, which is translated more or less directly into what is shared.
 
-Assuming different schemas sharing similar information a currently acceptable way to deal with is by setting semantic ontology equivalencies.  
-- "owl:equivalentClass" : means _“these two classes describe the same kind of thing.”_
-- "owl:equivalentProperty" means “these two properties mean the same thing.”
+When different schemas share similar information, a currently acceptable way to handle this is by defining semantic ontology equivalences:
+- "owl:equivalentClass": means _“these two classes describe the same kind of thing.”_
+- "owl:equivalentProperty": means “these two properties mean the same thing.”
 
-In other words, **schema doesn't substitute semantics**.
+In other words, **schema does not substitute semantics**.
 
 In an ideal scenario, where a RO-Crate Schema Plus package includes the schema, metadata, and files, the only remaining task for system-to-system integration would be to define the equivalences between their schemas.
 
-Finding these equivalencies can become now a point of contention when doing system integrations where there is not a well stablished ontology.
+Finding these equivalences can become a point of contention during system integration, especially when there is no well-established ontology.
 
-Since it seems to not to be a well stablished framework to make such choices, this choices end up being more political than technical choices.
+Since there does not appear to be a well-established framework for making such decisions, these choices often end up being more political than technical.
 
 ## Considerations
 
-### When importing a RO-Crate Schema Plus package by other system what is its expected behavior?
-Different systems are intended for different purposes and their behavior depends on both their purpose and their limitations. We would classify systems under two criteria:
+### When importing a RO-Crate Schema Plus package into another system, what is its expected behavior?
+Different systems are intended for different purposes, and their behavior depends on both their purpose and their limitations. We classify systems under two criteria:
 
-Purpose of the System:
-- Specific: Registers only information from schemas and semantics recognize.
-- General: Register all kinds of information, even if they don't recognize the purpose of their schema or semantics. 
+Purpose of the system:
+- Specific: Registers only information from schemas and semantics it recognizes.
+- General: Registers all kinds of information, even if it does not recognize the purpose of the schema or semantics.
 
-System behavior when dealing with Exceptional Situations:
-- Error: Any information found outside schemas and semantics the system recognizes leads to an error, canceling the complete registration.
-- Ignore: Any information found outside schemas and semantics the system recognizes is ignored, completing a partial registration.
+System behavior when dealing with exceptional situations:
+- Error: Any information found outside schemas and semantics that the system recognizes leads to an error, canceling the entire registration.
+- Ignore: Any information found outside schemas and semantics that the system recognizes is ignored, resulting in a partial registration.
 
-This is not a behavior limited to RO-Crate Schema plus, but to any kind of integration using a common format. As such, this is not defined by RO-Crate Schema plus.
+This behavior is not limited to RO-Crate Schema Plus but applies to any integration using a common format. As such, it is not defined by RO-Crate Schema Plus.
 
 ### Packaging of data
-RO-Crate schema plus doesn't define how to package data within RO-Crate.
+RO-Crate Schema Plus does not define how data should be packaged within RO-Crate.
 
-Our current interpretation of the RO-Crate standard is that it already establishes that CreativeWork, DataSet, etc. are entities with hasPart and that they own the data. 
+Our current interpretation of the RO-Crate standard is that it already establishes that CreativeWork, DataSet, etc., are entities with hasPart, and that they own the data.
 
-To attach data to an object in the graph, such object class should inherit from or intersect with those classes.
+To attach data to an object in the graph, such an object class should inherit from or intersect with those classes.
 
 ## Acknowledgments
 
@@ -173,7 +176,7 @@ RO-Crate Schema Plus specification: Andreas Meier (SIS, ETHZ), Juan Fuentes (SIS
 
 RO-Crate Schema Plus Reference Java library: Andreas Meier (SIS, ETHZ)
 
-RO-Crate Schema Plus Python Library:  Pascal Su (EMPA) and Simone Baffelli (EMPA)
+RO-Crate Schema Plus Python Library:  Pascal Su (EMPA), Simone Baffelli (EMPA)
 
 SciCat and SciLog RO-Crate Schema Plus ongoing integrations: Carlo Minotti (PSI), Frédéric Pontier (PSI), Omkar Zade (PSI)