如何解决基于标记的网站的语义问题

Question

基于标记的网站经常会受到同义词，同音异义词等语言的影响。对于寻找信息的程序员，比如Stack Overflow，具体的例子是：

• Subversion或SVN（或带有区分大小写标签的svn）
• .NET或Mono
• [会添加更多]

问题在于我们做想要保留我们精美的语言并使机器尽可能好地处理它。

像del.icio.us这样的网站看到它的标记库增长很多，因此可能会阻碍使用或搜索。搜索与SVN相关的条目可能会列出大多数带有subversion和svn标签的条目，但我可以想到三个问题：

1. 搜索不完整，因为许多条目可能没有两个标记（都是“同义词”）。
2. 搜索不太有用，因为Q / A通常会导致更多的Q！特别是针对特定主题的新手。
3. 标记一个问题（注意：或单独回答，听起来很有用）变得具有哲学性：'我是否标记了正确的方法？'

解决这些问题的一种方法是在标签之间创建语义链接，这样subversion和SVN就会被系统自动绑定，而不是由不良用户绑定。

这种方法听起来不错/可行/有吸引力/有用吗？如何有效地实施它？

Answer 1

识别同义词和语义连接是人类擅长的;通过寻找将匹配留给人类的方法，可以很好地解决组织开放式分类法的解决方案，例如SO的特色。

一种通用方法：某人（或某个团队）每天审核新标签。新同义词被添加到同义词组。搜索命中同义词组（或者，更细微的，根据用户偏好命中文字匹配或同义词组匹配）。

这需要支持后端的同义词组（适用于开发团队）。它需要一个标签管理器或十个（为主体或可信用户工作）。然而，不需要不断缩放 - 总标签池可能增长的速率（在初始版本来自公开测试的每个人碰撞之后）很可能减少< / i>随着时间的推移，任何有机词典的增长率都会如此。

Synonymy对我来说是个问题。分层映射是一个雄心勃勃且更复杂的问题;它可能是值得的，也可能不是，但考虑到定义层次结构的相对复杂性，它可能最好留作任何潜在同义词项目第1阶段的第2阶段。

Answer 2

blogspot.com上的软件设置方式是，在框中有一个ajax-autocomplete-thingie，您可以在其中写下标签的名称。这将搜索您之前的所有帖子，查找以相同字母开头的标签。至少你可以通过这种方式捕获不同的外壳和拼写（但不是同义词）。

Answer 3

我完全同意。目前有大量标签。我不参与其他基于标记的网站。但是，拥有标记层次结构将非常有用，而不是ruby rails ruby-on-rails rubyonrails等...

Answer 4

系统如何知道语义链接的标签？它会保留一个不断增长的标签图吗？我看不出那种工作方式。如果有人输入sbversion怎么办？怎么会被联系起来？

我认为询问用户提交标签的时间是可行的。例如，“你输入了以下标签：sbversion，pascal和bindings。你的意思是，”Subversion“，”Pascal“和”Bindings“？

显然，系统必须有一个相当智能的匹配系统才能工作。这样做会为用户提供额外的输入（这可能会让他们烦恼）但如果做得正确，人工输入会减少重复标记。

事实上，尽管如此，系统可以使用用户输入的结果作为自动标签匹配的基础。在前面的例子中，有人创建了一个“sbversion”标签，当提示将其更改为“Subversion”时 - 系统可以学习并在下次自动完成。

Answer 5

您正在研究的部分问题是英语中充满了同义词 - 以下是不同的：构建管理，颠覆，简历，源代码控制？

也许，也许不是。拥有一个系统，就像在SO上使用的那个系统一样，它可以带来你可能意味着的标签非常有帮助。但它并没有阻止人们对标记过程进行欺凌。

也许你可以在没有用户互动的情况下拒绝接受“新”标签？在让'sbversion'进去之前，强制进行拼写检查？

这绝对是一个有趣的问题。去年我在blog问了一个与此类似的公开问题。其中一些回复非常有见地。

Answer 6

标签基本上是我们承认搜索算法不符合要求。如果我们可以让计算机足够聪明，以确定标记为“Subversion”的内容与标记为“svn”的内容具有相似的内容，可能我们可以解析内容，那么为什么不完全跳过标记，并将搜索词直接匹配到内容（即自动标记，基本上是将关键字映射到结果）？！

Answer 7

问题是让搜索引擎使用“颠覆”和“svn”非常相似的事实，以至于它们意味着相同的“事物”。

根据频率计算标签之间的简单相似性可能很有吸引力：'subversion'和'svn'经常出现在一起，所以请求'svn'会返回与SVN相关的问题，但也只是标记'的罕见问题'颠覆'（反之亦然）。但是，'java'和'c＃'也经常出现在一起，但原因各不相同（它们不是同义词）。因此基于频率的相似性已经消失。

这个问题的答案可能是各种机制的混合，正如本Q / A线程中建议的那样：

• 在用户输入标签时通过建议标记来过滤拼写错误。
• 维护用户生成的同义词映射。如果它只是针对同义词，那么这张地图可能不会那么大。
• 允许多标签搜索，以便用户可以放置'subversion svn'或'subversion＆amp;＆amp; svn'（好吧，从程序员到程序员）在搜索框中获取两者。这是非常实用的，因为许多用户在不知道哪个术语最有意义时可能会尝试这种方法。

@Nick：同意。这个问题并不是要反对标签。标签具有巨大的潜力，但如果无法搜索“跨越”标签，用户将面临越来越多的问题。

@Steve：维护一个不断增长的地图标签绝对不实用。由于SO正在积累不断增长的 bag 标签，我们怎样才能在这个包上遮挡一些灯，以便以方便的方式搜索Q / A标签更有用？

@Espo：在创建问题时，基于现有标签的'Ajax驱动'标签建议显然可在SO上使用。这对于选择标签和适当的拼写非常有帮助（避免史蒂夫的'颠覆'与'sbversion'问题）。