2012年5月8日星期二上午5:04，Chris Harding<c.harding@opengroup.org>写道：>>我们正在研究一种定义UDEF对象类和>UDEF属性作为SKOS概念，并使用SKOS窄/宽来捕获>父对象类与其子对象类之间的关系，以及>父属性及其子属性。>>我们最初的问题是：>-这看起来是一种明智的方法吗？>-我们是否应该将整个UDEF作为一个单一的SKOS概念方案，或>会更好吗>为对象类和属性提供单独的概念方案？>我不完全确定使用SKOS是否一定是最增加语义丰富性的适当方法UDEF的目标应用程序。以下是一些可能有帮助的注意事项您决定纯粹基于SKOS的方法是否适合您的需要，或者RDF（S）+OWL是否可能是更好的方法。1.SKOS最初是为了表示知识而开发的*组织*系统，不是知识*表示*系统；也就是说，它的设计目的是代表思想之间的关系，而不是那些想法是关于。一个很好的测试，看看SKOS是否适合您的应用程序就是考虑在你的申请中是否有任何差异在某物是另一种某物和某物是之间其他事情的一部分。2.SKOS没有标准化的表达序列的方法概念，用于生成串联符号，或用于表示对可用于限制内容的概念类型的限制概念可以遵循其他概念。这本质上迫使UDEF是一个完整的枚举系统，这可能并不理想。3.UDEF上使用的示例CONOP公司<http://www.opengroup.org/udef/use/conops.htm>页面包含一个与国防后勤局（DLA）的互动示例。（以及概览页面标题为“操作概念”的事实：）建议与国防部和其他政府机构合作重要考虑。国防部语义互操作性和联邦工作正在使用OWL/RDF作为基础-请参阅以下内容幻灯片<http://www.dodenterprisearchitarchitecture.org/program/Documents/1015%20DWiz_DCMO_EAConf_Wednesday_May_2.pdf>作者：Dennis Wisnosky<丹尼斯·维斯诺斯基@osd+mil>（国防部BMA首席技术官兼首席执行官架构师）上周的国防部企业架构会议。4.美国空军早期在SAF-US（M）领导下的EVT中的工作表明RDF（S）+OWL不足以捕获大多数人的所有有用信息利益共同体；SKOS的弱语义大概是能够捕获更少的信息。（有趣的是，缩写EVT代表“企业词汇团队”；V甚至在以前就已经过时了该队被罢免）。5.一个自然语言术语在不同的情况下具有不同的含义CoIs，试图强迫主题专家一个或两个区域使用不同的术语。受试者表现水平物质专家被降级到接近新手的级别。查看一些UDEF定义似乎表明当前的定义不包括可能被认为对互操作性至关重要。例如，在“标识符”子树中，我们发现以下终端节点。*4.35.8*空军。分配。标识符*1.4.35.8*联合状态。空军。分配。标识符考虑到不同美国空军识别码的数量，这有点有问题，并且似乎基于未命名的特定用例。就映射到RDF（S）/OWL/SKOS而言，这些属性似乎暗示层次结构-RDFS中的SubPropertyOf，OWL中的SubDataPropertyIf，SKOS范围更广。就创建互操作系统而言，很难理解这些属性的语义将是。将数据字段标记为“4.35.8”意味着什么？将其与另一个标记为“4.35.8”的数据字段进行比较是否有意义？你能用这个字段连接来自不同来源的两条记录吗？你能加入两个记录吗，一个由“1.4.35.8”标识，另一个“4.35.8”？字段之间的关系严格来说是一种近似-无关系吗；在某种程度上是关于a联合国。空军。分配。它在某种程度上是关于空军。分配。标识符？UDEF创建的许多独特标签很可能是有效地重构为它们的语义组件，通过这样做更容易创建在企业规模及以上。西蒙