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

FND-280 #comment - loosens constraints on business day related proper… #896

Merged
merged 1 commit into from
Feb 27, 2020

Conversation

ElisaKendall
Copy link
Contributor

…ties to eliminate a reasoning bug, eliminates a duplicate individual that was not properly defined, and normalizes definitions to be ISO 704 compliant

Signed-off-by: Elisa Kendall ekendall@thematix.com

Description

This issue resolution loosens constraints on business day related properties to eliminate a reasoning bug, eliminates a duplicate individual that was not properly defined, and normalizes definitions to be ISO 704 compliant.

Fixes: #895 / FND-280

Checklist:

  • I'm familiar with the FIBO developer quide. My contribution meets all the requirements described there.
  • My contribution follows the principles of best practices for FIBO.
  • My changes have been reconciled with latest master and no merge conflicts remain.
  • This PR is related to exactly one issue. The issue is referenced by using a GitHub keyword such as "fixes", "closes", or "resolves".
  • Hygiene tests have been applied by a PR with "(WIP)" in title.
  • The issue has been tested locally using a reasoner (for ontology changes).

…ties to eliminate a reasoning bug, eliminates a duplicate individual that was not properly defined, and normalizes definitions to be ISO 704 compliant

Signed-off-by: Elisa Kendall <ekendall@thematix.com>
@trypuz trypuz added the FND FIBO Foundations label Feb 24, 2020
@trypuz trypuz added this to the 2020 Q1 FIBO Release milestone Feb 24, 2020
Copy link
Contributor

@dallemang dallemang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems really too bad, to remove those domains. Presumably, the error happens because you use the properties hasBusinessDayConvention or hasBusinessRecurrenceIntervalConvention on something that can't be a BusinessDayAdjustment or BusinessRecurrenceInterval respectively. But now, it is difficult to understand the intended use of these properties; if you can use them anywhere, it seems as if anything on earth could have such a Convention, including ridiculous things like NaturalPersons.

Is there a more appropriate general class that this domain could be, or could this be replaced wtih a couple of restrictions?

@ElisaKendall
Copy link
Contributor Author

Yes, there is the possibility of adding unions to constrain this better, but I'd rather pause on that until I've had more time to work with the examples and see what makes sense. What Mark had originally didn't work as he intended, though, and we ended up with logical inconsistencies in examples as a consequence.

I'll continue to work through this and then possibly raise another issue to further constrain their use. Thanks!

Copy link
Contributor

@rivettp rivettp left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this also changed a bunch of definitions unrelated to loosening the constraints this issue was about, I had to review those too. And several could use improving since they were not clear, and in one case actually wrong.

</owl:NamedIndividual>

<owl:NamedIndividual rdf:about="&fibo-fnd-dt-bd;BusinessDayModifiedFollowing">
<rdf:type rdf:resource="&fibo-fnd-dt-bd;BusinessDayConvention"/>
<rdfs:label>business day modified following</rdfs:label>
<sm:normativeReference>FPML 5.1 &quot;BusinessDayConventionEnum&quot;</sm:normativeReference>
<skos:definition>BusinessDayModifiedFollowing is a BusinessDayConvention that means a non-business date will be adjusted to the first following day that is a business day unless that day falls in the next calendar month, in which case that date will be the first preceding day that is a calendar date.</skos:definition>
<skos:definition>convention specifying that a non-business date will be adjusted to the first following day that is a business day unless that day falls in the next calendar month, in which case that date will be the first preceding day that is a calendar date</skos:definition>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the last use of "that date" presumably does not mean the one in the following calendar month. It would be better stated as "the adjusted date will be the first preceding...".

</owl:NamedIndividual>

<owl:NamedIndividual rdf:about="&fibo-fnd-dt-bd;BusinessDayModifiedPreceding">
<rdf:type rdf:resource="&fibo-fnd-dt-bd;BusinessDayConvention"/>
<rdfs:label>business day modified preceding</rdfs:label>
<sm:normativeReference>FPML 5.1 &quot;BusinessDayConventionEnum&quot;</sm:normativeReference>
<skos:definition>BusinessDayModifiedPreceding is a BusinessDayConvention that means that a non-business date will be adjusted to the first preceding day that is a business day unless that day falls in the previous month, in which case that date will be the first following day that is a business day.</skos:definition>
<skos:definition>convention specifying that a non-business date will be adjusted to the first preceding day that is a business day unless that day falls in the previous month, in which case that date will be the first following day that is a business day</skos:definition>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again the last "that date" would be better "the adjusted date"

</owl:NamedIndividual>

<owl:NamedIndividual rdf:about="&fibo-fnd-dt-bd;BusinessDayPreceding">
<rdf:type rdf:resource="&fibo-fnd-dt-bd;BusinessDayConvention"/>
<rdfs:label>business day preceding</rdfs:label>
<skos:definition>a BusinessDayConvention that means that a date will be adjusted to the first previous day that is a business day</skos:definition>
<skos:definition>convention specifying that a date will be adjusted to the first previous day that is a business day</skos:definition>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"first previous" could be taken as "earliest previous" which is not the intent. "latest previous" would be clearer

</owl:NamedIndividual>

<owl:NamedIndividual rdf:about="&fibo-fnd-dt-bd;BusinessDayNearest">
<rdf:type rdf:resource="&fibo-fnd-dt-bd;BusinessDayConvention"/>
<rdfs:label>business day nearest</rdfs:label>
<sm:normativeReference>FPML 5.1 &quot;BusinessDayConventionEnum&quot;</sm:normativeReference>
<skos:definition>BusinessDayNearest is a BusinessDayConvention that means that a non-business date will be adjusted to the nearest day that is a business day -- i.e. if the non-business day falls on any day other than a Sunday or a Monday, it will be the first preceding day that is a business day, and will be the first following business day if it falls on a Sunday or a Monday.</skos:definition>
<skos:definition>convention specifying that a non-business date will be adjusted to the nearest day that is a business day -- i.e. if the non-business day falls on any day other than a Sunday or a Monday, it will be the first preceding day that is a business day, and will be the first following business day if it falls on a Sunday or a Monday</skos:definition>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"first preceding" could be taken as "earliest preceding". "latest preceding would be clearer".
The algorithm is unnecessarily specific and wrong - in the case of the Saturday after Thanksgiving (assuming the Friday is not a business day) then the nearest business day will be the following Monday but the algorithm says the preceding Wednesday.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's address this under a new issue - I only normalized the definition, did not change the content.

</owl:Class>

<owl:Class rdf:about="&fibo-fnd-dt-bd;BusinessRecurrenceIntervalConvention">
<rdfs:subClassOf rdf:resource="&fibo-fnd-dt-bd;Convention"/>
<rdfs:label>business recurrence interval convention</rdfs:label>
<skos:definition>a convention for modeling recurring days, such as the end of the month, a particular day of the month, a day of the week, or more specifically, a t-bill auction date</skos:definition>
<skos:definition>convention that specifies how recurring days should be handled, such as the end of the month, a particular day of the month, a day of the week, or more specifically, a t-bill auction date</skos:definition>
Copy link
Contributor

@rivettp rivettp Feb 25, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see why t-bill auction is here, and it's very jurisdiction-specific. If it is so important (does it have its own named convention?) it should at least be cited as "US Treasury bills".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was there before - all I did was fix the definition. And there are t-bills referenced in the FpML that may not be limited to the US, including Australian t-bills ... although those could be Australian dollar but US t-bills.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
FND FIBO Foundations
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The business dates ontology includes properties whose domains are overly restricted
5 participants