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

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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jan 20, 2016

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

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Jan 21, 2016

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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Jan 21, 2016

Contributor

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

Contributor

Dataliberate commented Jan 21, 2016

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

@vholland

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Jan 22, 2016

Contributor

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

Contributor

vholland commented Jan 22, 2016

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

@sopekmir

This comment has been minimized.

Show comment
Hide comment
@sopekmir

sopekmir Jan 22, 2016

Contributor

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

Contributor

sopekmir commented Jan 22, 2016

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Jan 22, 2016

Contributor

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

Contributor

danbri commented Jan 22, 2016

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

@Dataliberate

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Jan 27, 2016

Contributor

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

Contributor

Dataliberate commented Jan 27, 2016

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

@Dataliberate

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Mar 24, 2016

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Mar 29, 2016

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Mar 29, 2016

Contributor

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

I agree it is worth considering.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sopekmir

sopekmir Mar 29, 2016

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...

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 29, 2016

Contributor

@mfhepp - any view?

Contributor

danbri commented Mar 29, 2016

@mfhepp - any view?

@mfhepp

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Mar 30, 2016

Contributor

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]

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Mar 31, 2016

Contributor

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

Contributor

danbri commented Mar 31, 2016

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 6, 2016

Contributor

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 ?

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 6, 2016

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@sopekmir

sopekmir Apr 6, 2016

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@mfhepp

mfhepp Apr 6, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 12, 2016

Contributor

"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.

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 13, 2016

Contributor

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
Contributor

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

This comment has been minimized.

Show comment
Hide comment
@JimSaiya

JimSaiya 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

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 13, 2016

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)

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@vholland

vholland Apr 19, 2016

Contributor

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

Contributor

vholland commented Apr 19, 2016

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 19, 2016

Contributor

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

Contributor

danbri commented Apr 19, 2016

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 19, 2016

Contributor

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

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 19, 2016

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.

Contributor

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 pushed a commit to edmcouncil/schemaorg that referenced this issue Apr 19, 2016

@Dataliberate

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 20, 2016

Contributor

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

Contributor

Dataliberate commented Apr 20, 2016

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 20, 2016

Contributor

Looking to merge the PR now...

Contributor

danbri commented Apr 20, 2016

Looking to merge the PR now...

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 20, 2016

Contributor

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

Contributor

danbri commented Apr 20, 2016

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

@danbri

This comment has been minimized.

Show comment
Hide comment
@sopekmir

This comment has been minimized.

Show comment
Hide comment
@sopekmir

sopekmir Apr 20, 2016

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@Dataliberate

Dataliberate Apr 20, 2016

Contributor

Concise description of what?

Contributor

Dataliberate commented Apr 20, 2016

Concise description of what?

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 21, 2016

Contributor
Contributor

danbri commented Apr 21, 2016

@danbri

This comment has been minimized.

Show comment
Hide comment
@danbri

danbri Apr 28, 2016

Contributor

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment