Add support for financial industry elements & integrate FIBO

[mfhepp]

The current support for financial products and services is weak. We need better support for financial products and services, i.e. credit cards as products (not just as payment methods), consumer accounts, loans and mortgages, etc.

This should be done in close alignment with the Financial Business Ontology (FIBO), http://www.edmcouncil.org/financialbusiness.

N.B.: This issue is meant as a place-holder to manage the already available pull request for this topic

[vickitardif]

Some quick comments:

• Is MonetaryAmount different than PriceSpecification? Granted, the latter is unfortunately named for some uses, but it seems better to re-use the type rather than adding a synonym.
• Is there an example of RelativePriceSpecification? I am trying to understand its intent.
• Is there an example of PaymentCard? I am trying to determine the difference between PaymentCard and its parent type PaymentMethod.

[Dataliberate]

Thanks for the comments Vicki - let me take them in turn:

• MonetaryAmount - is we believe, different enough to PriceSpecification to warrant a separate type. Firstly it is a quantifiable amount, or range, of money not directly related to the price of an offer, tax, valid periods, or other eligibility criteria. In the financial sector amounts of money are stand alone entities - see the example for DepositAccount where this type is used to define the limits of a potential account. It will be helpful to also add that example to MonetaryAmount, which we will do.
• RelativePriceSpecification - As yet there is no example for this. We intend to create examples for all the major proposed types soon, this one included.
• PaymentCard - there is not yet an example for this. PaymentCards as one of several types of PaymentMethod types (Cash, PayPal, Check, etc.) is an logical extension of what is already there. In the financial world there is also a differentiation between cards that are used only for payment (transport cards, student food & university facilities cards, etc.) and those that also have associated credit facilities - CreditCards. Adding examples for both credit and non-credit payment cards should help clarify this

[Dataliberate]

For tracking purposes the associated Pull Request is (#965)

[vickitardif]

Would it make sense to make PriceSpecification a subtype of MonetaryValue?

[sopekmir]

That was exactly what we discussed among us yesterday, so we will propose it with some high probability !

[danbri]

Q: Does FIBO have anything covering various kinds of filings e.g. company accounts?

[Dataliberate]

After discussion the request has been updated to make PriceSpecification
a subtype of the proposed new MonetaryAmount type.

[Dataliberate]

Background to this proposal and links to examples are available on a wiki page in the FIBO W3C Wiki Here: https://www.w3.org/community/fibo/wiki/Main_Page

[danbri]

/cc @chaals @pmika @scor @shankarnat

Ok, so @rvguha @vholland and I had occasion to discuss the core proposals in https://www.w3.org/community/fibo/wiki/Main_Page

In general we're positive about it, the changes are a good size, self-contained, and cover topics of widespread interest. The only area that is troubling has already been discussed somewhat here: MonetaryAmount. Guha expressed concern that it could encourage a proliferation of similar types, "Mass amount" etc. Also the accompanying properties, minAmount/maxAmount have very general names unrelated to the specific case of monetary quantities. The definitions (e.g. "The highest amount if the amount is a range.") are more general, so it isn't quite clear what the intent for them is here.

Perhaps we could have a call in a couple of weeks to work through the details?

[Dataliberate]

The proposing group are not particularly precious about the names of the properties you mention in MonetaryAmount.

The objective is to be able to describe a single amount, or the minimum / maximum of a range of money, with its associated currency.

Use cases, and examples, include a way to describe an amount such as $50 USD, or a range as in describing a DepositAccount being suitable for a balance between £1,000 and £1,000,000 GBP.

The descriptions for the terms minAmount/maxAmount were deliberately described in a generic way to enable reuse elsewhere.

[danbri]

Considering MonetaryAmount and http://schema.org/PriceSpecification and the existing properties with PriceSpecification as a value, at a quick look some of those appear not to really be prices.

Of the 7 incoming properties listed for PriceSpecification, these are the least pricey:

• http://schema.org/baseSalary
• http://schema.org/minimumPaymentDue
• http://schema.org/totalPaymentDue
• http://schema.org/netWorth

If we decide to integrate MonetaryAmount into the core, we ought to consider using it for these in place of PriceSpecification.

[Dataliberate]

All those do feel less price based and more amounts of money based.

I agree it is worth considering.

[sopekmir]

Yes, I could only confirm that we are really not sticking to the term name (MonetaryAmount) as long as the meaning of any potential replacing term is wide enough for the objectives Richard mentioned.

Of course I also feel that it perhaps could be indeed better to integarte it and reuse in places where the meaning is really about some measure(s) (amount) - not about a (price) tag...

[danbri]

@mfhepp - any view?

[mfhepp]

We had the following challenge: There are monerary amounts that are no prices. This could be seen solved by either a supertype for PriceSpecification or a subtype for QuantitativeValue. Both is problematic: From the type hierarchy, the former is cleaner, but the properties price, minPrice, maxPrice and priceCurrency do [truncated]

[danbri]

@mfhepp looks like your message got truncated somehow, could you finish the (interesting) thought?

[danbri]

Noting nearby vocabulary: http://schema.org/DatedMoneySpecification "A DatedMoneySpecification represents monetary values with optional start and end dates. For example, this could represent an employee's salary over a specific period of time."

Can we do something similar without the date? e.g. MonetaryAmount > DatedMonetaryAmount and rename DatedMoneySpecification ?

[Dataliberate]

I could see that MonetaryAmount would make an excellent and logical super-type to a (renamed from DatedMoneySpecification) DatedMonetaryAmount which adds the startDate & endDate.

[sopekmir]

Seems really great. I understand we would have:

Thing > Intangible > StructuredValue > MonetaryAmount > DatedMonetaryAmount

which even adds some better meaning to the term formerly names "DatedMoney..." through type hierarchy.

[mfhepp]

All:

Note that we will then have two branches of

*Thing > Intangible > StructuredValue > MonetaryAmount > DatedMonetaryAmount *
*Thing > Intangible > StructuredValue > MonetaryAmount > PriceSpecification *

In general, I think that the temporal aspect of a monetary amount should rather be modeled using properties of the type than a subtype. Alternatively, we could think about a generic mechanism for adding temporal meta-data to facts.

We could solve that as a quick fix by lifting validFrom and validThrough to MonetaryAmount and deprecate startDate and endDate and replace DatedMonetaryAmount by MonetaryAmount.

We will have to update the definitions of validFrom and validThrough then or at least double-check.

Martin

On 06 Apr 2016, at 17:30, sopekmir notifications@github.com wrote:

Seems really great. I understand we would have:

*Thing > Intangible > StructuredValue > MonetaryAmount > DatedMonetaryAmount *

which even adds some better meaning to the term formerly names "DatedMoney..." through type hierarchy.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub

[danbri]

"we could think about a generic mechanism for adding temporal meta-data to facts" ... that was how we ended up with the http://schema.org/Role design, and it has its uses but can be a bit too meta for mainstream understanding.

[Dataliberate]

Reading through the questions raised in relation to MonetaryAmount, its relationship to DatedMoneySpecification, PriceSpecification, other not obviously price based properties that have PriceSpecification in their range, and the names of its proposed properties; I have come to the following conclusions.

1. Although very similar in their structure, prices and monetary amounts are different in concept. Little would be gained, and as can be seen from this comment thread, confusion could be added by making them dependant on each other through sub typing.
2. As demonstrated by PriceSpecification, the temporal aspects of a price, or monetary amount can be satisfied without need of a ‘dated’ subtype by adding validFrom & validThrough. As the ranges of these two properties are extended their descriptions will need some attention.
3. The use of generic property names (amount, maxAmount,minAmount) in MonetaryAmount may cause confusion / conflict for future proposals. Also the use of amount as a property with a domain & range of MonetaryAmount in this case is unnecessarily recursive and thus confusing.

As a result of the above, I propose the following:

• Both MonetaryAmount and PriceSpecification become separate subtypes of StructuredValue but not of each other.
• The description of MonetaryAmount and PriceSpecification include wording to clarify the purpose:
  • MonetaryAmount: A monetary value or range. This type can be used to describe an amount of money such as $50 USD, or a range as in describing a bank account being suitable for a balance between £1,000 and £1,000,000 GBP, or the value of a salary, etc. It is recommended to use PriceSpecification Types to describe the price of an Offer, Invoice, etc.
  • PriceSpecification: A structured value representing a price or price range. Typically, only the subclasses of this type are used for markup. It is recommended to use MonetaryAmount to describe independent amounts of money such as a salary, credit card limits, etc.
• validFrom and validThrough have MonetaryAmount added to their domain. The description for validThrough is changed to “The date when the item is not valid. For example the end of an offer, salary period, or a period of opening hours.”
• amount: has MonetaryAmount removed from its range.
• New properties amountOfMoney, maxAmountOfMoney, minAmountOfMoney are created to replace amount, minAmount, minAmount in MonetaryAmount.
• DatedMoneySpecification is deprecated in favour of, or at least noted as being superseded by, MonetaryAmount.
• The following properties have MonetaryAmount added to their range: baseSalary, minimumPaymentDue, totalPaymentDue, netWorth. The intension being to remove PriceSpecification from their range either now or in a future release.

As a result of the above we would have:
Thing > Intangible > StructuredValue > MonetaryAmount
A monetary value or range. This type can be used to describe an amount of money such as $50 USD, or a range as in describing a bank account being suitable for a balance between £1,000 and £1,000,000 GBP, or the value of a salary, etc. It is recommended to use PriceSpecification Types to describe the price of an Offer, Invoice, etc.

• amountOfMoney Number The amount of money.
• currency Text The currency in which the monetary amount is expressed (in 3-letter ISO 4217 format).
• maxAmountOfMoney Number The highest amount of money if the amount is a range.
• minAmountOfMoney Number The lowest amount of money if the amount is a range.
• validFrom DateTime The date when the item becomes valid.
• validThrough DateTime The date until when the item is valid. For example when an offer ends, or end of a salary period, or period of opening hours.

Thing > Intangible > StructuredValue > PriceSpecification
A structured value representing a price or price range. Typically, only the subclasses of this type are used for markup. It is recommended to use MonetaryAmount to describe independent amounts of money such as salaries, credit card limits, etc.

Thing > Property > amount
The amount of money.

• rangeIncludes: Number, MonetaryAmount
• domainIncludes: InvestmentOrDeposit, LoanOrCredit, DatedMoneySpecification*
  • to be deprecated

[JimSaiya]

• validThrough DateTime The date when the item is not valid. For
  example the end of an offer, salary period, or a period of opening
  hours.

The term "Through" would imply that the item would still be valid on
(until the end of) DateTime. E.g., a credit card can be used
during the month/year printed on it.  The term "Until" would match
the definition given above better.

Jim Saiya
✉ jsaiya@formatdata.com
[in] www.linkedin.com/in/jimsaiya

[Dataliberate]

@JimSaiya I agree.
So it should be:

• validThrough DateTime The date until when the item is valid. For
  example when an offer ends, or end of a salary period, or period of opening
  hours.

(I have edited my original to reflect this)

[vickitardif]

Can we repurpose value, minValue, and maxValue instead of creating the new properties amountOfMoney, minAmountOfMoney, and maxAmountOfMoney?

[danbri]

Yeah thinking about it, I'd rather we made the generic vocabulary work if possible

[danbri]

@RichardWallis did note " Also the use of amount as a property with a domain & range of MonetaryAmount in this case is unnecessarily recursive and thus confusing." ... not sure what to do there.

[Dataliberate]

@vholland Extending the domain of value to include MonetaryAmount, instead of creating a new amountOfMoney property, was an option I considered. However already having StructuredValue in its range recreates a similar recursive situation that I was trying to avoid with amount.

Also the concept of value, in a financial sense, is somewhat broader than an individual amount of money. For example [at today's rates] $100 USD is the same value as €88 Euro.

[Dataliberate]

After due consideration we have followed @vholland's suggestion to use 'value' based properties for MonetaryAmount

[danbri]

Looking to merge the PR now...

[danbri]

Done. Please review! Also need a concise description of it...

[danbri]

http://webschemas.org/MonetaryAmount
Described at http://webschemas.org/docs/releases.html#g969

[sopekmir]

Dan,
How long is "concise" ?

I may try to do it today, based on the first post at #965 (by Richard) - I think Richard may be busy at San Diego FIBO conference, so I'm not sure if he could do it today.

[Dataliberate]

Concise description of what?

[danbri]

Oh, I did it already, see http://webschemas.org/docs/releases.html#g969

[danbri]

Closing per http://webschemas.org/docs/releases.html#g969 (although awaiting @mfhepp 's final review; can always re-open).