超级会员免费看
信息交互与音乐共享中的语义互操作性解析
1. 信息查询与交互基础
在信息查询过程中，查询会在特定上下文 (Kc ⊆ Dc) 中进行，该上下文由用于区分 (Gc) 的其他数据元素（反例）组成，并且反例与示例不能重叠，即 (Gc ∩ Kc = ∅)。例如，用户可以选择一些标签（如 “jazz”、“female - voice”、“piano”），基于标签系统得到一组可能的数据元素。若这是用户的首次交互，这些数据元素会与信息系统中的其他所有音乐文件进行对比。信息代理需要找出最佳分类器，以区分数据元素与上下文，然后向其他对等方查询最匹配的数据。代理之间不直接交换音乐文件或分类器，而是逐步协商标签。
2. 交互情况分类
可能出现以下五种交互情况：
-
成功交互
：
- 调用方所有者选择 (Gc ⊂ Dc) 并以 (Kc) 为上下文。
- 调用方信息代理将 (Gc)、(Kc) 分类为 (catc)。
- 调用方信息代理将 (catc) 编码为标签 (l) 并发送给被调用方。
- 被调用方信息代理将 (l) 解码为 (cats)。
- 被调用方信息代理使用 (cats) 过滤其数据集 (Ds)，得到结果 (R) 并返回给调用方。
- 调用方所有者从 (R) 中选择相关数据 (F)。
- 调用方将 (F) 插入 (Dc) 并更新 (Wc)，同时向被调用方发送成功信号。
- 被调用方更新 (Ws)。
成功交互时，调用方和被调用方会更新标签到类别的映射，增强使用的标签与分类器之间的关系（增加 (\Delta inc)），并削弱竞争关系。具体更新函数如下：
UpdateCaller(Wc,t, l, catc) 定义为：
Wc,t+1 = {ri|ri = (ci, li, γi) ∈ Wc,t with ci ≠ catc and li ≠ l}
∪
{(catc, l, γi + ∆inc) for wc = (catc, l, γi) ∈ Wc,t}
∪
{rj|rj = (catc, lj, γi + ∆n−inh) with lj ≠ l}
∪
{rj|rj = (catj, l, γi + ∆o−inh) with catj ≠ catc}
UpdateCallee(Ws,t, l, cats) 定义为：
Ws,t+1 = {ri|ri = (ci, li, γi) ∈ Ws,t with ci ≠ cats and li ≠ l}
∪
{(cats, l, γi + ∆inc) for ws = (cats, l, γi) ∈ Ws,t}
∪
{rj|rj = (cats, lj, γi + ∆n−inh) with lj ≠ l}
∪
{rj|rj = (catj, l, γi + ∆o−inh) with catj ≠ cats}
-
信息代理无法分类
：当调用方没有分类器来区分 (Gc) 和 (Kc) 时，调用方会执行以下操作：
- 构建新的分类器 (catn) 来区分 (Gc) 和 (Kc)。
- 发明新标签 (ln)（从足够大的字母表中随机抽取的字符串），并在 (W) 中添加 (ln) 和 (catn) 之间的新关系，初始强度为 (\gamma init)：(W’c = Wc ∪ {(ln, catn, γinit)})。之后交互继续，以 (ln) 作为新标签进行传输。
为避免随机字符串被其他代理用于其他分类器（同音异义问题），可使用通用唯一标识符（UUID）等技术来保证符号的唯一性。
-
被调用方不认识标签 ：若被调用方没有调用方发送的标签 (l)，被调用方会向调用方发送失败信号，然后接收 (Gc) 和 (Kc)，并执行以下操作：
- 被调用方信息代理将 (Gc) 与上下文 (Kc) 区分开来，分类为 (cats)。若失败，则创建新的分类器 (cats) 并添加到其分类库中。
- 被调用方信息代理在 (Ws) 中添加 (cats)、标签 (l) 和初始强度 (\gamma init) 的关系：(W’s = Ws ∪ {(l, cats, γinit)})。之后交互继续。
-
部分成功处理 ：当被调用方返回给调用方的结果部分不相关时，会计算一个分数（即所有者认为合适的元素百分比），低于阈值 (\theta fail) 则表示失败。可能的原因有两个：一是调用方使用的分类器不够精确，无法捕捉用户意图的区别；二是调用方和被调用方与传输标签关联的分类器不同。
区分这两种情况的方法是：调用方代理在所有者评估结果后，拥有两组正例（(Gc) 和 (F)）和两组反例（(Kc) 和 (B)），尝试找到比初始分类器更具判别力的分类器。若能找到，则认为代理误解了所有者的意图；若找不到，则表示通信失败，即被调用方对标签的解释与调用方不同。
-
调用方误解所有者请求 ：若调用方代理能找到新的分类器 (cat’c)，在新的正例集 (Gc ∪ F) 和反例集 (Kc ∪ B) 之间有更高的判别成功率，则使用 (cat’c) 代替 (catc) 继续交互。新分类器 (cat’c) 可以是现有分类器或新创建的分类器，将其编码为新标签 (l’) 后继续交互。
-
调用方和被调用方对标签解释不同 ：这种情况下，调用方和被调用方需要协调类别和标签。首先，双方会削弱在失败通信中使用的标签的关联强度：
- 调用方信息代理将 (Wc) 中 (catc) 和 (l) 之间的关联强度降低 (\Delta dec)。
- 被调用方信息代理将 (Ws) 中 (cats) 和 (l) 之间的关联强度降低 (\Delta dec)。
若调用方无法找到比第一次交易中使用的更好的分类器，调用方信息代理可以发送感兴趣对象的示例 (Gc ∪ F) 和上下文 (Kc ∪ B)，让被调用方尝试获取正确含义。
3. 重要参数
信息代理的自适应机制有以下主要参数：
| 参数 | 含义 | 值 |
| ---- | ---- | ---- |
| (\gamma init) | 新关系进入代理字典 (L) 的初始强度 | 0.5 |
| (\Delta inc) | 成功时使用的关系中 (\gamma) 的增加量 | 0.1 |
| (\Delta n−inh) | 成功时相同标签（不同类别）关系的减少量 | -0.2 |
| (\Delta o−inh) | 成功时相同分类器（不同标签）关系的减少量 | -0.1 |
| (\Delta dec) | 失败时使用的关系中 (\gamma) 的减少量 | -0.1 |
| (\theta disc) | 分类时使用的阈值 | 0.5 |
| (\theta fail) | 表示交换失败的阈值 | 0.5 |
这些参数的取值有一定灵活性，但 (\Delta inc > 0)，(\Delta n−inh < 0)，(\Delta o−inh < 0)，(\Delta dec < 0)。参数的重要性在模拟实验中得到体现，采用、强化、阻尼和侧向抑制等机制的组合有助于形成高效的字典。
4. 音乐共享示例
下面通过音乐共享的例子来说明上述交互过程。假设有三个用户及其各自的信息代理，每个对等方都有本地元数据，且所有歌曲都有唯一的标识号。
4.1 查询 1：Agent 0 向 Agent 1 请求更多 “Beatles” 歌曲
- 用户 0 选择 “beatles” 文件夹，要求 Agent 0 查找类似歌曲。Agent 0 因字典为空，无法找到分类器，于是创建新分类器 (Artist(The Beatles))，并发明新标签 “6365915a” 绑定到该分类器，初始强度为 0.5。
- Agent 0 使用 “6365915a” 向 Agent 1 查询，Agent 1 因字典为空无法解码该标签，返回失败信息。
- Agent 0 发送 “6365915a” 的正例和反例，Agent 1 创建新分类器 (Nom(Beatles, The)) 并与 “6365915a” 绑定。
- Agent 0 再次查询，Agent 1 成功解码并过滤数据集，返回歌曲列表。
- Agent 0 的所有者评估结果为全部有效，查询成功，双方更新字典，增强 “6365915a” 与各自分类器的关系。
交互流程如下：
- [0, Agent0]: search examples: [Across The Universe][I Feel Fine][Norwegian Wood][Helter Skelter][You Know My Name][Eleanor Rigby][Blackbird], counter-examples: [Let’s Spend the Night Together][Ruby Tuesday]
- [1, Agent0]: categorisation failed
- [2, Agent0]: creates Category<Artist(The Beatles)>
- [3, Agent0]: binds 6365915a to Category<Artist(The Beatles)>
- [4, Agent1]: query for 6365915a
- [5, Agent1]: fails to decode 6365915a
- [6, Agent0]: transmits examples and count-examples of 6365915a
- [7, Agent1]: categorisation failed
- [8, Agent1]: creates Category<Nom(Beatles, The)>
- [9, Agent1]: binds 6365915a to Category<Nom(Beatles, The)>
- [10, Agent1]: query for 6365915a
- [11, Agent1]: decodes 6365915a as Category<Nom(Beatles, The)>
- [12, Agent1]: filter data: results: [I’m Down][And I Love Her][Twist And Shout]
- [13, Agent0]: owner evaluation: good (3 out of 3): [Twist And Shout][I’m Down][And I Love Her]
- [14, Agent0]: search sucessful
- [15, Agent0]: update dictionary
- [16, Agent1]: update dictionary
4.2 查询 2：Agent 1 向 Agent 0 请求更多 “Sixties” 歌曲
- Agent 1 将示例和反例分类为 (Nom(Beatles, The))，使用现有标签 “6365915a” 查询 Agent 0。
- Agent 0 解码该标签为 (Artist(The Beatles))，返回所有 Beatles 歌曲。
- Agent 1 的所有者评估结果，只有 4 首歌曲被认为合适。Agent 1 认为自己误解了所有者请求，创建新分类器 (Année(from 1963 to 1966))，发明新标签 “5f6a1a0c” 绑定到该分类器。
- Agent 1 使用新标签查询，Agent 0 不认识该标签，接收示例和反例后，创建新分类器 (Genre(Rock ’n Roll)) 并与 “5f6a1a0c” 绑定，过滤数据集返回结果。
- Agent 1 的所有者评估结果为全部有效，查询成功，双方更新字典。
交互流程如下：
- [0, Agent1]: search examples: [Twist And Shout][Paint It Black][I’m Down][And I Love Her], counter-examples: [Billie Jean][Smoke on the Water][True Blue][Let’s Spend the Night Together]
- [1, Agent1]: uses Category<Nom(Beatles, The)>
- [2, Agent1]: codes Category<Nom(Beatles, The)> as 6365915a
- [3, Agent0]: query for 6365915a
- [4, Agent0]: decodes 6365915a as Category<Artist(The Beatles)>
- [5, Agent0]: filter data: results: [Blackbird][Eleanor Rigby][Norwegian Wood][Across The Universe][You Know My Name][And I Love Her][Helter Skelter][I Feel Fine][Twist And Shout][I’m Down]
- [6, Agent1]: owner evaluation: good (4 out of 10): [Twist And Shout][I Feel Fine][I’m Down][And I Love Her], bad (6 out of 10): [Across The Universe][Norwegian Wood][Helter Skelter][You Know My Name][Eleanor Rigby][Blackbird]
- [7, Agent1]: owner request misinterpreted, uses new Category<Annee(from 1963.0 to 1966.0)> instead.
- [8, Agent1]: binds 5f6a1a0c to Category<Annee(from 1963.0 to 1966.0)>
- [9, Agent1]: transmits examples and count-examples of 5f6a1a0c
- [10, Agent0]: categorisation failed
- [11, Agent0]: creates Category<Genre(Rock ’n Roll)>
- [12, Agent0]: binds 5f6a1a0c to Category<Genre(Rock ’n Roll)>
- [13, Agent0]: query for 5f6a1a0c
- [14, Agent0]: decodes 5f6a1a0c as Category<Genre(Rock ’n Roll)>
- [15, Agent0]: filter data: results: [And I Love Her][I Feel Fine][I’m Down][Twist And Shout]
- [16, Agent1]: owner evaluation: good (4 out of 4): [Twist And Shout][I Feel Fine][I’m Down][And I Love Her]
- [17, Agent1]: search sucessful
- [18, Agent1]: update dictionary
- [19, Agent0]: update dictionary
通过这些例子可以看出，即使不同代理有不同的元数据和数据库模式，通过标签协商和分类器的调整，仍然可以实现有效的信息交互和音乐共享。
下面是成功交互的 mermaid 流程图：
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
classDef io fill:#FFEBEB,stroke:#E68994,stroke-width:2px;
A([开始]):::startend --> B(调用方选择Gc和Kc):::process
B --> C(调用方分类Gc和Kc为catc):::process
C --> D(调用方编码catc为l):::process
D --> E(发送l):::io
E --> F(被调用方解码l为cats):::process
F --> G(被调用方过滤Ds得到R):::process
G --> H(返回R):::io
H --> I(调用方选择相关数据F):::process
I --> J(调用方插入F并更新Wc):::process
J --> K(发送成功信号):::io
K --> L(被调用方更新Ws):::process
L --> M([结束]):::startend
以上内容详细介绍了信息交互过程中的各种情况以及在音乐共享场景中的应用，展示了如何通过标签协商和分类器调整实现语义互操作性。
5. 交互情况分析总结
为了更清晰地对比不同交互情况，我们可以列出如下表格：
| 交互情况 | 主要问题 | 解决方案 |
| ---- | ---- | ---- |
| 成功交互 | 无 | 双方更新标签与分类器映射，增强使用关系，削弱竞争关系 |
| 信息代理无法分类 | 调用方无分类器区分 (Gc) 和 (Kc) | 构建新分类器 (catn)，发明新标签 (ln) 并建立关系 |
| 被调用方不认识标签 | 被调用方没有调用方发送的标签 (l) | 被调用方接收 (Gc) 和 (Kc)，分类并建立新关系 |
| 部分成功处理 | 结果部分不相关 | 计算分数，判断原因，尝试找更优分类器 |
| 调用方误解所有者请求 | 调用方分类器不匹配用户意图 | 找到新分类器 (cat’c)，编码为新标签 (l’) 继续交互 |
| 调用方和被调用方对标签解释不同 | 双方对标签关联的分类器不同 | 削弱失败通信中标签关联强度，必要时发送示例和上下文 |
通过这个表格，我们可以更直观地看到不同交互情况的特点和应对方法，有助于在实际应用中快速判断并采取相应措施。
6. 参数对交互的影响
参数在信息代理的自适应机制中起着关键作用。我们可以用一个 mermaid 流程图来展示参数对交互的影响：
graph LR
classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;
classDef decision fill:#FFF6CC,stroke:#FFBC52,stroke-width:2px;
classDef io fill:#FFEBEB,stroke:#E68994,stroke-width:2px;
A([开始]):::startend --> B{交互成功?}:::decision
B -- 是 --> C(增加关系强度 \(\Delta inc\)):::process
C --> D(减少相同标签不同类别关系 \(\Delta n - inh\)):::process
D --> E(减少相同分类器不同标签关系 \(\Delta o - inh\)):::process
B -- 否 --> F(减少关系强度 \(\Delta dec\)):::process
E --> G([结束]):::startend
F --> G
从这个流程图可以看出，不同的交互结果会根据参数进行不同的调整。例如，在成功交互时，(\Delta inc) 会增强使用的标签与分类器之间的关系，而 (\Delta n - inh) 和 (\Delta o - inh) 会削弱竞争关系，使得标签与分类器的映射更加准确。在交互失败时，(\Delta dec) 会降低失败关系的强度，减少后续使用该关系的可能性。
7. 音乐共享交互的深入理解
在音乐共享的两个查询示例中，我们可以进一步分析其交互的本质。
对于查询 1，Agent 0 和 Agent 1 从无到有地建立了标签和分类器的关系，这是一个典型的启动过程。在这个过程中，双方通过不断地交互和学习，逐渐明确了标签 “6365915a” 的含义，使得后续的查询能够顺利进行。可以用以下列表来概括这个过程：
1. Agent 0 遇到问题，创建新分类器和标签。
2. Agent 1 不认识标签，接收示例后学习并建立关系。
3. 再次查询时，双方达成一致，交互成功。
对于查询 2，Agent 1 最初的分类器选择不当，导致查询结果部分失败。但通过对结果的分析，Agent 1 能够及时纠正错误，创建新的分类器和标签。这个过程体现了信息代理的自适应能力，具体步骤如下：
1. Agent 1 错误分类，使用旧标签查询失败。
2. 分析结果，发现误解，创建新分类器和标签。
3. Agent 0 学习新标签和分类器，再次查询成功。
8. 实际应用中的注意事项
在实际应用中，为了更好地实现语义互操作性，需要注意以下几点：
-
标签唯一性
：使用 UUID 等技术确保标签的唯一性，避免同音异义问题，减少交互中的错误。
-
参数调整
：根据实际情况调整参数，如 (\gamma init)、(\Delta inc) 等，以达到最佳的交互效果。不同的应用场景可能需要不同的参数设置。
-
分类器优化
：不断优化分类器，提高其判别能力，以更好地满足用户的需求。可以通过收集更多的示例和反例来训练分类器。
9. 总结
信息交互和音乐共享中的语义互操作性是一个复杂但重要的问题。通过在特定上下文中进行查询，使用标签协商和分类器调整的方法，不同的信息代理可以实现有效的信息交换，即使它们有不同的元数据和数据库模式。
在交互过程中，会出现各种情况，如成功交互、部分成功、失败等，但通过相应的处理机制，如更新映射关系、创建新分类器和标签等，能够逐步解决问题，实现语义的一致性。
音乐共享的示例展示了整个交互过程的实际应用，从最初的启动到后续的调整和优化，都体现了信息代理的自适应能力。同时，合理设置参数和注意标签唯一性等问题，能够进一步提高交互的效率和准确性。
总之，语义互操作性为信息交互和共享提供了一种有效的解决方案，在未来的信息系统中具有广阔的应用前景。
扫一扫
4003
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
