Page Comparison

...

FND 235 - proposal from EK to add a datatype and property to the dates ontology

...

https://wiki.edmcouncil.org/display/FND/Actions

EK - reusing hte the same existing datatype (union of dateTime, dateTimestamp or string) - problem using the current structure with multiple restrictions.  Proposing a composite date value in cermstances circumstances where comparisons are important

EK - new patters pattern is for specific purposes (for efficiency) purposes - when challenges exist for mapping (one of hte the three data types don't work)

TradeDate and SettlementDate (i.e. when optionality is needed) is the driver of the composite date

Varying registation registration dates - another example

PR - not keen on "name" (composite date and value might not be appropriate)

...

FND group is in agreement on the value of the property hasReleaseDateTime

 - but not with that name, and it must have some semantics e.g. a domain. Not simply a property for every possible reference to that datatype. 

JG - would like two date representation representations (release date and event date - including time zone)

...

JG - look at the problem from teh the perspective of the business user who is evaluating FIBO from the CONCEPTS that they care about.  Not only about how it might be implemented - must also include the concept

...

MG - "offset" is inadequate for any future event

MB adds: surely future events are an ‘occurrence kind’ rather than an ‘occurrence’ – even if they have a calendar date it has not happened yet. EK concurs.

EK - recognizes MG issue is important (unclear on how to address) - request examples for evaluation of options

EK - back to notion of "composite" - this could handle event dates (raise two issues (1) for nano-seconds (2) time zone challenge - do we need two datatypes to implement?)

MB to raise JIRA issue on event dates

...

John Gemski: Here's the problem.  NYC is normally -5 UTC.  For 2 weeks every year the US goes to DST 2 weeks before Europe.  So for that 2 week period the time difference is -4 UTC and then it goes back to -5 UTC when Europe goes to DST.  Problem is there's no conformity when time zones change between DST and standard time.

MB adds: there is an ontological distinction between a point in time in and of itself, and 'the time in (some city)'.

Jeff Braswell: What if an Occurrence is something that occurs over a range of dates and time?

EK still sees value in keeping the property hiererchy hierarchy for composite date (for rollup) as long as domain and range can be expressed

...

Jeff Braswell: debt instruments are also transferable, as are other contracts

Slides

Here are the slides: 

(I re-did the Contracts diagram to captre all the existing relationships between things that are on the page. I also added the remaining sub classes of Financial Instrument, for completeness)

Decisions:

Action items

•  Mike Bennett Raise 2 new JIRAs, for date/time that includes nanoseconds, and for the ability to deal with tome zone differences.