Why are TimeSeries objects reported with head "TemporalData"?

Question

Related Problem: What does it mean to be an object in Mathematica?

I am quite surprised to find that

ts = TimeSeries[ {1,2,3,4}, {{1,2,3,4}}];
Head @ ts

returns

(* TemporalData *)

I do find this quite inconsistent as the object is also reported with TimeSeries[...] when it is generated. I would find it much more sensible to have TemporalData-functions also accept TimeSeries objects but still have them as special instances with a "Head" of their own.

More formally: If TimeSeriesis a constructor then it should generate a TemporalDataobject and I should not see TimeSeries[...] at all after applying the function. On the other hand if it is a data type of its own then it should have its own head.

Am I missing something here? (e.g. are there good reasons for this behavior or can it be avoided)

Answer 1

First Analysis

The official (first answer) from the technical support at Wolfram Research states that:

This seems consistent with the overall design of Mathematica where the head of an object that is a special case of some larger class generally has the head of the larger class (e.g. plots generally have the head Graphics).

[...] this may have some implications for bijectivity/invertibility [but should not be a problem] since most things in this area should have the head TemporalData.

While I agree that the problem seems limited it imho still is a design question which may be interesting in general since more and more we are talking about objects in Mathematica where there used to be atoms and normal expressions only.

I do not quite follow the logic with regard to the Plot example:

g = Plot[x^2, {x,-2,2}];
Head @ g

(* Graphics *)

will give the more general head indeed but here we are talking about a constructor. (Please correct me since my knowledge about computer science stems from reading Roman Maeder's Computer Science with Mathematica ). And naturally we are interested in the information of the object (data type) that has been constructed.

Quite in accordance here we never again see reference to the constructor again:

(OwnValues @ g)[[1,2]]
(* shows a Graphics object *)

Also using FullForm @ g will show that there is not a trace left indicating the Graphics-Object to be a special case 'Plot' (rather than say a BarChart).

This is different for TimeSeries:

While at first the analogy holds

ts = TimeSeries[ {1,2,3,4}, {{ 1,2,3,4 }} ];
Head @ ts

(* TemporalData *)

It is different further down the road:

(OwnValues @ ts)[[1,2]]
(* shows TimeSeries[ ... ] *)

and referencing FullForm @ ts clearly shows that we are talking about a TemporalData object of subclass (?) TimeSeries, since

(FullForm @ ts)[[1,1]]
(* TimeSeries *)

Note: As has been indicated by Andy Ross, the undocumented ts["ObjectType"] will serve as a TimeSeriesQ function.

But here again I do get the impression that deeper design changes are at work:

expr = h[ e1, e2, e3, e4 ]; expr[[1]]

(* e1 *)

Compare this Mathematica 1.0.1 -like behavior to:

f = FullForm @ ts

(* TemporalData[TimeSeries, List[ ... ], False, 10.'] *)   

which surprises when asked about its first part:

f[[1]]

(* returns more than simple *TimeSeries* , e.g. full information about 
number of data and times *)

So it seems that object is not equal to object?

Proposal for further releases

I am not computer scientist enough to follow through the design implications at hand here but while I understood the Mathematica-design described by Roman Maeder I am struggling with some design changes in the latest releases of Mathematica.

Possible Route 1

Everything is kept as is but the documentation is at least made a bit more enlightening and maybe a TimeSeriesQ and EventSeriesQ is implemented for special instances.

Possible Route 2

TimeSeries is seen as a mere constructor and thus a (special case) of 'TemporalData[...]' is reported as the result (analog to Plot and the like for Graphics). Thus OwnValues would not show TimeSeries but TemporalData.

Possible Route 3 (is there one?)

Thinking and reading up about classes and subclasses I believe that subclasses extend classes they are special cases of but are referenced as a class in their own right. Maybe (using upvalues in Mma) one wants to tie separate methods to a TimeSeries - object while at the same time allowing for use of TimeSeries objects whenever a TemporalData object is asked for (e.g. f[td_TemporalData] might also accept a TimeSeries).

So this would mean leaving TimeSeries[...] as a FullForm Representation while changing the interpretation of Head (?) with regard to objects?

Conclusion

Not being savvy enough in this regard (but nontheless interested) I would see the first proposal as a minimal solution (for clarity) while prefering the 2nd route.