Rdf 嵌套的SKOS概念方案？

我正试图用我公司的一些数据制作一个知识图表。我主要使用SKOS作为描述事物的本体，但是我遇到了一个关于

概念方案的用法的难题

基本上，我想创建一个用于导航各种概念方案的概念方案。尽管SKOS断言
概念
和
方案
是不相交的，但它也明确表示
SKOS:inScheme
没有域。这让我觉得我可以通过一个
ConceptScheme
，其中大多数/所有概念实际上都是
ConceptSchemes

使方案可导航似乎是一个很常见的问题，但我还没有找到太多关于这个主题的内容。这种“计划中的计划”是明智的做法吗？或者，如果没有，是否有更好的方法将不同的概念方案联系起来，以便它们获得这样一个解决方案所能提供的导航能力

p、 因为我计划以类似的方式构建一个数据目录（可能是一个目录目录目录），所以我也将其标记为“dcat”。然而，我认为对主要问题的明确回答也应该澄清DCAT方面的问题。
好吧，规范是明确的，概念和概念方案是不相交的。inScheme的领域与此无关。“我知道我的行为违反了规则A，但他们没有违反规则B，因此违反规则A是可以的。”这样不行

那么，违反规则的后果是什么


知道SKOS规则的数据验证器可能会抱怨
用于编辑或显示SKO的工具可能会混淆，并且可能无法工作
当你描述你的模特时，熟悉SKOS的人会给你难看的表情

如果你同意（你很可能同意），那就继续吧。
没有必要违反概念和概念方案的分离性。如果您使用
inScheme
创建方案方案，甚至创建方案和概念混合集合的方案M，则您没有为任何内容分配两种类型。您的计划成员只是有不同的类型。我同意你的解释，即缺少
inScheme
的域是为了使这类事情成为可能

换言之：将类型Concept和Concept Scheme分配给同一资源（不允许）与创建包含这两种类型的不同成员的集合之间存在差异

注：这种建模方法是否是解决问题的最佳方法，这与您在这里提出的问题不同。
RDF和OWL的思想是创建独立于应用程序的自描述数据集。然而，SKOS的正式实现并没有涵盖完整的规范。例如，标准规定，不应该有多个
skos:prefLabel
，但这无法实现，因为在OWL注释中，属性不能是
OWL:FunationalProperty
。例如，如果有一天在SHACL中有一个SKOS规范，那么这种模糊性是可以避免的，数据验证器可以使用标准和数据逻辑，而不是它们的本地应用程序逻辑。因此，假设我想避免错误地使用本体论，那么有没有其他方法来实现我似乎正在使用的这种递归KOS？也许skos的假设是，随着时间的推移，概念方案将保持基本不变。但是我看到很多独立的方案正在产生（a.LaAAA），并且需要在这些方案位于更大的知识图上的地方进行集成。如果一个概念方案是你在skos中可以拥有的最高级别的东西，突然这些方案开始感到难以置信的笨拙。我不明白你为什么要用skos来关联概念方案。SKOS主要是关于概念之间更广泛/更狭窄/相关的关系。这些是您想要在概念方案之间表达的关系吗？一个方案比另一个方案宽/窄意味着什么？@cygri（顺便说一句，谢谢你的回复）。很可能我完全搞砸了概念方案应该是什么，它可以是什么。我认为一个方案可以有层次关系。想象一下，我编写了一个应用程序，并为它使用的所有术语创建了一个概念方案。另外，我有一个
服务
。我的应用程序是一项服务，因此可能可以从
服务
方案导航，但它的行为就像一个概念。如果我需要为这一部分放弃SKOS模式，这也是可以接受的，但这将是一个耻辱，因为我需要构建一些看起来非常像SKOS的东西。我不会将应用程序建模为一个概念方案。我可能有一个“MyApp术语”方案，其中包含应用程序中使用的术语。然后是一个“术语”三重链接，将应用程序链接到概念方案。如果我有一个“服务”方案，下面有一个“MyApp”的概念，那么我可能仍然希望这个概念是一个独立于应用本身的资源。因此，我将有一个类型为skos:Concept的资源名为“MyApp”，另一个类型为xyz:Application的资源名为“MyApp”，由一个属性（如“main item”）链接。概念有其自身的特性和生命周期，与它们所代表的事物不同。因此，如果概念A是概念B和概念C的子概念，但我必须只保留一个关系（A是B的较窄术语），并且必须采用另一个A类，其中（A是B的较窄术语，A是A的较窄术语），这与我的问题有关吗？