Quoting Rosario Michael Piro
I think a usage record should be explicitly declared to be aggregate (how should be discussed), otherwise we would easily undermine all standardization efforts. How does for example an arbitrary implementation of the Resource Usage Service (RUS), that uses the UR, realize that your UR is meant to be aggregate. It would most probably (and usually should) interpret the StartTime as the start time of job execution and the End Time as stop time of job execution of a single job. It wouldn't understand urwg:description="accountperiod" as modifier of the meaning of Start and EndTime.
So, my point here, is that section 10 of the spec defines StartTime, Endtime, and CPUDuration as relating to Usage *not* job. The descriptor is used to attach meaning but it's not actually necessary, it's essentially a free element. Without the descriptor field the aggregate example is still valid. I guess the issue is that the current section 10 defs allow this; I think deliberately. For example the CPUDuration field can be used in a number of circumstances: aggregate info is one of them, time on a batch system another, cputime spent copying files may be yet another. If we do move these fields into seperate sub-elements or specific "Job" types (which I'm in favour off) then we have to be very careful. Anyone using the schema as I think original intended will have to made aware of these significant changes. I'd love to understand from the original authors if this is actually how they envisaged its use.
Of course you might customize the behaviour of your RUS (or whatever service you use for accounting), but that would make it a non-standard solution.
But I agree that an aggregate format would be most useful. If it will not be defined by the UR-WG then most probably most Grid environments/projects will define their own aggregate format. This as well would risk to undermine the standardization efforts.
Before declaring an aggregate UR out of scope, we should at least start (via the mailing list) a discussion on what would be necessary (new elements? Or simply an additional attribute 'urwg:scope="aggregate"' to some of the elements? To which? Allow multiple job IDs for aggregate URs? etc.
But I think this would be a longer process and wouldn't lead to quick results. The improvement of the current UR for single jobs will (and should) have the priority I guess.
Cheers,
Rosario.
Matt.
-- ------------------------------------- Rosario Piro (piro@to.infn.it) http://www.to.infn.it/~piro/ ------------------------------------- Istituto Nazionale di Fisica Nucleare Sezione di Torino ------------------------------------- National Insitute for Nuclear Physics Section of Turin, Italy -------------------------------------