Fixed grammar and sentence structure

applications/argo.md

@@ -24,7 +24,7 @@ name: argo_workflows
 Argo Workflow server
 ```
 
-Argo Workflows also provides detailed logs for all executions, enabling workspace administrator to monitor behavior, trace failures, and debug issues.
+Argo Workflows also provides detailed logs for all executions, enabling workspace administrators to monitor behavior, trace failures, and debug issues.
 
 ```{figure} assets/argo_workflow_single_job.png
 ---
@@ -33,7 +33,7 @@ name: argo_workflow_single_job
 Argo Workflows details of a finished workflow with details of a step
 ```
 
-Sample templates will become available in the tutorial section once possible
+Sample templates will become available in the tutorial section when possible.
 
 ## Capability requirements for integration
 
@@ -71,4 +71,4 @@ Argo Workflow Server built in resource usage metrics
 ## Related use cases
 
 - [Generate Results](../use_cases/result_generation.md)
-- [Provide an Algorithm as a Service](../use_cases/algorithm_as_a_service.md)
+- [Provide an Algorithm as a Service](../use_cases/algorithm_as_a_service.md)

applications/argo/capability_integration.md

@@ -1,40 +1,40 @@
 # Integration Requirements for Argo Workflows on EOxHub
 
-This document is intended as support material to describe how to best provide a capability implementation and its description in order to allow EOX to integrate it as a workflow inside of an EOxHub Workspace. This includes input definitions, expected Docker image standards, and output formats.
+This document is intended as support material describing how to provide a capability implementation and its description so that EOX can integrate it as a workflow within an EOxHub Workspace. This includes input definitions, expected Docker image standards, and output formats.
 
 ## Input Requirements
 
-To ensure compatibility with various interfaces (e.g. OGC Process API) to allow on demand execution of the capability some input requirements need to be considered. Furthermore information providing more context is needed regarding following points:
+To ensure compatibility with various interfaces (e.g. OGC Process API) and allow on-demand execution of the capability, some input requirements need to be considered. Furthermore, additional information is needed regarding the following points:
 
 - Description of expected input data - does the service expect data already present or data are downloaded as part of the dockerized algorithm?
-- Description of expected argument and parameters
+- Description of expected arguments and parameters
 - Description of expected output - see Output requirements section
 
 
 ### Arguments and parameters
 
-eodash processing widget support multiple ways how to pass input. 
-- Area/location - process can take as input drawn point or polygon from the eodash user interface. For this integration, input field must accept eather coorinates directly or geoJSON as a string. File input is not accepted. 
-    - Example GeoJSON Feature String '{"type":"Feature","geometry":{"type":"Polygon" "coordinates":[[[30,10],[40,40],[20,40],[10,20],[30,10]]]},"properties":{}}'
-- Date - standard HTML Format date formats are supported. eodash also supports start and end time to create range. 
+The eodash processing widget supports multiple ways of passing input. 
+- Area/location - the process can take a drawn point or polygon as input from the eodash user interface. For this integration, the input field must accept either coordinates directly or GeoJSON as a string. File input is not accepted.
+    - Example GeoJSON Feature String '{"type":"Feature","geometry":{"type":"Polygon","coordinates":[[[30,10],[40,40],[20,40],[10,20],[30,10]]]},"properties":{}}'
+- Date - standard HTML date formats are supported. eodash also supports start and end times to create a range. 
     - "YYYY-MM-DD" e.g. 2015-05-30 for date.
     - "YYYY-MM-DDThh:mm" for datetime 2025-07-02T06:33 
 - Numeric fields - integer or float values
 - Text fields
 - Dropdowns with limited options
 
 
-All fields can have default value
+All fields can have a default value
 
 
 ## Docker Image Requirements
 
 Your process must be encapsulated in a Docker image. There are no strict limitations of what can be done, but there are good practices that help integration:
 
-- image is "slim" - only with required dependencies installed
-- image is tagged with version based on [semantic versioning](https://semver.org/)
-- algorithm logs to standard out (stdout) helping debug potential issues
-- simpler if no sideloading/sidecars (docker in docker) and similar
+- The image is "slim" - only the required dependencies are installed.
+- The image is tagged with a version based on [semantic versioning](https://semver.org/).
+- The algorithm logs to standard output (stdout) helping to debug potential issues.
+- Avoid sideloading/sidecars (Docker in Docker) and similar additional services where possible to keep the structure simple
 - no special volumes, network expectations, ...
 
 We expect to know resource usage estimation - RAM consumption and CPU estimates.
@@ -47,7 +47,7 @@ The workflow should store its results in `/output` folder, which will be collect
 
 Expected outputs:
 - Results (e.g., COG, geoJSON, CSV)
-  - Inputs are expected to be cloud-native so for raster output formats, COGs are expected, for vector data geoJSON for small files up to 5Mb or flatGeobuf 
+    - Inputs are expected to be cloud-native. For raster output formats, COGs are expected; for vector data, GeoJSON is recommended for small files up to 5 MB, or FlatGeobuf for             larger files.
 - Logs (optional but encouraged)
 
 
@@ -59,7 +59,7 @@ Outputs must be:
 
 ##  Sample Checklist
 
-To submit your process for integration, make sure these information are included:
+To submit your process for integration, make sure this information is included:
 - [ ] Dockerfile included and builds correctly
 - [ ] README with usage instructions and input/output description
 - [ ] Sample call example
@@ -69,4 +69,4 @@ To submit your process for integration, make sure these information are included
 
 ---
 
-Please contact the EOxHub team or submit a ticket if youneed more information.
+Please contact the EOxHub team or submit a ticket if you need further information.

applications/conda_store.md

@@ -1,6 +1,6 @@
 # Conda Store
 
-Within each user workspace where JupyterLab is provisioned also a dedicated [Conda Store](https://conda.store/) is available.
+Within each user workspace where JupyterLab is provisioned, a dedicated [Conda Store](https://conda.store/) is also available.
 
 
 
@@ -13,9 +13,9 @@ name: conda-store2
 Conda store User interface
 ```
 
-Dedicated environments can be produced based on the user rights either for a user themselves or for a whole workspace and shared with colleagues or other people.
+Dedicated environments can be created based on user permissions, either for an individual user or for an entire workspace, and shared with colleagues or other users.
 
-Conda Store supports GUI or yaml syntax for environment creation and examples and how to guides can be found in the official [documentation](https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html)
+Conda Store supports a GUI or YAML syntax for environment creation. Examples and how-to guides can be found in the official [documentation](https://docs.conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html).
 
 ```{figure} assets/conda_store.png
 ---

applications/container_registry.md

@@ -1,6 +1,6 @@
 # Container Registry
 
-We use **Zot Registry** - a lightweight, OCI-native container image registry - as repository for storing and managing container images within EOxHub Workspaces.
+We use **Zot Registry** - a lightweight, OCI-native container image registry - as a repository for storing and managing container images within EOxHub Workspaces.
 You can easily push your custom images to Zot and pull them directly into your **Argo Workflows**.
 
 The login credentials can be found in the secret **registry-login** in the [credentials manager](./secret_manager.md) of your workspace.
@@ -27,7 +27,7 @@ Authenticate with the endpoint and push your locally built images using standard
     docker tag my-image:latest registry.[workspace-name].[cluster].eox.at/my-image:latest
     ```
 
-3. Push image to registry
+3. Push the image to the registry
 
     ```shell
     docker push registry.[workspace-name].[cluster].eox.at/my-image:latest
@@ -46,4 +46,4 @@ Update your Argo Workflow templates to point to the Zot registry URL in your `co
 ## Related use cases
 
 - [Develop an Algorithm](../use_cases/algorithm_development.md)
-- [Provide an Algorithm as a Service](../use_cases/algorithm_as_a_service.md)
+- [Provide an Algorithm as a Service](../use_cases/algorithm_as_a_service.md)

applications/data_editor.md

@@ -1,6 +1,6 @@
 # Data Editor
 
-The Data Editor application, provides a traceable review and approval path of collection configurations before data is published to the configured STAC catalog. This STAC catalog is used in the [Publishing Dashboard](publishing_dashboard.md) which is based on [eodash](https://eodash.org).
+The Data Editor application provides a traceable review and approval path for collection configurations before data is published to the configured STAC catalog. This STAC catalog is used in the [Publishing Dashboard](publishing_dashboard.md) which is based on [eodash](https://eodash.org).
 
 It is based on [git-clerk](https://github.com/EOX-A/git-clerk) - Open-Source Content Management System based on Git workflows with a friendly file-editing GUI.
 
@@ -58,7 +58,7 @@ Currently supported data (resource) types are:
 * Copernicus Marine Data Store WMTS
 
 
-List of all supported resources is kept up to date on [eodash wiki](https://github.com/eodash/eodash_catalog/wiki/Resource) so please visit this site as well. 
+A list of all supported resources is kept up to date on the [eodash wiki](https://github.com/eodash/eodash_catalog/wiki/Resource), so please visit this site as well.
 
 
 
@@ -68,17 +68,17 @@ All required fields are marked in the Data Editor. More information about each o
 
 ## Overview of the process
 
-Generally for including a supported type of EO collection into an eodash deployment within EOxHub, the steps are summarized as follows:
+Generally, to include a supported type of EO collection in an eodash deployment within EOxHub, the steps are as follows:
 
 - Start a new `session` in the Data Editor and create a new collection configuration file.
-- Fill metadata fields split into thematic groups. Mainly filling the [Resource](https://github.com/eodash/eodash_catalog/wiki/Resource) is important to visualize the data on the web map.
-- For raw data and client only rendering (GeoJSON, flatgeobuf or GeoTIFF as direct access), eodash supports an [OpenLayers flatstyle](https://openlayers.org/en/latest/apidoc/module-ol_style_flat.html). More information on styling can be [found here](https://eodash.org/styling.html#vector-styling).
-- eodash project offers [eodash-style-editor](https://github.com/eodash/eodash-style-editor) for editing the flatstyle definitions with updating the visualization in real time when definition is changed
+- Fill in the metadata fields, which are split into thematic groups. Filling in the [Resource](https://github.com/eodash/eodash_catalog/wiki/Resource) field is particularly important for visualizing the data on the web map.
+- For raw data and client-only rendering (GeoJSON, FlatGeobuf, or GeoTIFF as direct access), eodash supports an [OpenLayers flat style](https://openlayers.org/en/latest/apidoc/module-ol_style_flat.html). More information on styling can be [found here](https://eodash.org/styling.html#vector-styling).
+- The eodash project offers [eodash-style-editor](https://github.com/eodash/eodash-style-editor) for editing flat style definitions and updating the visualization in real time as the definition changes.
 - To define interactions for the user (e.g. modify the style within the eodash app), the style can be extended with variables, combined with [JSON Form definition](https://eox-a.github.io/EOxElements/?path=/docs/elements-eox-jsonform--docs).
-- After finishing the updates confirmed by the layer live preview panel and approving of the corresponding Data editing session (GitHub Pull Request), the changes can be merged to production catalog.
+- After confirming the updates in the layer live preview panel and approving the corresponding Data Editor session (GitHub pull request), the changes can be merged into the production catalog.
 
 
-For learning how to include your data in Narrative publication, read the section [**Narrative Editor**](../applications/narrative_editor.md) and follow the tutorial [**Creating Narrative**](../tutorials/narrative_tutorial.md)
+For learning how to include your data in Narrative publication, read the section [**Narrative Editor**](../applications/narrative_editor.md) and follow the tutorial [**Get Started with the Narrative Editor**](../tutorials/creating_narratives/introduction_narrative_editor.md)
 
 
 ## Related tutorials
@@ -91,4 +91,4 @@ For learning how to include your data in Narrative publication, read the section
 
 ## Related use cases
 
-- [Publish Insights](../use_cases/publish_insights.md)
+- [Publish Insights](../use_cases/publish_insights.md)

applications/eoapi.md

@@ -2,7 +2,7 @@
 
 EOxHub includes robust data visualization capabilities for both raster and vector data based primarily on [eoapi](https://eoapi.dev/). These are powered by [titiler-pgstac](https://github.com/stac-utils/titiler-pgstac) and [PgSTAC](https://github.com/stac-utils/pgstac), which together enable dynamic tiling and rendering of STAC-compliant assets directly from storage based on pre-defined collection-level metadata fields.
 
-It exposes a [FastAPI](https://fastapi.tiangolo.com/) based interface, supporting image formats such as PNG and JPEG, and standard interfaces like WMTS.
+It exposes a [FastAPI](https://fastapi.tiangolo.com/)-based interface, supporting image formats such as PNG, JPEG and standard interfaces such as WMTS.
 
 Future tutorials for eoAPI will become available in the tutorial section once possible.
 
@@ -19,7 +19,7 @@ Ingesting the existing STAC items to the database can be done in multiple ways:
 
 ### Make it Searchable
 
-This service utilizes `stac-fastapi` to publish and manage metadata describing their datasets, enabling machine-readable search, query, filter and cataloging across collections.
+This service utilizes `stac-fastapi` to publish and manage metadata describing its datasets, enabling machine-readable search, querying, filtering, and cataloging across collections.
 
 ![eoapi_stac](assets/eoapi_stac.png)
 
@@ -32,7 +32,7 @@ titiler-pgSTAC is a TiTiler extension that connects to pgSTAC to support large-s
 
 ### Visualize Vector Data
 
-Utilizing [tipg](https://github.com/developmentseed/tipg) - Vector Tiling Service  for OGC Features and OGC Tiles specifications.
+It utilizes [tipg](https://github.com/developmentseed/tipg), a Vector Tiling Service for the OGC Features and OGC Tiles specifications.
 
 ![tipg](assets/tipg.png)
 

applications/file_browser.md

@@ -17,9 +17,9 @@ The **File Browser** is a web-based file management application integrated into
 
 EOxHub Workspace employs a public access system to facilitate sharing and accessing datasets:
 
-- **Public Folder**: Files placed in the `public` directory are accessible via permanent public URLs, allowing for easy sharing and integration into other applications e.g. [Data Editor](data_editor).
+- **Public Folder**: Files placed in the `public` directory are accessible via permanent public URLs, allowing for easy sharing and integration into other applications, e.g. the [Data Editor](data_editor).
 - **Shareable Links**: Users can generate shareable links for specific files or folders, providing controlled access to external collaborators.
-- **Access Control**: All areas within the File Browser are restricted to be accessed only by users of the workspace. Data in the `public` folder is openly accessible. By using the creation of shareable links other files can be made accessible to external people.
+- **Access Control**: All areas within the File Browser can only be accessed by users of the workspace. Data in the `public` folder is openly accessible. Shareable links can be used to make other files accessible to external users.
 
 
 ## Related tutorials
@@ -29,4 +29,4 @@ EOxHub Workspace employs a public access system to facilitate sharing and access
 ## Related use cases
 
 - [Develop an Algorithm](../use_cases/algorithm_development.md)
-- [Publish Insights](../use_cases/publish_insights.md)
+- [Publish Insights](../use_cases/publish_insights.md)

applications/jupyterlab.md

@@ -15,7 +15,7 @@
 - View and edit CSVs, images, and text files
 - Use drag-and-drop functionality across tabs
 
-In the context or EOxHub Workspaces, JupyterLab comes pre-configured with common EO and geospatial libraries, making it ideal for analysis, visualization, and prototyping. For more information, please visit the official [documentation](https://jupyterlab.readthedocs.io/)
+In the context of EOxHub Workspaces, JupyterLab comes pre-configured with common EO and geospatial libraries, making it ideal for analysis, visualization, and prototyping. For more information, please visit the official [documentation](https://jupyterlab.readthedocs.io/)
 
 ---
 
@@ -25,9 +25,9 @@ When launching JupyterLab in EOxHub, you will be asked to choose a **user profil
 
 These are examples of common profiles based on the chosen subscription plan:
 
-- **Trial Profile**: Ideal for lightweight exploration and testing, usually avavilable in workshop settings or trials
+- **Trial Profile**: Ideal for lightweight exploration and testing, usually available in workshop settings or trials
 - **Standard Profile**: Recommended for moderate EO processing
-- **Large Profile**: For heavy workloads (model training, large-scale analysis) or usage of GPPU
+- **Large Profile**: For heavy workloads (model training, large-scale analysis) or GPU usage
 
 If your use case requires more resources, longer runtimes or GPU, please reach out to request a **custom setup**.
 

applications/publishing_dashboard.md

@@ -2,7 +2,7 @@
 
 The Publishing Dashboard provides a user-facing web interface for presenting and distributing curated datasets and narratives. It centers interactive maps and charts, as well as search and filter capabilities, and can be configured for public sharing or restricted access for defined user groups. 
 
-Daily operation does not require coding skills or deep technical knowledge: content and configuration are maintained via the Data Editor and Narrative Editor, other applications available inside the EOxHub workspace together with the dashboard.
+Daily operation does not require coding skills or deep technical knowledge: content and configuration are maintained via the Data Editor and Narrative Editor, together with other applications available inside the EOxHub Workspace.
 
 The Publishing Dashboard is based on **[eodash](https://eodash.org/)**, **[EOxElements](https://eox-a.github.io/EOxElements/)** and **[vitepress](https://vitepress.dev/)**. It is a web client instance connected to the information managed in the [Data Editor](data_editor.md) as well as the [Narrative Editor](narrative_editor.md).
 
@@ -29,7 +29,7 @@ name: eodashboard narratives screenshot
 Narratives overview screenshot from eodashboard.org
 ```
 
-For more information on how to manage the published data content please have a look at the [Data Editor](data_editor.md) section, or for managing narratives at the [Narrative Editor](narrative_editor.md) section.
+For more information on managing published data content, please see the [Data Editor](data_editor.md) section; for managing narratives, see the [Narrative Editor](narrative_editor.md) section.
 
 ## Related tutorials
 
@@ -44,4 +44,4 @@ For more information on how to manage the published data content please have a l
 ## Related use cases
 
 - [Provide an Algorithm as a Service](../use_cases/algorithm_as_a_service.md)
-- [Publish Insights](../use_cases/publish_insights.md)
+- [Publish Insights](../use_cases/publish_insights.md)