cardinality
Cardinality pertains to whether a property is required, and if so, how many instances may be present.
Summary: experience with the development of microformats over time has shown that making all properties optional and plural at a syntactical/schema level is more future proof.
points of cardinality
- bad idea to put cardinality into formats/schemas.
- better to make each property plural at a format/schema level.
- move any notion of "singular" semantics up to the per application level (use first occurrence/value of a property if necessary).
from experience
Our experience with microformats has shown all this and thus we are moving forward with 1-3 above in microformats-2 (explicitly making all properties both optional and plural at a syntax level, permitting applications to apply any needed singular semantics to first instance of a property).
See point (2.) in the microformats 2 summary
adopting compound properties from other formats
Per naming-principles, when adopting a compound property (a property where a single value is used to represent multiple components, like a list) :
Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.
Using a comma-delimited values (or delimiter-based text data in general) has been shown to be problematic in general case, e.g. CSV files. Thus it is better to decompose any such compound property into separate properties or multiple instances represented by multiple elements.
optional is required
Related: making properties optional has also been a hard lesson learned, with repeated examples, from hCard to hAtom - which to be fair took their notions of "required" properties from vCard and Atom, though a mistake propagated is still a mistake.
In short: people will omit properties when publishing, and often think of ways that it makes sense to do so - beyond what the original vocabulary designer(s) was/were thinking. Better to define what that means on a per vocabulary / application level than make it something syntactical.
faq
Perhaps not so *frequently*, but certainly *asked* questions.
should a format or syntax define cardinality
Q: Should a format or syntax define cardinality of its properties and terms?
A: No.
Experience with microformats has shown attempts to define cardinality in formats for publishing on the web create an unnecessary point of failure/fragility.
So, no, don't bother.
should English plurals as property names imply cardinality
Q: Should a property name with an English plural 's' (or its absense) imply any aspect of cardinality?
A: No.
Simple answer (using hRecipe as a real world designed/implemented source of examples)
- use singular forms of English nouns, even for (expected) multivalued properties. E.g. "ingredient" is the property name even though pretty much all recipes have multiple ingredients (and thus instances of that property)
- plural forms of English nouns should only be used when it implies specific meaning about any instance of the property (e.g. amounts), not some implication that the property is or may be multivalued. E.g. "instructions" is the property because a property value itself likely contains multiple human readable instructions, and in practice recipes have a single instance of this property. Related: the "calories" extension property (which is an amount).
does it ever make sense to define cardinality
Q: Does it ever make sense to define cardinality of a property?
A: It never makes sense to do so at a format or syntax/schema level.
vCard (up through v3) made the same mistake of declaring many properties to have at most one value.
Much of this was addressed in vCard4, where previously singular properties were made plural.
In short, vocabulary designers get cardinality wrong all the time, so you might as well give up trying. Seriously, none of us (including you) are that smart.
It's easier (and more future-proof) to simply allow every property to be plural, and then define any perceived singular semantics at a higher application level (which is where any notion of singular vs plural actually matters if at all). If it changes, changing the application is much easier than the format.
informative
Informative references.
- Page started with contents from email by Tantek Çelik 2012-03-01 to W3C public-vocabs list