你好，马克，>注意，我指的是注释以外的用例>文档检索，我同意您应该用>概念，而不是术语。你能详细描述一下这些用例吗？在每一个用例中，解释一下你想要断言什么，这些断言意味着什么，以及这些断言中所涉及的资源的性质是什么。>这些只是在>参数“我们需要一个Term类来附加属性”这些属性是什么？请列出并解释使用它们所作断言的含义。飞行。。。“术语”是最可怕的词。它对一百万不同的人来说意味着一百万种不同的事情。来自受控词汇表的“术语”和来自术语表的“词汇”是完全不同的东西。在元数据应用程序中，“术语”可以是事物的属性，也可以是这些属性的值，或者是事物的类，或者是无意义的字符串，或者是上述所有内容——请参阅“都柏林核心元数据术语”[3]。SKOS核心词汇规范[4]使用“术语”来指代SKOS核心词汇量本身的类和属性，这种用法与都柏林核心和其他RDF文档一致。由于在重叠的话语领域中这种令人难以置信的超载用法，SKOS核心指南[5]几乎没有在散文中出现字符串“term”。这是非常刻意的。（我刚发现一对情侣溜走了，doh。）都柏林核心区的人们学到的教训是：要准确。都柏林核心元素集的几个属性的含义现在在实践中已经超载，以至于实际上变得毫无意义。这对于DCMI体系结构和使用团队来说是一个巨大的问题。如果我们为SKOS Core创建一个类“Term”，我很确定，在实际使用中会发现令人难以置信的变化，这将使它以及SKOS Core的所有相关部分实际上毫无意义。我们会给已经非常混乱的话语领域带来混乱。一句话：如果你能定义一类不被称为“术语”的资源，其含义明确且易于定义，其应用程序简单明了，其支持用例可以通过大量实践证明是合理的，那么很好，让我们来谈谈它。如果你不能，请跳出框框思考。想想n元关系。如果你发现很难定义你想要关联的事物的性质（即类型），那么你可能是在合并资源。也许你所理解的“同义词库术语”实际上是几个事物之间n元关系的一个实例。如果你不喜欢n元关系，那么在你使用术语的所有不同上下文中，努力区分术语的含义，然后从那里开始定义类。我敢打赌你最后会上大约12节课，几乎所有的课都是不相交的。干杯，铝。[1]http://lists.w3.org/Archives/Public/Public-esw-thes/2005年10月/0114.html[2]http://lists.w3.org/Archives/Public/Public-esw-thes/2005年10月/0085.html[3]http://dublincore.org/documents/dcmi-terms/[4]http://www.w3.org/TR/2005/WD-swbp-skos-core-spec-20050510/[5]http://www.w3.org/TR/2005/WD-swbp-skos-core-guide-20050510/>-----原始消息----->发件人：Mark van Assem[mailto:mark@cs.vu.nl]>发送时间：2005年10月26日12:01>收件人：迈尔斯，AJ（Alistair）>抄送：public-esw-thes@w3.org>主题：回复：内容注释vs条款注释> > >你好，Alistair，> >我不知道怎么说才不会听起来像个屁眼> ... 但我很肯定你的建议>与叙词表构建的基本原则相矛盾>正如我从ISO 2788中学到的那样，使用新的BS 8723，>直接来自Stella和Leonard这样的人。> >也许你是对的，但我认为一些同义词库>民间是>出于附加原因，支持学期课程>属性。结果是，您可以拥有的URI>他们，以及>按照我建议的方式使用这些术语。我想如果人们发现>那些有用的，他们会的，无论任何标准是什么。而且>我认为他们这样做不会错。> > > ... 然后是同义词表T术语<摇滚>和同义词库T术语>＜玄武岩＞在语义上是等价的标记。> >是的，在同义词库中，它们就像（我认为）WN中的>WordSense在一个Synset中是等效的。但对于一些实际的>使用（您同意为WordSense存在的）它们不是。> >>因此，使用同义词库T“注释”文档>术语<玄武岩>在语义上等同于“注释”>使用sarus T术语<rock>的文档。因此，有>这样做毫无意义。> >使用同义词库的人会同意“玄武岩”和“岩石”是>等价物？> >>如果你想说更具体的话，可以使用>同义词表，那么您需要一个将<玄武岩>作为>首选术语。> >但是如果没有呢？> >>或者，使用自由文本关键字注释。> >注意，我指的是除注释以外的用例>文档检索，对此我同意您应该用注释>概念，而不是术语。> >>“岩石”和“玄武岩”这两个词可能有很大不同>在自然语言话语中使用时对你的意义，但是>这完全无关。“岩石”这个词，还有西撒路>术语“岩石”是完全独立的实体。> > > > >>>一个更可能/有用的场景是>>>语言映射到>>>另一个中的非ref项，因为它更准确>>>翻译>>>单词。它支持更精细的映射，而不仅仅是在>>>概念。> > > > >>如果你在谈论语义映射，那么你是否>选择同义词表T术语<岩石>或同义词库T术语<玄武岩>>因为映射目标与>映射，因为同义词表T术语<岩石>和同义词库T>术语<玄武岩>是语义上等价的标记。因此，>如果你谈论的是语义映射，这是不可能的>创建一个比现在更精细的映射>通过概念之间的映射实现。> >不在概念层面上，但在术语层面上是可能的？> >用X语言表示prefTerm A通常是错误的>在文本中显示/使用/。。。在语言Y中使用非PrefTerm B？>它提供>您可以随意忽略的其他信息，因为>概念到概念的映射由术语到术语的映射隐含>（好吧，如果您这样定义映射词汇表的话）。它>可能会有帮助>例如在翻译或展示中。> >也许这不是很有用，但我什么也没看到>这也是根本错误的。> >>>第一次使用是如果您真的对该特定>>>术语而不是其>>>同义词。例如，如果要计算>>>乘以某个概念>>>拼写错误。或者计算特定术语的出现次数。> > > > >>你怎么能把“概念”拼错？你在数什么>确切地说？你所说的“特定术语的出现”是什么意思？> >概念不能拼写错误，因为它是无名的。你是>计算术语，而不是概念。> >>注意：出现在>自然语言文档和共享的同义词库术语>完全不同的相同字符序列>实体。他们有着相同的性格>序列可以让你推断出什么都没有。> >为什么不呢？当然，您可能需要假设>条款和>单词重叠，但我认为程序员可能会这么做。> >>我说得有道理吗？> >我可以非常清楚地看到你来自哪里，以及我的用例>也许最终会变成完整的数据库，但我确实认为人们>会尝试以各种方式使用同义词库，但不会>这样做是错误的。这些只是在>“我们需要一个Term类来将属性附加到”参数（即>可能是一个更有说服力的论点）。如果我们引入一个术语>类，它们是我们不能禁止的可能用途。> >干杯，>马克。> > -- >Mark F.J.van Assem-阿姆斯特丹Vrije大学> mark@cs.vu.nl -网址：http://www.cs.vu.nl/~马克>
接收日期：2005年10月26日星期三15:38:55 UTC