lock down version 0.0.1

README.md

@@ -2,7 +2,7 @@
 ATA defines a standard, programming language-agnostic interface description for REST APIs, which allows both humans and computers to discover and understand the capabilities of a service without requiring access to source code or inspection of network traffic. When an API conforms to ATA, a consumer can understand and interact with the remote service with a minimal amount of implementation logic. Similar to what interface descriptions have done for lower-level programming, ATA removes guesswork in calling a service.
 Use cases for machine-readable API definition documents include, but are not limited to: interactive documentation; code generation for documentation, clients, and servers; and automation of test cases. ATA documents describe an API's services and are represented in either YAML or JSON formats. These documents may either be produced and served statically or be generated dynamically from an application.
 
-The current version of the AgTech API Specification is [Version 0.0.1](versions/0.0.1.md). The next version will be 0.0.2.
+The current version of the AgTech API Specification is [Version 0.0.1](versions/0.0.1). The next version will be 0.0.2.
 
 ### See It in Action
 
@@ -14,9 +14,10 @@ Development of ATA is guided by the Technical Steering Committee (TSC). All deve
 The TSC holds weekly web conferences to review open pull requests and discuss open issues related to ATA. Participation in weekly calls and scheduled working sessions is open to the community.
 Open AgTech encourages participation from individuals and companies alike. If you want to participate in the evolution of ATA, consider taking the following actions:
 
-- Review the current specification. The human-readable markdown file is the source of truth for the specification.
+- Review the current specification, in [master](versions/master).
 - Review the development process so you understand how the spec is evolving.
 - Check the issues and pull requests to see if someone has already documented your idea or feedback on the specification. You can follow an existing conversation by adding a comment to the existing issue or PR.
 - Create an issue to describe a new concern. If possible, propose a solution.
+- Open a PR related to your issue or concern. This will be reviewed and merged by the TSC.
 
 Not all feedback can be accommodated and there may be solid arguments for or against a change being appropriate for the specification.

versions/0.0.1/README.md

@@ -0,0 +1,13 @@
+# API Specification
+This directory contains the various parts of the open API specification for exchanging data and operational control in indoor agricultural environments.  
+
+The specification is divided into the following sub-sections to make it easier to follow...
+
+* **General** - contains all of the essential rules that need to be followed, including common concepts, common data structures, timestamp formats, error handling, and so on.
+* **Plan** - specifies the API for interacting with the basic concepts of a well-planned facility (compartments, zones, crop varieties, and so on)
+* **Lights** - specifies the API for interacting with lighting systems
+* **Air** - specifies the API for interacting with air control systems (heating, cooling, ventilation, humidity, and so on)
+* **Soil** - specifies the API for interacting with soil monitoring systems
+* **Roots** - specifies the API for interacting with root monitoring systems
+* **Reservoirs** - specifies the API for interacting with reservoir control systems
+* **Nutrients** - specifies the API for monitoring nutrients

versions/0.0.1/air.md

@@ -0,0 +1,22 @@
+# Purpose
+
+This specification is intended to define a standardized way of communicating with climate control systems for real-time monitoring and control of air quality and to allow data collection between control systems and / or peripheral devices.
+
+# Scope
+
+The scope of this document is limited to providing a payload structure and endpoint type definitions to allow basic control and data acquisition. The addition of product specific features is left to the implementer, but to be in compliance the product must support the basic set of features specified below.
+
+# Definitions
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
+
+# Endpoints
+## Sensors
+### URLS
+### Measurements
+| Data point | Description                      | Unit    |
+| ---------- | -------------------------------- | ------- |
+| temp       | The temperature of the air       | celsius |
+| humidity   | The level of humidity in the air | %       |
+| co2        | The level of CO2 in the air      | ppm     |
+| airflow    | The speed of the airflow         | m3/s    |