目标

分类框架的主要目标是将分类与对象的创建和管理解耦，提供一个对人类友好、视觉上可识别、灵活的替代搜索索引的对象的方法。从几乎任何操作系统都使用的目录架构开始，分类方法已经使用了很长时间，遵循将分类与对象的创建、管理、存储和识别解耦的原则。

分类法分类，以及其目前流行的变体 - 标签，被广泛应用于许多Web框架和桌面系统中。Gmail 以复制文件夹结构的方式开始了这一点，提出了将对象虚拟放入多个桶中的概念，也许这是遵循了几十年存在于文件系统中的软链接。

当Web服务如Gmail和Flickr为了非常特定的对象分类目的采用分类法分类时，这种分类法得到了新的面貌。例如，我们可以选择应用这种分类法或者不使用它。后来，类似的分类概念被采用到如iTunes、Microsoft Vista OS 中的 Explorer 等桌面应用程序和Web框架中。

除了分类框架的主要目标是将分类逻辑从内容管理中解耦外，我们还将关注Web框架中的以下不可或缺的实体 - 可扩展性、可靠性、可扩展性和可用性。这还必须考虑操作频率，以确定关键因素。实现的具体细节在设计考虑中讨论。

数据库被规范化到3NF以确保可扩展性同时保持可伸缩性。经常使用的查询如关系、对象映射和叶成员资格被设计为可伸缩的。通过在不同状态的对象上设置钩子以及可能通过计划任务来实现可靠性。

词汇表

• 叶：分类标签的基本单位，将与项目关联以对它们进行分类。这里术语和标签可以互换使用。叶可能有许多类似的名称，我们称它们为别名。
• 别名：例如，"大学"和"学院"可能指的是相同的事物，对于单一术语使用两个不同的标签是冗余且容易引起误解的。因此，可以将"大学"设置为"学院"的别名，这样只有一个术语 - "大学"，每当用户指定术语"学院"时，它将被解释为"大学"。
• 树：这是一个作用于叶子的伞形单位，作为桶来定义下面叶子的属性、规则和交互。它将具有以下属性
  • 层次结构：涉及的层次结构类型（参考下面的结构）
  • 受控：是否可以在管理员表单之外创建叶子（com_taxonomy）
  • 关系：允许哪种类型的关系：仅允许父子关系，还是也允许同级对同级的关系。
• 树映射：除非将树映射到对象管理器（如组件）上，否则树是无用的。一个特定的映射涉及一个树和一个扩展。进一步定义以下规则
  • 必需：每个对象是否必须与这个树下的这个关联中的叶子相关联
  • 多个：是否可以将多个叶子与单个对象关联
  • 权重：当扩展调用所有关联的树或对象下的所有关联术语时，决定树优先级的因素。权重越大，位置越低。
• 叶子映射：在树映射规则和树的属性的指导下，叶子与树映射中给出的扩展下的对象相关联。这也被称为标记或标签。

结构

尽管统一树吸收域名结构将是足够的，但我们考虑到树的森林，原因在后续的设计考虑中解释。顶级成员将是一个树，其属性定义了树的使用和结构。叶子是特定树的成员，尽管出于设计考虑中的许多原因，叶子将仅限于一个树，但可以被多个扩展使用，仍然遵循定义一次，到处使用的原则。

在分类法框架下可以构建多种结构。然而，有三种基本结构，可以在其上构建复杂设计，我们称之为层次结构。

层次结构

1. 扁平层次结构

这也被称为扁平结构、标记、浮动术语等。用这种结构构建的树将为终端用户提供一个相当直接的简单分类法系统。

2. 单一层次结构

这通常被理解为分类树，其中叶子要么是根叶子，要么是另一个叶子的子叶子。因此，只能有一个父级，但可以有多个子级，呈现出自上而下的层次结构。

3. 多重层次结构

灵活性的需求可能带来一些很少使用的功能。多重层次结构就是这样一种功能，尽管如此，对于完整性来说仍然是必不可少的。它允许多个父级，因此可以实现向上和向下的分支。

构建结构

将结构的逻辑与构建块分开的意图是为了保持最大的灵活性，即能够实际上达到构建分类系统中的任何级别的复杂性，同时确保可用性，使不会用户引导入歧途。在这个设计中，结构将无缝地构建在上述块上。

流行的结构

（参考上面的词汇，了解下面特定词的隐含意义）

1. 自由标记 - 类似于Wordpress、Gmail或Flickr中的标记功能。这是扁平层次结构，多个、不受控的树，并且可能不是必需的。
2. 分类 - 与Joomla!或WordPress中使用的分类类似。具有单一层次结构 的层次树。通常是受控的，可能是必需的且唯一。这意味着用户必须选择一个，且每个对象只有一个叶子。
3. 用户组 - 与Drupal中使用的有机组类似。具有单一层次的层次树，受控，唯一且必需。
4. 书籍 - 具有单一层次的层次树，不受控，必需且唯一。
5. 频道 - 多个层次，不受控，多个且可能必需。

上述示例强调了创建树和映射扩展之间所需的协调。尽管用户或扩展可以通过直接在表中输入或使用后端表单并构建模型来完成此操作，但确实需要进行深思熟虑的规划。在前端表单中（参见图谱分类器com_taxonomy）将简化此操作，用户只需选择一个结构，其属性将自动定义。

数据库结构

设计时考虑了处理大量记录的能力和可扩展性，因此模式被规范化为3NF。以下表格构建了分类框架

• tree：它构建了存储构建完整树所需完整信息的树丛。所有属性都可以通过管理组件进行编辑，但是将提供快速构建以用于常见类型的树（参见图谱分类器com_taxonomy的前端）。
• tree_map：它存储树与其他扩展之间的对应关系，例如内容组件。树可以完全链接到一个或多个扩展。这种规范化可以使得单个树在多个应用程序中重用。权重决定了特定链接相对于类似链接的优先级。
• leaf：包含关于术语的原子信息，它所属的树等。还添加了权重以确保，当多个叶子为特定请求排列时，偏好顺序。
• leaf_map：用于将术语与项目匹配，例如内容帖子
• leaf_hierarchy：它包含两个叶子之间的关系。目前支持的关系类型是父级和同级，分别转换为组成层次树的父子关系和组成簇树的点对点关系。
• leaf_alias：它包含叶子的别名列表。当分类框架用于与人类直接交互的组件时，记住正确术语的责任无法强制执行，此时处理别名的能力至关重要。例如，单词“大学”，“大学们”等都可以指代相同的术语 - 学院。

设计考虑

层次结构/自由术语

有两种流行的分类结构。层次树（通常是单一层次）和自由标记（扁平层次）。尽管这对于内容管理任务来说绰绰有余，但对于具有自由标记的专辑、用户组、用户角色（用于权限授予目的）等复杂层次结构，将需要各种功能。这是通过将结构与其构建块 - 层次结构、扩展映射（和属性）和树属性隔离开来实现的。

集中式/分布式

有时需要关注90%常用的功能，而牺牲完全的灵活性以提升性能。

在设计中没有必要使用树，如域名层次结构中实现的，所有内容都从第0级开始 - 根域 - 点，并通过第一级和第二级域扩展，所有这些都是平等的表示。同样，只有叶子可以形成分类框架，并具有将扩展映射到特定叶子的能力，这将决定所有子项的属性。

然而，无论选择何种方式实现多棵树，这种做法牺牲了灵活性，换取了性能的提升，更重要的是支持多级层次结构，或者更准确地说，支持多个父节点。它允许在广度和深度上都有更大的扩展性。

在这里定义，到处使用

遵循流行的“一次编写，多次使用”范式，分类框架预计将成为所有分类需求的统一解决方案。因此，它必须能够与任何实现无缝链接。这是通过将一棵树映射到特定的扩展来实现的，从而使所有下级术语都可以供扩展使用。