请审阅初稿

[Karen Coyle]

谢谢,汤姆。更多内容如下:在10/15/20上午4:25,Thomas Baker写道:>你好,凯伦,>>2020年10月10日06:31，凯伦·科伊尔写道:>>我已经完成了我们的“alpha发行”文档的初稿:>>>>https://hackmd.io/pTp9ub_bQbO6vxZra1w-kw?view>>这是一个很好的开始!:-）>>>现在集中精力于总体方法。>>我喜欢解释器和约束器的区别>对我来说，这似乎与两者的区别无关>形状和语句，其中语句是约束>在Shapes上下文中的属性-值对。我承认我把它放进去了，没有很好地积分。你可以在Nishad的图表中看得更清楚:https://n1sh-my.sharepoint.com/:b:/g/personal/nishad_thalhath_org/EXhn1CYlFphLobPcUZjRe-YB9-94j9QmykBRqRlKwaMD_g?e=8hXG7J>>这是我如何使用DCAP模型:>>形状(语句的容器)>shapeID>shapeLabel>shapeClosed (? ?)>>属性-值语句()>——属性>propertyID>propertyLabel>——价值观>valueNodeType>valueDataType>valueConstraint>valueConstraintType>valueShape>——作为整体的陈述>强制性的>可重复的>请注意>>一个正交的、功能性的元素视图可以是:>>柱- profile的必要条件>propertyID>>——容器>shapeID>>——讲解员>shapeLabel>propertyLabel>请注意>>——限制>shapeClosed (? ?)>强制性的>可重复的>valueNodeType>valueDataType>valueConstraint>valueConstraintType>valueShape>尼沙德称这种形状为“结构”，供参考。我使用的顺序是我从一个幼稚的开发人员的角度所看到的步骤，所以带有教程的氛围。首先是属性，但从逻辑上讲，属性会得到标签。然后是值类型等等。将所有的属性信息保存在一个区域。然后把它做成形状。我可以看到一个大纲，就像你上面，但那将更多的是一个解释，而不是一步一步的文件。我可以制作一个简短的解释文件，但不太像教程，我们没有理由不能两者兼顾。同时查看属性和形状(甚至从形状开始)确实与原始DCAP相似。我们可以在这样的文件中解释这项工作与原始DCAP之间的关系。 >关于容器的故事可能是每个容器>持有关于一种事物的陈述。如果没有>形状在概要文件中指定，然后在容器中指定>profile作为一个整体，只描述了一种类型吗>的事情。我必须承认，“容器”对我来说是一种全新的描述形状的方式，而且(还没有?)没有引起我的共鸣。对我来说，形状是一个以形状节点为锚的锚定物。但它的形状是由Eric所说的“外向三元组”组成的，它们与这些外向三元组连接在一起(有点像菊花链)，但我不认为它们是“包含的”，因为它们相互联系在一起，可能没有明确的边界。我的意思是，他们周围没有什么东西把他们联系在一起——他们是内在联系在一起的。(我肯定我没说得那么好。)我更喜欢把形状看成一个图——一组相连的三元组。>>最终，我们应该能够将模型归结为>一个故事的整体结构和描述>它的特点在一两个段落。这个故事可以>将元数据描述为关于事物的语句集>在这个世界上。如果元数据描述了不止一种>事物，然后是关于特定事物的陈述>可以在称为>“形状”。您认为这是对本文档的介绍，还是不同的文档?kc >>汤姆>——Karen Coylekcoyle kcoyle.nethttp://kcoyle.netskype: kcoylenet