Understanding the right data type & structure for schema.org JSON representation - schema.org

Question

I've been looking at schema.org and it seems like a great idea for a public project that models the schema for several common types of data entities (Person, Place, Thing, Book, Movie, etc...).
I'm having trouble understanding two concepts regarding the data types and structure
I'll use the Recipe schema as an example, specifically the (simplified) raw JSON representation from the bottom of that page:
{
"#context": "http://schema.org",
"#type": "Recipe",
"author": "John Smith",
"name": "Mom's World Famous Banana Bread",
"nutrition": {
"#type": "NutritionInformation",
"calories": "240 calories",
"fatContent": "9 grams fat"
},
"recipeIngredient": [
"3 or 4 ripe bananas, smashed",
"1 egg",
"3/4 cup of sugar"
],
}
The author field should be of type Organization or Person, but the above JSON simply represents it as a string ("John Smith"). On the other hand, the nutrion field is of type NutritionInformation but it's represented as a fully structured object (i.e. not just a string). In what situations should we use the former versus the latter? Is it assumed that each object can optionally be distilled down to a simple string if more detail is not needed?
The recipeIngredient field is a list/array of items, but nothing in the specification document mentions that it should be a list. Can it also just be a single element? How do we know when to use a list versus a single element?

Answer 1

Expected types
Every Schema.org property can have a Text¹, a URL¹, or a Role value, even if they are not listed under "Values expected to be one of these types".
Quote from the data model documentation:
We also expect that often, where we expect a property value of type Person, Place, Organization or some other subClassOf Thing, we will get a text string, even if our schemas don't formally document that expectation. In the spirit of "some data is better than none", search engines will often accept this markup and do the best we can. Similarly, some types such as Role and URL can be used with all properties, and we encourage this kind of experimentation amongst data consumers.
In case Text is not listed as expected type, it’s usually better to provide one of the expected types instead of Text. In your example, going with an expected type would at least convey whether the author is a Person or an Organization, and it would give you the chance to provide an #id value, which allows others to make statements about the author of this recipe, or to understand that two authors are the same.
Multiple values
Every property can have multiple values. This is a core feature in all three syntaxes supported by Schema.org (JSON-LD, Microdata, RDFa).
Unless the property’s definition says otherwise, you should not put multiple values into one property value, not least because no delimiter is defined. So, not using an array for recipeIngredient would be incorrect, as this property expects "A single ingredient".
¹ As Text and URL are subtypes of DataType, these types should not be specified. If it’s a string value, it’s of type Text; if it’s an #id value, it’s of type URL.