Fred Maciel wrote:

First of all, sorry for the cross-posting -- this subject involves all three WGs. Since GGF14 there have been a lot of discussions on where resource modeling fits -- BES considered it out of scope but Andrew thinks it's not totally out; RSS is discussing whether it's in scope; and this was discussed in the OGSA-WG also. So, let's discuss this in the Resource Modeling design team teleconference (which is, in fact, the place to discuss this).

Alas, the timing of the telecon is consistently impossible for me for family reasons, and I'm pretty certain that Soonwook Hwang can't make them either. (I'm not sure about Mathias Dalheimer.) However, so far we've discussed this within the RSS group by email and I think we feel that from the point-of-view of the RSS, we will not be saying very much at this stage. We do not wish to say that services should not use legacy information resource systems/models, and indeed feel that it is actually going to be the case that the RSS (in particular, the Candidate Set Generator) will sit at the boundary between the resource-oriented information domain and the request- oriented information domain (with the RSS focus being more on the latter I believe). In terms of general requirements on an information model, any implementation of a CSG will need to have access to sufficient data on the configuration of a resource in order to know whether a job described in JSDL will be able to run there. However, the information does not need to be so specific that the job must always be associated with exactly one configuration; our experience with existing systems indicates that it is easier to satisfy users' higher-level constraints (e.g. on co-scheduing or pricing) when greater flexibility is present at the lower levels. Things get more interesting when you start to have information models that contain higher-level policy descriptions. But I don't have all that much useful input on that yet. :^) This is something that we're going to have to do a use-case search on before proceeding with at that level of detail. Donal Fellows.