[ur-wg] Thinking about the Usage Record

[Donal K. Fellows]

Hi everyone!

What with the cancellation of today's meeting, Matt Ford and I had a
little ad hoc meeting discussing the things that bothered us about the
specifcation as it currently stands. Now, we're coming from quite
different perspectives (despite working at the same site) so it was
interesting that there was quite a lot of agreement between us on ways
in which it would be nice if the UR spec&schema evolved. So here are
some notes based on my recollections of what we talked about:


There seems to be confusion about what is going on with the difference
between the UsageRecord element and the JobUsageRecord element. That
needs to be clarified/cleaned up.

Matt wants to be able to describe usage records for things other than
atomic computational jobs (especially storage).

The composition rules in the schema are waaaay complex! Probably too
complex.

Many UR parts are only meaningful to computational jobs, most of the
rest are generic.

Network bandwidth confuses both of us! A bad sign!

It would be nice to have composite usage records, but we don't need
aggregate URs. A composite should be a UR that has URs inside it, but
does not present any aggregate info other than in the most general sense
(e.g. "this is the global user identity associated with all this").
Anyone defining an aggregate might derive from this though.

We should decide whether we're going to go down the road of having a
type system or having highly specified elements. The first approach is
the one that seems to be favoured by the OGSA information modelling
crowd, and the second is what was eventually adopted by JSDL; I favour
the second I must admit, in part because it is easier to build a good
ontological model of everything then. Otherwise, you have to figure out
how to understand all the ways you can put all the pieces together, when
in fact some ways of doing stuff are meaningless. The second approach is
also a bit easier to validate in XML Schema (though perhaps a bit more
verbose).


So, proposal is to divide terms into generic and computational job
groups. Then define a parent UR type that just has the generic terms in
it, an extension of that which adds the computational job terms, and a
separate extension which does the composite/compound record (which might
be useful for talking about MPI jobs). Other extensions could be defined
in the future (and we'd set the WG up as the nexus for talking about
such extensions, in a manner similar to the JSDL-WG is going) but we
probably ought to limit ourselves for now. :-)

The computational job UR should probably be called POSIXActivtyUR to
link in with the vibe around JSDL and BES. That strikes me as being good
GGF politics. :-)

I've got some notes somewhere on how to make the schema obey all this
while tooling up sensibly.

Donal (I hope I remembered everything right...)