kcoyle
commented
4 years ago John, thanks. In fact, we started with a single cardinality column.[1] However, we were unclear what would be the values in that column. Of course, many people would be comfortable with something like "1,1" for "mandatory, not repeatable". Others are more accustomed to "1..1". With those forms, it can be hard to say "unlimited" for the repeatability digit; some use "-1", and in the dotted form you often see "..n". And then we thought about the fact that anyone who isn't or hasn't been at some point a coder wouldn't have encountered these forms. A software interface could display this as the more common notions of mandatory and repeatable however we aren't assuming that there will be a software interface to the table for profile developers, but that they will work directly in a spreadsheet program. So we went with the two columns and with what we assume to be the more common terminology. The values would be a binary yes/no which is pretty simple to understand. That doesn't mean we cannot change, that's just the background information.
Another issue we've discussed has to do with mixing information in a single column. This has come up in the value column. Could we allow both values like "text" and a URI stem in the same column?
text https://id.loc.gov/subject/ anyURI "red, blue, green"
That would reduce the value/value_type to a single column. That worried some of us due to the difficulty in interpretation for those creating applications from the profile. Programs converting the tabular format to actionable code would have to be pretty nimble to triage that column.
These are both open questions. If there is a desire to put them up for more discussion I can create github issues for them. That might be useful in any case so that we have a record of the pros and cons as we see them.
kc [1] https://github.com/dcmi/dcap/blob/master/prototypes/simpleFromHackathon/profile2Instance1.csv
On 3/5/20 5:51 AM, John Samuel wrote:
Taking a look at these two examples for the creation of application profiles,
- https://github.com/dcmi/dcap/tree/master/prototypes/simpleFromHackathon
- https://github.com/dcmi/dcap/tree/master/prototypes/wikidata_painting
I think the application profile can be further simplified
Column names element Property Property Label Value Value type Annotation Constraint
Repeat/Mand(atory) as columns may help the users of application profiles. However, if you take a look at https://en.wikipedia.org/wiki/E-GMS, we see there are other possibilities: "mandatory", "mandatory if applicable", "recommended" or "optional". So, the idea of the final column is to be able to create a flexible list of constraints, including cardinality.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dcmi/dcap/issues/58?email_source=notifications&email_token=AAL53YLJ2RD7N2PZCEDEJ3DRF6U4VA5CNFSM4LCKKCM2YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ISZE56Q, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAL53YLRCPLBC6EQIVMT3M3RF6U4VANCNFSM4LCKKCMQ.
-- Karen Coyle kcoyle@kcoyle.net http://kcoyle.net skype: kcoylenet
tombaker
Taking a look at these two examples for the creation of application profiles,
I think the application profile can be further simplified
Repeat/Mand(atory) as columns may help the users of application profiles. However, if you take a look at https://en.wikipedia.org/wiki/E-GMS, we see there are other possibilities: "mandatory", "mandatory if applicable", "recommended" or "optional". So, the idea of the final column is to be able to create a flexible list of constraints, including cardinality.