Ordering attributes for data capture

[pknowl]

The original attribute ordering overlay RFC was closed as the tech team had placed this functionality as a presentation requirement. However, the absence of attribute ordering has emerged as a critical impediment. Currently, OCA interface functionality is significantly compromised without this capability at a capture level, rendering it ineffective for practical use. It's imperative that attribute ordering is not only implemented but also formally integrated into the specification as a critical feature.

The value of attribute ordering extends beyond simple aesthetic or superficial presentation aspects. It plays a fundamental role in enhancing data usability, integrity, and semantic clarity. Properly implemented, an ordering overlay can:

Improve Data Interpretation: By logically organizing data attributes, we facilitate a more intuitive understanding, making it easier for users and systems to accurately comprehend and work with the data.

Enhance Data Quality: Structured attribute ordering supports consistent data entry and processing, reducing errors and ensuring data meets our quality standards.

Ensure Semantic Consistency: Logical sequencing of attributes helps maintain the semantic context of data, preventing misunderstandings arising from out-of-context or poorly sequenced data elements.

Support Advanced Data Processes: Beyond immediate comprehension, a well-considered order of attributes is crucial for efficient data analysis, reporting, and decision-making processes, where the sequence of information can influence outcomes and insights.

In light of these considerations, integrating an ordering overlay into the OCA stack is deemed essential by the Decentralized Semantics WG for realizing the full potential of the architecture. It's about laying the foundation for a more intelligent, user-friendly, and semantically rich data environment.

Additional note from Ryan: The entire point is that we iterate and try things, if we want to do better later then we do that then and deprecate.

[carlyh-micb]

Sam Smith also notes the importance of attribute ordering.

from: IETF draft "In contrast, from a functional perspective, lexicographic ordering appears un-natural. In lexicographic ordering the fields are sorted by label prior to serialization. The problem with lexicographic ordering is that the relative order of appearance of the fields is determined by the labels themselves not some logical or functional purpose of the fields themselves. This often results in oddly- labeled fields that are so named merely to ensure that the lexicographic ordering matches a given logical ordering."

[stevenmilstein]

Let the market decide.

Please take a look at the car accessory aftermarket as an example. Companies develop original car accessories, like the third brake light, which car manufacturers may not have thought of. At some point, the car manufacturers see enough market demand and decide to produce it themselves.

Another example is OpenAI, which introduced plug-ins. Once it saw success, it shut down for "Customs."

[blelump]

Additional note from Ryan: The entire point is that we iterate and try things, if we want to do better later then we do that then and deprecate.

Deprecation is a last resort rather than a built-in ecosystem feature. It isn't a free lunch. It tremendously impacts the whole ecosystem and costs time and money, especially at scale. While evolution or iteration towards a balance of features and their consumability also requires time and money, the inputs, so what's known in the beginning, play a crucial role in the direction of further evolution. Evolution is a natural process to move forward, yet requires wise decisions. We do not need to Monte Carlo method to see what works.