Additional virtual properties not accessible terribly easily

[Deleted user]

From Chris B:

"we also add the ability to append functions/methods etc after the properties as well (e.g. PriceOfferClose.VOLATILITY()). I'm guessing that this is something that F# would naturally allow too based on the library of registered objects/functions etc that are registered within it?

Opening up our library of functions to F# (in addition to data as you have done here) would have benefits too in that it would allow any function registered with TimeScape to be used within F# expressions (so external pricing libraries, custom XLL's etc) without any integration coding (i.e. no need to create another F# provider for each one) - in that sense, TimeScape is acting as an 'analytic provider' to F# rather than a data one.

One other consideration (data-wise) is that there are some cases in our database model where properties can exist on an item that are not defined in the schema. We call these "virtual series" and (currently) they apply to data series which are calculated on the fly bases on other items associated with a given item.

For example, an Index is the weighted sum of a collection of equity prices (with a divisor thrown in). If the equities have a 'Close' price, then it is possible to ask the question:

ITEM(...'S&P Index'...).Close

which will calculate the 'Close' for the index based on the index composition. In this case, the Close series is not defined in the schema but is implied from the fact that the category 'Index' is of a certain type (a basket) and that one or more of the underlying equity items in that basket have data for property 'Close'. Given that any object might support 'virtual series / properties', then we support the operator P? within queries to allow you to get a sense of what data/operations are (potentially) available to be used at a given point in an expression. This might also be something worth looking into down the line in terms of how that might fit?"