Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for financial industry elements & integrate FIBO #969

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

Add support for financial industry elements & integrate FIBO #969

mfhepp opened this issue Jan 20, 2016 · 36 comments

Comments

@mfhepp
Copy link
Contributor

@mfhepp 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
Copy link
Contributor

@vholland vholland commented Jan 20, 2016

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
Copy link
Contributor

@Dataliberate Dataliberate commented Jan 21, 2016

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
Copy link
Contributor

@Dataliberate Dataliberate commented Jan 21, 2016

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

@vholland
Copy link
Contributor

@vholland vholland commented Jan 22, 2016

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

@sopekmir
Copy link
Contributor

@sopekmir sopekmir commented Jan 22, 2016

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

@danbri
Copy link
Contributor

@danbri danbri commented Jan 22, 2016

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

@Dataliberate
Copy link
Contributor

@Dataliberate Dataliberate commented Jan 27, 2016

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

@Dataliberate
Copy link
Contributor

@Dataliberate Dataliberate commented Mar 24, 2016

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
Copy link
Contributor

@danbri 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
Copy link
Contributor

@Dataliberate Dataliberate commented Mar 29, 2016

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
Copy link
Contributor

@danbri 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
Copy link
Contributor

@Dataliberate Dataliberate commented Mar 29, 2016

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

I agree it is worth considering.

@sopekmir
Copy link
Contributor

@sopekmir sopekmir commented Mar 29, 2016

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
Copy link
Contributor

@danbri danbri commented Mar 29, 2016

@mfhepp - any view?

@mfhepp
Copy link
Contributor Author

@mfhepp 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
Copy link
Contributor

@danbri danbri commented Mar 31, 2016

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

@danbri
Copy link
Contributor

@danbri 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
Copy link
Contributor

@Dataliberate Dataliberate commented Apr 6, 2016

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
Copy link
Contributor

@sopekmir 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
Copy link
Contributor Author

@mfhepp 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
Copy link
Contributor

@danbri 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
Copy link
Contributor

@Dataliberate Dataliberate commented Apr 13, 2016

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
Copy link

@JimSaiya JimSaiya commented Apr 13, 2016

  • 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
Copy link
Contributor

@Dataliberate Dataliberate commented Apr 13, 2016

@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 pushed a commit to MakoLab/schemaorg that referenced this issue Apr 19, 2016
@vholland
Copy link
Contributor

@vholland vholland commented Apr 19, 2016

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

@danbri
Copy link
Contributor

@danbri danbri commented Apr 19, 2016

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

@danbri
Copy link
Contributor

@danbri 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
Copy link
Contributor

@Dataliberate Dataliberate commented Apr 19, 2016

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

@Dataliberate Dataliberate commented Apr 20, 2016

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

@danbri
Copy link
Contributor

@danbri danbri commented Apr 20, 2016

Looking to merge the PR now...

@danbri
Copy link
Contributor

@danbri danbri commented Apr 20, 2016

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

@sopekmir
Copy link
Contributor

@sopekmir sopekmir commented Apr 20, 2016

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
Copy link
Contributor

@Dataliberate Dataliberate commented Apr 20, 2016

Concise description of what?

@danbri
Copy link
Contributor

@danbri danbri commented Apr 21, 2016

@danbri
Copy link
Contributor

@danbri danbri commented Apr 28, 2016

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.