Add support for financial industry elements & integrate FIBO #969

Closed
mfhepp opened this Issue Jan 20, 2016 · 36 comments

Projects

None yet

6 participants

@mfhepp
Contributor
mfhepp commented Jan 20, 2016

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

@vholland
Contributor

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
Contributor

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
Contributor

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

@vholland
Contributor

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

@sopekmir
Contributor

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

@danbri
Contributor
danbri commented Jan 22, 2016

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

@Dataliberate
Contributor

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

@Dataliberate
Contributor

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
Contributor
danbri commented Mar 29, 2016

/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
Contributor

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
Contributor
danbri commented Mar 29, 2016

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:

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

@Dataliberate
Contributor

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

I agree it is worth considering.

@sopekmir
Contributor

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
Contributor
danbri commented Mar 29, 2016

@mfhepp - any view?

@mfhepp
Contributor
mfhepp commented Mar 30, 2016

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
Contributor
danbri commented Mar 31, 2016

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

@danbri
Contributor
danbri commented Apr 6, 2016

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
Contributor

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
Contributor
sopekmir commented Apr 6, 2016

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
Contributor
mfhepp commented Apr 6, 2016

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
Contributor
danbri commented Apr 12, 2016

"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
Contributor
Dataliberate commented Apr 13, 2016 edited

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
Contributor

@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)

@Dataliberate Dataliberate pushed a commit to MakoLab/schemaorg that referenced this issue Apr 19, 2016
@RichardWallis RichardWallis Applied changes to MonetaryAmount PriceSpecification and DatedMoneySp…
…ecification as per proposal schemaorg#969 (comment)
f5edf01
@vholland
Contributor

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

@danbri
Contributor
danbri commented Apr 19, 2016

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

@danbri
Contributor
danbri commented Apr 19, 2016

@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
Contributor

@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 Dataliberate pushed a commit to edmcouncil/schemaorg that referenced this issue Apr 19, 2016
@RichardWallis RichardWallis Applied changes to MonetaryAmount PriceSpecification and DatedMoneySp…
…ecification as per proposal:

schemaorg#969 (comment)
27117ca
@Dataliberate
Contributor

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

@danbri
Contributor
danbri commented Apr 20, 2016

Looking to merge the PR now...

@danbri
Contributor
danbri commented Apr 20, 2016

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

@sopekmir
Contributor

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
Contributor

Concise description of what?

@danbri
Contributor
danbri commented Apr 21, 2016
@danbri
Contributor
danbri commented Apr 28, 2016

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

@danbri danbri closed this Apr 28, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment