形状和基数

[托马斯•贝克]

>在9/24/20早上7:47,Phil Barker写道:>我对此的用例来自于我发现错误的验证>实例数据中的> >是由于人们输入错误的类id造成的。>> >http://schema.org/course而不是http://schema.org/Course。我的>解决方案是加入一个规则，归结为“如果你的课程>> >列表中没有任何课程，你做了某种>> >错误”。我接受Karen的观点(并同意)，您的用例可以通过一个带有“课程列表形状”的概要文件来满足，该概要文件定义了主题实体(课程列表)与对象实体之间的关系(例如，“hasCourse”?)，该对象实体是用强制的rdf:type arc for描述的http://schema.org/Course(根据“课程形状”)。在ShEx: foo:CourseListShape {bar:hasCourse @foo:CourseShape} foo:CourseShape {rdf:type sdo:Course}中，类似地，正如Karen指出的，“图书俱乐部形状”可能需要与图书和成员的关系(分别在图书形状和成员形状中描述)。然而，如果我正确理解的话，你想要把整个图(“实例数据”)作为一个“课程列表”，例如::x rdf:type sdo: course:y rdf:type sdo: course:z rdf:type sdo: course，如果图没有至少一个'rdf:type sdo: course '三元组，你想要得到一个验证错误。你想要得到这个结果，而不必为“课程列表”::e创建一个实体(':e')::e ex:hasCourse:x - NOT!:e例:hasCourse:y - NOT!:e例:hasCourse:z - NOT!类似地，您希望将以下图视为“bookclub”::x rdf:type ex:Book:y rdf:type ex:Member，如果该图没有至少一个'rdf:type ex:Book'弧和一个'rdf:type ex:Member'弧，并且无需为"bookclub"::e bar:hasBook:x - not !:e bar:hasMember:y - NOT!我是否正确理解了你的要求?EricP指出，在整个图上测试三元组的基数以引发验证错误目前超出了ShEx(或SHACL)的范围。 In principle, it could be supported in ShEx by extending shape maps with cardinality. A shape map defines a set of nodes in a graph, either by query or by simple numeration, and specifies the shapes against which those nodes are to be validated. For example, the following hypothetical shape map -- hypothetical because cardinality ('+' for 'one or more') is not supported for ShEx shape maps -- could be wrapped in a context where an error would be raised if a graph did not have at least one 'rdf:type ex:Book' arc and one 'rdf:type ex:Member' arc: { {FOCUS rdf:type ex:Book}@<#BookShape>, {FOCUS rdf:type ex:Member}@<#MemberShape> }+ More simply, perhaps, one could check for the presence (or not) of a given triple in the graph with a SPARQL query. The DCAP CSV format we are designing does not have its own validation semantics -- nor should it, because we do not have the resources to invent yet another validation language alongside ShEx, SHACL, JSON Schema, and the like. As I see it, the value of the DCAP CSV format, beyond that of presenting a profile as a readable table, depends on how well it can be translated into actionable schemas. On 2020-09-25 07:15, Phil Barker wrote: >所以你实际上是在建议使用这个规范意味着我必须这样做>以某种方式建模我的数据，例如有一个顶级实体BookClub或>我是否需要一个课程列表?在我看来，您的用例确实可以通过使用BookClub和CourseList的实体对数据建模来满足，并按照BookClub和CourseList的形状进行描述，正如Karen所建议的那样。但是，如果现有的验证语言不能满足您的要求，那么依赖于这些语言可用来作为验证基础的DCAP CSV格式就不能满足要求。我也不清楚如何在表格格式的限制下传达这样的验证条件。因此，我认为该需求超出了DCAP CSV格式的范围——需要在概要文件本身之外处理，例如使用SPARQL查询。汤姆——汤姆·贝克<Tom在tombaker.org上>