Steven Newhouse wrote:
While it was not my intention to cause 'trouble' some of the responses to me seem to indicate very different architectures/implementations.
I don't currently have any specific architecture or implementation in mind. On this topic, I'm closer to being in the peanut gallery than usual. :-)
I think you need to firm up your models as to how you expect this activity schema to be stored, represented and accessed.
I suppose I'm currently thinking that, for a generalized Activity, there'll be information originating in a whole range of services and resources, and that there will be some model of aggregation. The info that represents the current state will be "out of date" (and so perhaps ought to be tagged with EPRs of services where you can go and ask for the most up-to-date version?[*]) but the historical info will (eventually) be accurate. Given that we're aggregating, we have to have a common structure/organization for how to gather the disparate subdocuments together. Which I think is the focus of what we're doing here, yes? Donal. [* I only just thought of this now; the idea's not been subject to any kind of deep thought, analysis or in-service testing! ]