（长回复）各位，我同意并理解你的目标，我希望你能接受我的对于不仅满足它的直接社区，也是W3C标准所针对的更广泛的社区正常寻址。总之，很容易看出许多好的想法已经进入第一个WD。当做，约翰·麦克卢尔1.从马克的反应来看，我的“用例”显然说得不好。由类推，最佳实践论文“OWL中的简单零件-孔关系”本体论”正确地指出，它的四种设计模式中有三种是不利之处在于它们复制了一个人的本体的部分。我正在努力传达当前SKOS实现也意味着类似重复。问题始于skos:subject，其范围是skos:Concept。从什么开始我学到了，实例化时的skos：概念是owl:Thing。这意味着skos:subject无法引用rdfs:Class。这意味着无论如何绑定到文档的本体是全面的，它的任何类都不能是指代文本单元的主题。我很不舒服这个结果是因为我对“主体”的定义肯定是由引用一组通用实例或一组特定实例，或针对特定实例；rdfs：类对象当然是集合的代表的泛型实例，这似乎是最常见的“主题”绑定类型到文本单位。简而言之，skos的定义：subject阻止了我采用SKOS，因为您的互操作性目标。我建议的“修复”是三重的。首先，更改skos的范围：服从rdfs:Class，允许将本体条目作为文本主题引用unit，并将skos:isSubjectOf的域更改为rdfs:Class，从而允许由本体类编目并在该类中列出的资源。第二，将skos:Concept的超类更改为owl:Class，允许分类条目作为文本单元的主题引用。第三，锐化skos：强调其与文档作者的特定相关性的概念，而不是本体作者。2.一些人回应说，使用rdfs:subClassOf表示概念方案是不恰当的。坦白地说，这让我困惑，因为我无法检测到任何NT/BT和子类/超类关系之间的差异。顺便说一句，我没有建议消除sko：更广泛地支持rdfs:subClassOf，但更确切地说（在OWL中）这两者是等价的或至少skos:wide是rdfs:subClassOf的子属性。但更重要的是，如果Concept是owl:Class的子类，那么它继承owl:Class的属性。我建议在这方面采取几项行动关注。首先，评估Concept的命名相关属性是否更好与猫头鹰相关：阶级——天知道选择越多越好现在可以使用rdfs:label和dc:title。其次，考虑使用owl:unionOf属性表示更狭义的概念。第三，识别语义（如果有）用于在概念中定义的概念（可以定义类类内）。第四，确定owl:Restriction（或子类）是否有用用于记录由概念。第五，检查概念。具体来说，我强烈怀疑狭义概念的表示是owl:unionOf，因为这将提供直接支持引用本体类的概念方案（主题图）（这与所说的对概念方案“适当”的担忧是一致的设置子类关系）。如果“unionOf”太技术化，我建议用一个更具交际性的名称将其分属性（或更好地等效它）SKOS利益相关者。一个简单的概念================<概念rdf:ID='Level1Concept'><owl:unionOf rdf:parseType='Collection'><owl:Class rdf:about='OntologyClass'/><概念rdf:ID='Level2Concept'/></owl:unionOf></概念>现在，这种方法还与SKOS集合相关的类和属性。收藏概念========================<概念rdf:ID='Level1Concept'><rdfs:subClassOf rdf:parseType='Collection'><owl:Class><rdfs:label>集合1<owl:unionOf rdf:parseType='Collection'><owl:Class rdf:about='OntologyClass1'/><概念rdf:ID='Level2AConcept’/></owl:unionOf></owl:Class><owl:Class><rdfs:label>集合2<owl:unionOf rdf:parseType='OrderedCollection'><owl:Class rdf:about='OntologyClass2'/><概念rdf:ID='Level2BConcept’/></owl:unionOf></owl:Class></rdfs:subClassOf></概念>一些人认为在skos:Concept和owl:Class之间建立关系（或等价地，在skos:broader和rdfs:subClassOf之间）被认为是可信的由于担心某些概念方案不“合适”，因此不合适本体论。我这么说：因为概念的任何实例都不可能是实例化后，发布“差”本体不会产生任何影响。可以有人发现任何影响吗？SKOS软件理论家的工作是确保从未实例化任何Concept实例。显著的好处（语义和功能上）通过使Concept成为元类如果任何资源具有<rdf:typerdf:resource='someConcept'/>元素。3.似乎有一些共识认为概念和a主题。我的建议是不要再拐弯抹角了，好好谈谈TMI团队，并就以下各项的正确定义和作用达成决议每个。在这种情况下，让我指出，没有人需要的是另一个标准“不知道它的基类代表什么”。。。。什么时候意味着标准互操作性。。。。因此，我非常反对定义一个概念作为“抽象的想法或概念；思想单位”[SKOS核心词汇]或有意识地“不严格”或“非正式”。。。。这与对我来说，标准是什么的概念。就我个人而言，TopicMap相当于ConceptScheme，并且Concept相当于Topic。我想需要添加一些与Topic Map相关的属性对这件事比我知道得多。4.主题索引提出了一个问题。>因为skos:概念不应该被解释为类I>认为rdf:type不是skos:Concept应该在中使用的方式>为文档编制索引。顺便说一句，如果是，我们如何区分>类/skos实例之间：“正常意义上”的概念人>（即真实人物的实例）和具有rdf:type的文档>与同一类/skos的关系：概念人？没错，使用rdf:type而不是skos:subject是完全错误的。它来自我之前误解了一个概念，作为owl:Class的一个子类，因此可以有具体的例子。现在我看到一个从未有过的概念任何实例，必须由SKOS-aware Reasoner强制执行的规则。5.其他我得到了反对票，认为概念不是一个类别；解释对我来说会很有用。我的职位依赖于WordNet的定义类别，“类别”与“类”或“主题”或“概念”的关系复数v单数名词，等等……注意其中一个SKOS的dc:title示例，呵呵：<skos:ConceptScheme rdf:about=“http://my.example.org/theGCL/version2.1">政府类别列表2.1版...</skos:ConceptScheme>我也有点困惑——抱歉，即使在与OASIS合作20分钟后文档——主题指示器的确切含义。。。。。和SKOS例子很差。。。。我怀疑它的功能可以由owl：如上所述的限制（我对主题指示器的理解是它标志着那些*可能*被用作主题的概念，即概念意思是明确的，没有主题指标——现在，我建议而不是确定那些可能不是给定类型的主题的概念文档资源或文本单元，其中分类概念将指定否任何类型的文档资源都可以有作为主题的范畴概念）。Mark询问是否修改SKOS指南，使其对非中小企业（如如果有一个花园-各种各样的数据模型，可以显示与TMI协商后保留的关键条款之间的关系团队。FWIW有向图虽然有趣，但与最后，更多RDF示例和完整示例！dc:title是否可以映射到其中一个SKOS标签？最后一个想法。我自己的本体定义了一个名为“Noun”的元类，它有一个属性“hasPlural”。。。。作为消除谓词歧义设计模式的一部分转换为谓词动词和谓词名词（即DirectObject）。。。。我的其目的是使该属性等效于您的标签属性之一。
接收日期：2005年7月22日星期五02:54:25 UTC