Moving Planning folder

planning/README.md

@@ -0,0 +1,91 @@
+# Thing Description Planning
+
+In this folder, you can find resources to help with understanding how the next version of the Thing Description deliverable is planned.
+First, work items are listed and then a roadmap with priorities is provided per category.
+
+## Work Items
+
+### Categories
+
+The work items are split into four categories.
+
+1. [Binding Templates](./td-next-work-items/binding-templates.md): The first category is Binding Templates, which involves specifying the mechanism but also the submission mechanism.
+2. [Usability and Design](./td-next-work-items/usability-and-design.md): The second category focuses on work items that are more about restructuring, redesigning, and improving the usability of the specification. These could pave the way for new features.
+3. [New Features](./td-next-work-items/new-features.md): The third category is about work items that are directly linked to new features.
+4. [Testing and Tooling](./td-next-work-items/testing-and-tooling.md): The fourth category is comprised of items that help the specification management and maintain consistency.
+
+Such categories can be reflected with labels and different views in the GitHub project management panel.
+The task force will go through existing issues, pull requests, and discussions, and categorize them accordingly.
+
+- **Priorities:** The items in each markdown under [td-next-work-items](./td-next-work-items) are a flat list with no priorities set for now. Ideally, items that are dependencies to other items and those with concrete industry use cases will be prioritized.
+
+- **Details:** The details of different work items can be found at <https://github.com/w3c/wot/blob/main/proposals/deliverable-proposals/thing-description.md>. We will consolidate such details and link them appropriately.
+
+#### Related Resources
+
+In addition to GitHub issues and Use Cases, there are various documents that should be read before starting the work
+
+- Long Running Actions Proposals: <https://github.com/w3c/wot-thing-description/tree/main/proposals>
+- Registry Analysis: <https://github.com/w3c/wot/tree/main/registry-analysis>
+- Historical Data Landscape: <https://github.com/w3c/wot/pull/1112>
+- Charter Details: <https://w3c.github.io/wot-charter-drafts/wot-wg-2023-details.html>
+
+### Notes
+
+- The points below are still open to discussion:
+  - What to do with the existing issues and PRs that are postponed?
+    - Option 1: If there are no use cases identified, they can be closed after some time.
+  - What about the work items in the charter or details that are not linked to use cases?
+
+## Roadmap
+
+We should have a roadmap for the TD specification that is aligned with the charter start and end dates.
+Concrete roadmaps with the order of items are below at [Individual Roadmaps](#individual-roadmaps).
+
+### Charter-Related Information
+
+#### WoT WG Charter Details
+
+- Charter End Date: 2 October 2025
+- CR Transition (feature freeze): July 10, 2025 (worst estimate)
+- Charter Start: October 2023
+
+#### Schedule for TD Deliverable
+
+- We will stop work big features 6 months prior to the CR Transition. That means January 10, 2025. In other words, we should be done with big features by the end of 2024. Please see https://github.com/w3c/wot/blob/main/planning/schedule.md
+- As a result, we should indicate whether a feature is considered a big feature. Some notes on this:
+  - The bigger the implementation impact, the more time to implement.
+  - We can give something like "Story Points" to give a rough idea of the effort.
+
+### Category-based Roadmaps
+
+Each section contains a list of work items to be done in an order.
+
+#### Specification Refactoring
+
+1. [Incorporating Binding Mechanism](./td-next-work-items/binding-templates.md#binding-templates-integration)
+2. [Synchronization with other documents](./td-next-work-items/usability-and-design.md#synchronization-with-other-documents) (might be a long process, so it should happen asynchronously or in the background with syncs in the calls)
+3. [Common definitions section](./td-next-work-items/usability-and-design.md#common-definition-section)
+4. [Grouping of normative requirements](./td-next-work-items/usability-and-design.md#grouping-of-normative-requirements)
+5. [Better Integration of Thing Model](./td-next-work-items/usability-and-design.md#better-integration-of-thing-model)
+6. [Security Schemes Refactoring](./td-next-work-items/usability-and-design.md#security-schemes-refactoring)
+
+#### Specification Tooling
+
+1. [Specification Generation Tooling](./td-next-work-items/testing-and-tooling.md#spec-generation)
+2. [Example reorganization](./td-next-work-items/testing-and-tooling.md#examples-reorganization)
+
+#### Implementation Report Testing
+
+1. [Testing Pipeline](./td-next-work-items/testing-and-tooling.md#testing-procedure) (less priority since we are not close to the testing phase at all)
+
+#### Usability and Design
+
+An example list of usability and design items with an order:
+
+- Initial connection
+- Data mapping
+
+#### New Features
+
+They are not ordered yet. See [here](./td-next-work-items/new-features.md) for more information.

planning/work-items/README.md

@@ -0,0 +1,4 @@
+# Categorized Work Items
+
+The documents here detail the work items per category.
+The filename is the category name.

planning/work-items/analysis/analysis-historical-data-work-item.md

@@ -0,0 +1,64 @@
+# [DRAFT] Analysis of Historical Data Work Item
+
+This document gathers all information related to time series or historical data-related topics.
+These include issues, use cases, and discussions in other forms.
+This document will be worked on before extending the TD specification.
+
+## Overall Description of the Topic
+
+Some edge and cloud services can collect property value changes or event emissions for a certain time.
+This data, called time series, can be collected by Consumers to display (or use in any other way) the evolution of the affordance data over time.
+
+This topic is also known as:
+
+- Time series
+- Data Trend
+
+## Use Cases
+
+To find the related use cases, the [coverage document](https://github.com/w3c/wot-usecases/blob/main/USE-CASES/coverage.csv) has been used and another pass through the [use cases document](https://w3c.github.io/wot-usecases) has been made.
+
+- [Smart Agriculture - Greenhouse Horticulture](https://w3c.github.io/wot-usecases/#smart-agriculture)
+- [Smart Agriculture - Open-field Agriculture](https://w3c.github.io/wot-usecases/#smart-agriculture-openfield)
+- [Smart City - Geolocation](https://w3c.github.io/wot-usecases/#smartcity-geolocation)
+- [Smart City - Dashboard](https://w3c.github.io/wot-usecases/#smartcity-dashboard)
+- [Smart City - Connected Building Energy Efficiency](https://w3c.github.io/wot-usecases/#connected-building-energy-efficiency)
+- [Digital Twin - Digital Twin 2](https://w3c.github.io/wot-usecases/#digital-twin-2)
+- [VR/AR - AR Virtual Guide](https://w3c.github.io/wot-usecases/#ar-guide)
+
+## Issues
+
+- [Historical Events](https://github.com/w3c/wot-thing-description/issues/892)
+- [Historical Property Updates](https://github.com/w3c/wot-thing-description/issues/302#issuecomment-441235444)
+
+## Other Discussions
+
+These can be artifacts like presentations, meeting minutes.
+
+## Identified Requirements
+
+From the use cases, requirements should be identified.
+
+## Feature Proposals
+
+Ideally, the feature can exist only after the requirements are identified. However, if there are proposals already, they can be put here to drive discussions.
+
+## Existing Solutions
+
+- [Timeseries Data Submodel Specification at IDTA](https://industrialdigitaltwin.org/wp-content/uploads/2023/03/IDTA-02008-1-1_Submodel_TimeSeriesData.pdf)
+  - Timepoint (A UTC time) and Duration (time after the start and last measurement) are possible. In Duration, start time is necessary
+  - TAI and UTC are basic formats. Unix Time, Ephemeris Time (ET) or Barycentric Dynamical Time (TBD) are possible
+  - Sampling Interval or Rate can be provided as metadata
+  - Start and End Time can be provided since it also takes past values into account. Accordingly, you can also provide whether it is an ongoing timeseries or a completed one. (Ege: This is probably not relevant for us)
+  - Last Update can be provided. This is probably a data and not metadata for WoT. We can give guidelines/defaults on this. Normally, it should be equal to the timestamp of the last value.
+  - Each data blob is called a record.
+  - First the metadata is defined and then each data point needs to respect to that. Basically, it is like providing a data schema and then the values.
+- [InfluxDB Timeseries Data oriented Database](https://www.influxdata.com/)
+- [WebThings.io REST API](https://webthings.io/api/#event-resource)
+- ECHONET Lite Web API has an extension of the current TD specification on this direction
+  - WebAPI Specs: https://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/web_api/ECHONET_Lite_Web_API_Specs_v1.1.4_e.pdf
+  - WebAPI Device Specification: https://echonet.jp/wp/wp-content/uploads/pdf/General/Standard/web_api/ECHONET_Lite_Web_API_Dev_Specs_v1.4.1_e.pdf
+
+## Reading Resources
+
+- Overview on Wikipedia: https://en.wikipedia.org/wiki/Time_series

planning/work-items/binding-templates.md

@@ -0,0 +1,51 @@
+# TD.Next Binding Templates Work Items
+
+![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/Binding)
+
+## Binding Submission Mechanism
+
+We need to specify how a new binding should be submitted. E.g. Registry or a similar approach.
+Registry analysis is happening at a separate document. See [Registry Analysis](../../../registry-analysis/).
+
+Our approach should clarify the following points:
+
+- Rule-based validation process of the binding document submission (what checks should a submission pass)
+- Review process (do we organize special meetings, invite submitters to explain, how do we document it all etc.)
+- To be continued
+
+## Binding Mechanism
+
+![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/Binding)
+
+### Binding Templates Integration
+
+![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/Binding) ![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/document%20reorganization)
+
+Binding Templates core mechanism will be incorporated into the TD document.
+
+### Payload Driven Protocols
+
+![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/data%20mapping)
+
+Some protocols are built on top of the application layer protocols. Some examples are:
+
+- RPC protocols on top of HTTP such as JSON-RPC.
+- Protocols using MQTT topics together with payloads to identify affordances.
+- Websocket sub-protocols.
+- SSE usage across implementations.
+- Webhook usage across implementations.
+
+The Thing Description should be updated with mechanisms that make it possible to describe such protocols while optimizing the TD instances to be human and machine readable.
+The Binding Templates should be updated with concrete cases where this mechanism is already used.
+The Profiles can use this mechanism to reduce the size of TDs while making them easier to understand.
+The working group will also document in which cases this method does not work due to making the TDs too complicated to understand, thus requiring a binding document.
+
+Note: This is dependent on _Reusable TD Elements_ of [Usability and Design](./usability-and-design.md) work item list.
+
+### External Security Ontologies
+
+![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/Binding) ![GitHub labels](https://img.shields.io/github/labels/w3c/wot-thing-description/Security)
+
+Currently security schemes are "baked into" the TD specification but it would be more manageable and consistent to break them out as separate ontologies so that all security schemes would be done via extensions. For protocol-specific security schemes in particular, these should be moved to the Protocol Bindings and ontologies supporting them. The TD 2.0 spec would be updated to only include general-purpose "structural" security schemes and "generic" schemes that apply to all protocols.
+
+See https://github.com/w3c/wot-charter-drafts/issues/57 , https://github.com/w3c/wot-thing-description/issues/1880