@ExplodingCabbage 和 @fcbond 可能知道。

@ExplodingCabbage
问题284和541在NLTK网站的这个标题下列出。以下是引用以方便参考。
Bug 541似乎是关于添加领域的问题。我可以看到第一个例子，因为代码有几种不同的含义，但我不确定第二个和第三个例子中什么是有效的新领域。
Bug 284可能更严重，根据描述：它说同义词没有被考虑在内来计算相似度分数，而且似乎确实发生了这种情况：

>>> wn.synset('john.n.02').wup_similarity(wn.synset('dog.n.01'))
0.5714285714285714
>>> wn.synset('john.n.02').wup_similarity(wn.synset('man.n.01'))
0.5714285714285714

Bug 284

# instance hypernyms not used in similarity calculations

>>> wn.synset('john.n.02').lch_similarity(wn.synset('dog.n.01'))
1.335...
>>> wn.synset('john.n.02').wup_similarity(wn.synset('dog.n.01'))
0.571...
>>> wn.synset('john.n.02').res_similarity(wn.synset('dog.n.01'), brown_ic)
2.224...
>>> wn.synset('john.n.02').jcn_similarity(wn.synset('dog.n.01'), brown_ic)
0.075...
>>> wn.synset('john.n.02').lin_similarity(wn.synset('dog.n.01'), brown_ic)
0.252...
>>> wn.synset('john.n.02').hypernym_paths()
[[Synset('entity.n.01'), ..., Synset('john.n.02')]]

Bug 541

# add domains to wordnet

>>> wn.synset('code.n.03').topic_domains()
[Synset('computer_science.n.01')]
>>> wn.synset('pukka.a.01').region_domains()
[Synset('india.n.01')]
>>> wn.synset('freaky.a.01').usage_domains()
[Synset('slang.n.02')]

首先，我们需要检查是否解决了bug。对吧？

首先，我们需要检查这些bug是否已经解决。对吗？

👍同意！

现在我不确定第一个bug是否已经修复，我不知道那里使用的所有示例的正确相似度分数是多少。wn.synset('john.n.02').wup_similarity(wn.synset('dog.n.01')) 的相似度与今天相同(刚刚运行了示例),所以它要么是正确的，要么没有修复。对于任何父树来说，man 似乎都被正确地计算为最短距离(man 和 dog 在其中一个树中共享大多数父节点，而 0.57... 似乎是一个相对合理的分数)。因此，也许这个bug指的是其他方法，也许是使用 brown_ic 对象的那些方法？

根据我的当前理解，第二个bug与其说是一个bug,不如说是一个可以改进的地方(增加域的覆盖率)。对于2/3和3/3的情况，调用 topic_domains() 的输出似乎很好，但对于1/3的情况，它是正确的但不完整的。

有人知道包含允许选项的参考域集吗？如果需要，它可以扩展吗？

扩展域的一个简单方法可以是：

1. 使用已经分配的域训练分类器(例如，在所有形式的'code.n.03'及其同义词以及任何其他用相同域标记的概念上训练一个domain:computer_science` 二元分类器；
2. 在大型语料库上运行分类器；
3. 对于正面预测，搜索文档中的任何其他同义词集的出现，并用域标签它们；
4. 对于每个域重复此过程。

这似乎是可行的，但可能需要一段时间，并且需要进行一些严肃的修订。

首先，我们需要检查这些bug是否已经解决。对吧？
当然要检查，但鉴于我们引用的这些来自回归测试部分，我假设它们已经解决了；这些测试是为了证明修复工作有效并防止回归。

如果bug可以认为已经修复，那么关闭这个问题似乎就安全了。毕竟这是2017年4月的问题。

我没有打开这个问题，因为我担心这些bug可能没有被修复，而是因为这些bug编号实际上是无法跟踪的断开链接 - 无法跟进的问题引用。如果有人熟悉NLTK托管的历史，能指出旧的问题追踪器在哪里就好了；然后我们可以用类似的方式用互联网档案馆的链接替换这些bug编号，就像最近的回归测试用完整的GitHub问题URL来识别它们对应的bug一样。

正确的解决方案是将代码中的对问题的引用移除，对吗？在代码内部的注解中引用问题的做法已经被证明是脆弱的。