-
Notifications
You must be signed in to change notification settings - Fork 74
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
Conversation
…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>
There was a problem hiding this 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?
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! |
There was a problem hiding this 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 "BusinessDayConventionEnum"</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> |
There was a problem hiding this comment.
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 "BusinessDayConventionEnum"</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> |
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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 "BusinessDayConventionEnum"</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> |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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> |
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
…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: