fibo-fbc-fct-breg:hasEntityExpirationDate AND fibo-fnd-arr-doc:hasExpirationDate

[trypuz]

We have two properties in FIBO that relate entities to their expiration dates:

1. fibo-fbc-fct-breg:hasEntityExpirationDate (data property)
2. fibo-fnd-arr-doc:hasExpirationDate (object property)

I suggest we have one object property for the expiration date in FIBO; with general enough definition, e.g. "the date on which an entity ceased to exist".

[ElisaKendall]

@trypuz These are two very different things. The object property in arrangements is used to represent the expiration date of a contract, license, or other document, which may be a legal document, and as an important date, we have reified it. The expiration date for an entity in business registries was modeled to the GLEIF representation of an LEI entity expiration date explicitly. We could eliminate that one, but then would have to also ensure that the LEI representation isn't impaired, especially for anyone using already. There isn't an intervening reified date in the GLEIF mapping, in other words.

Let me talk with Pete Rivett about the GLEIF mapping to see what the impact would be.

[rivettp]

The meaning is quite different, I agree with @ElisaKendall . Contract expiration is a planned thing and is set in advance when the contract is created. So the definition proposed "ceased to exist" (in the past) is not appropriate. Entity expiration is not planned at all and is generally unexpected. "expiration" is probably not the best word to use for an entity ceasing to exist, but is consistent with GLEIF.

[trypuz]

I'm more concerned about the way we represent dates and link things to dates. I'd like to rather have all relations of this kind as specializations of fibo-fnd-dt-fd:hasDate.

[trypuz]

BTW, I do not think any complete mapping between FIBO and GLEIF ontology exists beyond Pete's mind.

[ElisaKendall]

@trypuz - there are a few more that I think we should add that have this style, that I noticed while doing mappings for WF. I'll use this issue to add a couple of additional reified dates and related properties as subproperties of hasDate / hasExplicitDate, based on that work and what I perceive the need to be for AML/KYC. Then we should probably do an exhaustive search for these kinds of datatype properties and decide what makes sense, rather than addressing them on a one-off basis?

[ElisaKendall]

@trypuz - I can do a search for these and see what makes sense with respect to the LEI content, since we have lots of example individuals that use the FIBO LEI mapping, but I'm not sure about which properties for dates the examples use. I do recall some issues / mismatched representation I had to address for that to create the individuals, though.

[jfgemski]

I don’t think you’ll find too many generic dates. Most dates only make sense in the context in which they’re used and have slightly different definitions based on their context. John <mailto:[email protected]> [email protected] | H: +1 (516) 826-0701 | M: +1 (516) 353-0004 From: Elisa Kendall <[email protected]> Sent: Tuesday, November 17, 2020 12:57 PM To: edmcouncil/fibo <[email protected]> Cc: Subscribed <[email protected]> Subject: Re: [edmcouncil/fibo] fibo-fbc-fct-breg:hasEntityExpirationDate AND fibo-fnd-arr-doc:hasExpirationDate (#1222) @trypuz <https://github.com/trypuz> - there are a few more that I think we should add that have this style, that I noticed while doing mappings for WF. I'll use this issue to add a couple of additional reified dates and related properties as subproperties of hasDate / hasExplicitDate, based on that work and what I perceive the need to be for AML/KYC. Then we should probably do an exhaustive search for these kinds of datatype properties and decide what makes sense, rather than addressing them on a one-off basis? — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1222 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGJ22MZZSQMXWGYZWWIS3SQK2PLANCNFSM4TY2ZA6Q> . <https://github.com/notifications/beacon/ACNGJ22DIIV4AONL6KSSRFDSQK2PLA5CNFSM4TY2ZA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFN2S4VQ.gif>

[ElisaKendall]

@jfgemski - The explicit dates I would like to add include EffectiveDate, ExpirationDate, TerminationDate, DateOfBirth, and DateOfDeath - we have properties for some of these, but these are quite common and are needed for various kinds of contracts, for AML with respect to people, etc. I wasn't thinking of anything beyond this, but having these as subclasses of ExplicitDate would be quite useful.

[jfgemski]

Here are a few others you should consider: Julian Date Gregorian Date As-Of Date* Value Date* Period Start Date Period End Date Report Date Current Date Previous Date Next Date The two * items should really be date/time fields. Don’t know if that makes a difference in an ontology. John <mailto:[email protected]> [email protected] | H: +1 (516) 826-0701 | M: +1 (516) 353-0004 From: Elisa Kendall <[email protected]> Sent: Tuesday, November 17, 2020 3:06 PM To: edmcouncil/fibo <[email protected]> Cc: John Gemski <[email protected]>; Mention <[email protected]> Subject: Re: [edmcouncil/fibo] fibo-fbc-fct-breg:hasEntityExpirationDate AND fibo-fnd-arr-doc:hasExpirationDate (#1222) @jfgemski <https://github.com/jfgemski> - The explicit dates I would like to add include EffectiveDate, ExpirationDate, TerminationDate, DateOfBirth, and DateOfDeath - we have properties for some of these, but these are quite common and are needed for various kinds of contracts, for AML with respect to people, etc. I wasn't thinking of anything beyond this, but having these as subclasses of ExplicitDate would be quite useful. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1222 (comment)> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNGJ27Z3TPIKSGGYI55TCDSQLJT3ANCNFSM4TY2ZA6Q> . <https://github.com/notifications/beacon/ACNGJ2534SMOY5BJTUDGXW3SQLJT3A5CNFSM4TY2ZA62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOFN3EKKQ.gif>

[ElisaKendall]

Thanks, John - this is helpful. We already have some of these, but I'll take a look and see what makes sense to include.

[rivettp]

@trypuz I feel compelled to respond to your to your comment "BTW, I do not think any complete mapping between FIBO and GLEIF ontology exists beyond Pete's mind.".
A week or two ago I did send @ElisaKendall and walk her through a mapping ontology between the GLEIF and FIBO ontologies which is c. 90% complete and is valid with respect to reasoners. The incompleteness is caused by gaps: after that discussion I'm going to be raising some issues on FIBO to address those gaps.

[trypuz]

The meaning is quite different, I agree with @ElisaKendall . Contract expiration is a planned thing and is set in advance when the contract is created. So the definition proposed "ceased to exist" (in the past) is not appropriate. Entity expiration is not planned at all and is generally unexpected. "expiration" is probably not the best word to use for an entity ceasing to exist, but is consistent with GLEIF.

@rivettp, the definition I proposed was just an example. We could have a definition like "links an entity with an expiration date" that is fairly general but unfortunately conveys little meaning.

[ElisaKendall]

@trypuz I think I can do better, and as I mentioned, I need to create several explicit dates to clean some things up with respect to contracts as well as for people (in part for AML but also to deal with alignment issues I'm having in a client application).

It may be a day or two before I push something out, but I'll try to get to it in the next couple of days to cover the dates I believe we need explicit representation for, with the properties revised to reflect those changes. That won't address the data property in FBC, however, which I don't want to touch until Pete and I work through the mapping he has been doing and I have a more complete set of changes to incorporate.

[rivettp]

@trypuz regardless of what we do with the definition wording I think there's a semantic difference between an expiration date on a contract which is a scheduled thing, often in the future, and the unplanned date an organization goes out of business. And both different, I believe, from the date a person dies.

That said, I agree with your inclination to use properties rather than classes for this.
And for pragmatic purposes - specifically the ability to use SPARQL comparison operators to check if one ate is earlier than another for example - it's important to use xsd:dateTime for values.

[rivettp]

@trypuz for general properties such as hasDate we should have use cases that justify them, since they do have an overhead in reasoners. And have a negative impact on modularity - since they end up pulling in many other ontologies for (probably) no added value (e.g. no restrictions).
One potential usecase might be to create a calendar for an organization or contract depicting all dates in its history. But is that of any use to anyone using FIBO? Any other justification?

In contrast I can see no such potential justification for properties such as "has" which have no useful semantics and are inconsistently subPropertied.

Conversely I don't see a justification being the desire to organize properties in a hierarchy in primitive tooling like Protege, with no associated semantics.