cardinality - Revision history

Aaronpk: Replace with {{DISPLAYTITLE:}}

2020-07-18T16:21:15Z

Replace <entry-title> with {{DISPLAYTITLE:}}

← Older revision		Revision as of 16:21, 18 July 2020
Line 1:		Line 1:
	~~<entry-title>~~cardinality~~</entry-title>~~		{{DISPLAYTITLE:cardinality}}
	Cardinality pertains to whether a property is required, and if so, how many instances may be present.		Cardinality pertains to whether a property is required, and if so, how many instances may be present.

Tantek: adopting compound properties from other formats

2012-03-04T04:13:49Z

adopting compound properties from other formats

← Older revision		Revision as of 04:13, 4 March 2012
Line 15:		Line 15:

	See [[microformats-2#Summary\|point (2.) in the microformats 2 summary]]		See [[microformats-2#Summary\|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) :

			<blockquote>Plural components are made singular, and thus multiple nested elements are used to represent multiple text values that are comma-delimited.</blockquote>

			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 ==		== optional is required ==

Tantek: informative ref

2012-03-03T02:08:19Z

informative ref

← Older revision		Revision as of 02:08, 3 March 2012
Line 63:		Line 63:

	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.		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 [http://lists.w3.org/Archives/Public/public-vocabs/2012Mar/0016.html email by Tantek Çelik 2012-03-01 to W3C public-vocabs list]

	== see also ==		== see also ==
	* [[naming]]		* [[naming]]
	* [[principles]]		* [[principles]]

Tantek: drafted based on email I sent to w3c vocabs list

2012-03-03T02:05:19Z

drafted based on email I sent to w3c vocabs list

New page

<entry-title>cardinality</entry-title>
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 [[microformats-2#Summary|point (2.) in the microformats 2 summary]]

== 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.

== see also ==
* [[naming]]
* [[principles]]