Well, *all* processing is being done in terms of collections, so that wouldn't be an issue. Even fields that are explicitly singletons are implemented as an ExactlyOne collection.
(Basically, the QL language is going to be monadic down to its socks -- everything is about passing collections through pipeline stages. Sometimes, those collections will have only one item, or zero items; that's fine. The notion is to make the collections so universal that you don't even think about them.)
Anyway, it's a good point, although I suspect that Tags per se aren't the right way to handle most of your examples. Mind, Tags are only one of a dozen data types designed so far -- an important one, but not the right tool for every job. I suspect that Name is of type ExactlyOne[Text], and Ability is the same, or maybe ExactlyOne[Link[Effect]], where Effect is a separate Model (class). (Actually, Name and DisplayName are built into the system -- all Things have both as semi-optional-but-encouraged properties.)
But yes -- at this point I'm leaning towards the optional-constraint suggestion as the best way to handle this, if and when it turns out to actually be necessary...
no subject
(Basically, the QL language is going to be monadic down to its socks -- everything is about passing collections through pipeline stages. Sometimes, those collections will have only one item, or zero items; that's fine. The notion is to make the collections so universal that you don't even think about them.)
Anyway, it's a good point, although I suspect that Tags per se aren't the right way to handle most of your examples. Mind, Tags are only one of a dozen data types designed so far -- an important one, but not the right tool for every job. I suspect that Name is of type ExactlyOne[Text], and Ability is the same, or maybe ExactlyOne[Link[Effect]], where Effect is a separate Model (class). (Actually, Name and DisplayName are built into the system -- all Things have both as semi-optional-but-encouraged properties.)
But yes -- at this point I'm leaning towards the optional-constraint suggestion as the best way to handle this, if and when it turns out to actually be necessary...