[Application-profiles-ig] Order, manifest, etc

Fri May 21 19:06:46 BST 2021

All, I recently added a comment to the issue on defining the order of values [1] in which I suggested that we could consider using the manifest to give this kind of constraint on a property. That was an unexamed idea on my part, and now is leading me to a number of different considerations. The upshot, though, is that it will be difficult to target specific rows in our manifest because they may not be uniquely identified. I came to this when I realized that the CSVW manifest defines mainly definitions and constraints on columns, and none on rows. There is the possibility to address rows but only if they have a unique primary key. [2] I don't think we can assume this of a TAP - even a shapeID/propertyID combination could occur more than once. It would be great, though, to try this out in our search for a solution. We clearly do not want to greatly expand the number of columns. The order question alone bring up at least 4 possible different needs: 1. The order of values for a repeatable property 2. The order of properties within a shape (not sure if RDF can do this) 3. The order of shapes (?possible?) 4. The order of choices in a picklist (order reflects preference) The seemingly simple concept of "order" quickly multiplies into many different requirements, each of which would require us to define a column to carry that information; we can expect equal or more complexity from requirements like "AND-OR-NOT". If each new requirement results in multiple added columns, you can see how it quickly gets out of hand. This is why I was hoping that we could move some specific requirements to the manifest where they wouldn't impact the size of the table. I don't know if we can do this. In addition, if we allow definition of rows in a manifest, we have to warn users that it only works if the row's identity is unique in the TAP. We are going to need a philosophy to guide us as requests for additions come in. I think that a robust extension mechanism could help out a lot here, but I have no idea what that might look like. I'm not sure where to go next, but will try to come up with a few use cases and questions that we can hash over at our next meeting. [1]https://github.com/dcmi/dctap/issues/14#issuecomment-842669449[2]https://www.w3.org/TR/2016/NOTE-tabular-data-primer-20160225/#row-types——卡伦Coylekcoyle at kcoyle.nethttp://kcoyle.net