回应:Nishad的要点

[Karen Coyle]

Tom等人，在会议上，John建议在引用名称空间的地方使用名称空间列。我在会议期间模拟了[1]的一个示例，但事实是，单个行可能使用多个名称空间(即属性和值类型)。尽管我所做的是试图将名称空间与它被前缀引用的行对齐，但似乎没有理由名称空间列自己在一行中;而且，每个id/名称空间对只需要引用一次。我意识到它可能在视觉上不协调，但这个[2]似乎是另一种可能性，其中id/域名在任何一行中陈述一次，但在正确的列。kc [1]https://github.com/kcoyle/RDF-AP/blob/master/test.csv［2］https://github.com/kcoyle/RDF-AP/blob/master/test2.csv在4/8/20上午6:54,Thomas Baker写道:>嗨Nishad,>>在你的要点[1]，我真的很喜欢这个想法>前缀在CSV的顶部!>>最初，我喜欢将每一行分配为a的想法>"type"，原则上允许三种类型的东西:>>*配置文件本身的URI(“BASE”)>*命名空间的声明前缀>*语句(与实体关联的属性/值对)。>>．..共享一组列。>>但是，我同意Phil关于名称空间的观点>uri并不适合“属性”。如果我们想>遵循RFC 4180[2]，“通用格式和MIME类型的CSV>(2005)，这意味着我们定义了一个头文件(或>隐式消息头):>>将包含对应于>文件，并应包含相同数量的字段>文件其余部分的记录…>>换句话说，如果前缀要被容纳进>平的，rfc4180兼容的格式，我没有办法>至少再添加一个列(这里是“namespace”)。>>然后让ID列作为的标识符>“基本”id、“前缀”id、“实体”id和“语句”>身份证似乎有点牵强。>>我仍然不确定为什么声明需要有>语句的标识符(例如。， B9“标题”，B10>“发布日期”)。在你的要点:>>*“实体”ID B11 ('person')被引用>第8行中的值('@person')。>>* "statement" id(如果我理解正确的话>function)——'title'， 'pubDate'， 'name'， 'email'，>'birthDate'——实际上没有被任何引用>CSV中的其他单元格。>>我创造了一个反义词，可以重新排列事物>这要看我怎么看了。>>我很抱歉这是最后一刻才送来的，但是>也许我们可以简单地分享屏幕，然后讨论>在调用。>>一会儿聊！>汤姆>>［1］https://gist.github.com/nishad/1339d3962002eea3f9282e4ef4b2b09c>［2］https://tools.ietf.org/html/rfc4180>［３］https://gist.github.com/tombaker/4c54606ef0dd033b6f306e23764ea384>>2020年3月26日星期四05:27:53PM +0000, Nishad thalhas写道:>>日期:2020年3月26日星期四17:27:53 +0000>>来自:Nishad thalhas <nishad thalhath.org>>>:“application-profiles-ig lists.www.voudr.com＂>><application-profiles-ig lists.www.voudr.com>>>主题:[Application-profiles-ig]对CSV格式的一些建议>>内容类型:multipart /替代;>>边界= " _000_0036F9E8BAD64FFAA2DB2D1ED0C15AA6thalhathorg_ ">>列表档案:<https://lists.www.voudr.com/pipermail/application-profiles-ig/>>>发送者:Application-profiles-ig>><application-profiles-ig-bounces lists.www.voudr.com>>>>>亲爱的凯伦、汤姆和大家:>>>>基于上次会议[1]，提出的简单CSV[2]格式，ShEx statements[3]， SimpleDSP[4]，以及简单格式[5]的形式主义，我想对简单CSV格式提出一些最小的改变。>>>>由于这些基于CSV的创作格式具有SimpleDSP的共同特征，如果我们能够避免它的注意事项，将会很有帮助。>>>>这个想法是让它更符合标准的CSV，利用ShEx的潜力。此外，它还可以在不同的序列化格式之间转换。>>>>我的建议的一个例子是[6]:https://gist.github.com/nishad/1339d3962002eea3f9282e4ef4b2b09c>>>>以下是拟议的改动:>>1.根据rfc4180[7]，每个记录位于单独的行上>>2.一个通用的标题行和列的顺序是不相关的，但表示使用概要文件词汇表的组件。>>3.一个可选的'type'行，用于指示记录的类型。在真正简单的概要文件中，或者没有前缀或实体的概要文件中，并不需要它。>>4.'type'可以是任何BASE、前缀、实体或属性。默认值是'property'，如果没有给出，则返回默认值。>>5.可选'ValueType'， (Literal, Nonliteral, IRI)默认为'Literal'，并映射到shex: nodeconconstraint。对于更简单的概要文件，这也是一个可选的行，但是对于高级概要文件的RDF、ShEx、ShExR和OWL表达式很方便。>>6.'Value'是可选的，默认为'text'或'xsd:string'。'value'可以只是一个数据类型，也可以是一个用ShExC表示的ShEx约束字符串。例如，shex:IRIStem， 'xsd:float mininclu3.14 maxinclu9.0 '或'xsd:string ["foo" "bar"]'>>7.统一的ID，便于转换为ShEx, RDF，或JSON-LD。统一ID更适合于设计高效的解析器和转换器。>>>>优点是:>>1.从实现者的角度来看，每个单元都可以用命名标签来处理，这对于模板和适应复杂的用例来说要容易得多。>>2.CSV可以与任何数据序列化格式(如JSON、NDJSON或YAML)互操作，没有任何损失。>>3.根据用例，工作表可以使用自定义行水平扩展。不过，它并没有打破DCAP-2的定义。>>4.标题标签有助于在类似格式(如ShExstatements)之间创建简单的转换。>>5.类型声明使得每个记录都是可操作的，而无需编程开销。>>6.每个元素(包括前缀)都可以在一个有效的CSV中声明。>>7.它不需要对当前CSV格式的简单概要文件进行任何更改，只需要合并ID字段。>>>>我的进一步建议是将“值”拆分为“数据类型”和“约束”，这样格式就可以进一步互操作。此外，Constraints还可以使用ShExC文本约束字符串来记录复杂的规则，否则这些规则很难用表格格式表示。>>>>simpleCSV的所有其他属性都被维护，例如未转义的'@'作为ID的指针。所有在“entity”后面声明的属性都属于“entity”。只有在有效的CSV中表示完整的元数据应用程序配置文件时，才需要所有这些最小的更改。>>>>Nishad>>>>［1］https://github.com/dcmi/dcap/blob/master/meetings/2020/2020-03-18.dcap_zoom_call.md>>［2］https://github.com/dcmi/dcap/blob/master/prototypes/simple/simpleInstance.csv>>［３］https://github.com/johnsamuelwrites/ShExStatements>>［4］https://metabridge.jp/tutorial_dsp.html>>［5］https://github.com/dcmi/dcap/blob/master/prototypes/simple/formalisms.md>>［6］https://gist.github.com/nishad/1339d3962002eea3f9282e4ef4b2b09c>>［7］https://tools.ietf.org/html/rfc4180#section-2>>>——Karen Coylekcoyle kcoyle.nethttp://kcoyle.netskype: kcoylenet