在SE11或 ADT 里创建一个 Data Element 时，很容易把注意力全部放在数据类型、长度、Domain 上。一个字段是CHAR 10、NUMC 4还是DEC 15,2，看起来像是 Data Element 最核心的部分。可真正进入一个成熟的 SAP 系统之后，会发现 Data Element 承担的职责远不止定义字段能存什么数据。
同样是一个CHAR 10，它可能表示销售组织、物料编号、员工编号，也可能表示一个完全不同的业务概念。从数据库的视角观察，这几个字段可能没有任何区别。但从 SAP 应用的视角观察，它们的字段标题、F1 帮助、F4 Search Help、默认字段名、SPA/GPA Parameter、Change Document 行为，甚至阿拉伯语和希伯来语环境中的书写方向，都可能完全不同。
这正是 DDIC Data Element 的 Semantic Properties 存在的原因。
SAP 当前的 ABAP Keyword Documentation 将 Data Element 描述为一种可以带有语义属性的全局类型，其中包括文档、UI 文本以及 Search Help。Domain 则更多承担底层技术属性和值域语义。一个 Domain 可以被多个 Data Element 复用，而一个 Data Element 会在这个技术基础上进一步表达字段在业务中的含义。
这里有一个很重要的边界需要先建立起来。
Data Element 的大部分 Semantic Properties 主要在字段被 UI 消费时发挥作用，而不
