请审阅初稿

[托马斯•贝克]

在2020-10-15 03:53,Karen Coyle写道:>我可以做一个简短的文档>解释，但不像教程，我们没有理由不能>有两个。也许我们可以有两份文件:一本参考书和一本入门书。Primer可以查看创建概要文件的过程，从最小属性列表开始，添加各种约束，并将这些语句分组成形状。在Primer中开发教程方法可能意味着(较短的)Reference可以简单地定义元素的含义。>同时关注属性和形状(或者甚至从形状开始)>确实与原来的DCAP类似。这样的文件可能在哪里>我们将解释这项工作与原始DCAP的关系。好的。>我必须承认“容器”对我来说是一种全新的描述形状和>还没有引起我的共鸣。对我来说，形状是一个固定的东西>形状节点作为锚点。但形状由埃里克所说的组成>"外向三元组"它们和这些外向三元组连在一起>但我不认为它们像它们那样是“包容的”>把彼此联系在一起，可能没有明确的边界。我的>意味着他们周围没有什么东西能把他们连在一起——他们能>在内部。(我肯定我没说得那么好。)我更喜欢认为>形状作为一个图形-一组相连的三元组。我明白你的意思了。然而，在我看来，每个形状都集中在一个节点及其邻近的节点上——从该节点出发的外向三元组的集合。实际上，它是在这个邻域周围画一条线，从这个意义上说，“包含”这个三元组集合。但也许“容器”不是最好的词。它在任何意义上都不是将一个邻近节点与另一个邻近节点隔离开来。作为一个具有外向三元组的节点，形状是一个图形，但在我看来，形状实际上并没有将一个三元组与另一个三元组连接起来。相反，它是用一组_node_——object或值节点链接主题节点。它由一个链接(通过谓词)到一组对象节点的主题节点组成。或者，换句话说:它是一个用属性-值对描述的主题。从给定节点的角度看，它是图的一部分。 It is the set of shapes, then, link together to describe the graph. >最终，我们应该能够将这个模型归结为>>是一个能够传达故事的整体结构和描述的故事>在一两段中说明它的特点。这个故事可以>>将元数据描述为关于事物的语句集>>在世界上。如果元数据描述了不止一种>>事物，然后是关于特定事物的陈述>>可以在称为>>“形状”。>>您认为这是对本文档的介绍，还是有所不同>文件吗?它本身不是文档，而是对词汇表的一个抽象长度的总结——可以用来介绍Primer和Reference。汤姆-汤姆·贝克<汤姆在tombaker.org>