8月26日会议的问题

[托马斯•贝克]

在2020-09-09 12:28,Phil Barker写道:>有人看到另一种方法吗?我知道菲尔想找个办法>> >来包含类，我不知道这是否满足他所有的用例。>我想看看那些用例。嗨，菲尔，非常感谢，非常有帮助!一些第一反应…>我认为它是在应用程序概要文件的定义中固有的。“我们>将应用程序概要定义为由绘制的数据元素组成的模式>从一个或多个名称空间“Heery和Patel><http://www.ariadne.ac.uk/issue/25/app-profiles/>)，如果“数据>名称空间中的元素包含类，那么应用程序概要文件应该包含类>要把他们包括在内。这个定义中没有说属性是更多的>比阶级重要，所以我认为他们会被平等对待。我不太同意。所有在当时被称为“元素”的东西都被称为“属性”;我认为这对Heery和Patel论文中引用的所有元素都是正确的。属性加类的统称过去是，现在仍然是“术语”(在RDF世界中也是非正式的)。在这一组中，我认为我们实际上已经对属性进行了特殊处理，我们说，最微小的可能轮廓是一系列属性。在RDF中，资源的类用RDF:type arc表示，在语句的对象符合的形状上下文中，我们的模型覆盖了它。从表面上看，我认为这个可以满足你的要求。>但问题是关于用例的:>>当将一个大的通用模式裁剪为一个更小的更具体的模式时(例如。>用例14 <https://github.com/dcmi/dcap/issues/14>)我也想>生成应用程序概要文件的RDF Schema定义文件>只包含我想要使用的类。(我无法告诉你我有多频繁>请求schema.org的模式定义文件，该文件仅包含>与教育课程相关的部分，或与>组织。)您是在暗示最简单的概要文件可能是一个类列表吗?在实践中，这可以用一系列形状来表达吗?也就是说，通过创建一系列由其类型弧定义的形状?在我的理解中，schema.org只是将可能相关的属性分组到相关的类中。换句话说，我认为这样做是为了提供信息、记录和显示——而不是因为类和相关属性之间有任何正式的联系。>当我基于应用程序概要文件创建输入表单时(用例16)><https://github.com/dcmi/dcap/issues/16>)，我找到了表单的那部分>/子表单与类相关。我可能想指定标签/描述>用于这些表单的方法与类的方法不同>原件。这些可以通过形状标签提供吗?>类似地，当发布应用程序概要文件(用例)的文档时>49 <https://github.com/dcmi/dcap/issues/49>)，这样的文档通常>围绕类构建(这里有一个例子><http://sdo-learningresources.appspot.com/docs/schemas.html>)，即使>不是我可能想改变类标签和笔记如何使用它们>对我的用户来说更具体。你的要求会被这样的清单所满足吗?Shape Label: Institution Prop_ID: rdf:type Constraint: schema:Organization Annotation:教育机构。—列出使用的Schema.org类。—为模式提供一个标签:与中使用的组织不同https://schema.org/Organization—提供不同于Schema.org中的描述—提供足够的信息来组装Schema.org文档的子集，例如，通过将Schema.org中的所有属性与Organization类关联起来。这样的列表可用于围绕类构造文档，如http://sdo-learningresources.appspot.com/docs/schemas.html．汤姆-汤姆·贝克<汤姆在tombaker.org>