This is a pretty substantial proposal, even though it is targetted for 'pending'. I have only taken a quick look for now, forgive the scrappy notes but I figured some immediate feedback is better than waiting:

It needs review at least for innappropriate generality e.g. "amount" property, "renegotiable", "currency", and/or redeclarations e.g. "email" is given a new rdfs:label for some reason.

By "innappropriate generality" I mean terms that have pretty specific defined meaning but rather general purpose names that could easily apply to areas of schema.org where their meaning seems unanticipated or underdocumented. For example, could a Demand or Offer be "renegotiable"?

It looks like a technical problem with these definitions is that they are all listed as if they were new terms, i.e. with rdfs:label, but some already exist. So "amount", "currency", "email" are all existing properties but presented as if they are new. Check some of the other data/ext/pending//.rdfa files for examples of annotating existing properties. These are nearly right (you don't say that they're isPartOf pending) but the additional rdfs:label and rdfs:comment shouldn't be there.

'amount' is already a general property - this proposal is just adding a proposed new Type to its domain.
'currency' s already a general property - this proposal is just adding a proposed new Type to its domain.

There is a display issue - you would see that they are in red not blue (ie. augmented in extension not defined asPartOf extension)

Can easilly drop the rdfs:labels for email.

Removed comment from email - general comment is fine.

"renegotiable" is a boolean that could be applied to Offer, Demand etc. Surely tht is part of what would come out of its 'pending' review?

@RichardWallis 'renegotiable' is a pretty significant addition to the meaning of the existing Offer/Demand patterns. I hesitate to introduce such lightheartedly and in the context of a single domain extension.

What shall this imply - that certain aspects of the offer are to be negotiated? Or that one can request a better offer? In that case I would prefer modeling the "base" offer more broadly (e.g. with ranges for prices or other terms and conditions) and introduce an "extends" mechanism so that one offer can be refined into a new one.

One could also think of going the Actions route, i.e. defining a vocabulary for specifying technically (like API) you can request the refinement or update of an offer.

I mean, what is the implication of an offer being renegotiable? schema.org does not imply that an offer is binding anyway, see

http://www.heppnetz.de/ontologies/goodrelations/v1.html#Offering

"An offering represents the public, not necessarily binding, not necessarily exclusive, announcement by a gr:BusinessEntity to provide (or seek) a certain gr:BusinessFunction for a certain gr:ProductOrService to a specified target audience. An offering is specified by the type of product or service or bundle it refers to, what business function is being offered (sales, rental, ...), and a set of commercial properties. "

So even if renegotiable is missing, you can try to renegotiate the offer. s

To clarify, the current definition of "renegotiable" does not say anything at all about its applicability to Offer/Demand. It is attached at "Thing > Intangible > Service > FinancialProduct > LoanOrCredit". My concern was that such terminology will give the impression of applicability to Offer/Demand situations, and the absence of an account of how these pieces relate to each other chips away at the consistency of the whole system.

How about calling it "financialProductRenegotiability" for now at least?

@danbri Yes, a property at the level of the individual product / service type is less prone to conflicts, even if it covers commercial aspects of the offer.

@danbri In principle that makes sense. However in search of a shorter property name than “financialProductRenegotiability”

What about renegotiableLoan as we are attaching it a LoanOrCredit?

Commented out mobileApp, textChat, email in favour of moving them to a separate Issue (#1265)
Updated example that references mobileApp on assumption #1265 is adopted.

Replaced by PR (#1300)