[gin-info] Possible list of subset data for info interop

[Jennifer M. Schopf]

Thomas-

    the goal of this group is low hanging fruit. to come up with a schema 
we all agree on is NOT low hanging fruit - it's months of work. This is not 
the place for that work. The GLUE schema list is likely to begin 
discussions of extensions soon, the OGSA-WG has said they'll look at GLUE 
schema/CIM mixes soon.  If you want to evaluate those topics, i suggest you 
check out these other efforts.

The goal of this group was low hanging fruit, minimal capability, using 
existing work.

The list, as you show it, is indeed worthless. However, if every resource 
advertises out it's own list grouped together it gives us the basic data we 
need to understand what a resource might look like in order to make 
extremely preliminary resource selection decisions. Look at what we've done 
for TG as an example, i think. It's minimal, but it's useful. A sample web 
page is here 
<http://snipurl.com/j24r>http<http://snipurl.com/j24r>://snipurl.com/j24r


  -j





At 16:17 02/03/2006, Dr. Thomas Soddemann wrote:
>Hi Jen,
>
>Jennifer M. Schopf wrote:
>>Thomas-
>>
>>    this group is NOT defining a schema.  This group is deciding on a 
>> minimal set of attributes for everyone to advertise in their native schemas.
>don't worry, I have not suggested to come up with a new schema.
>
>>We will not have an NxN mapping - we will have a mapping of N schemas 
>>into one list of attributes. This space is also small - I believe we have 
>>only 3 schemas for folks involved now, the GLUE schema, CIM, and what the 
>>nordu-grid guys have used, which should be close to the GLUE schema since 
>>it grew out of MDS2 originally.
>What is the value of the following attribute list?
>
>Queue name=small
>Queue name=large
>Queue name=huge
>GRAM version=4.0.1
>GRAM version=4.0.1
>GRAM version=3.9.5
>LRMS type=other
>LRMS type=SGE
>LRMS type=OpenPBS
>Total CPUs=128
>Total CPUs=64
>Total CPUs=2048
>Free CPUs=16
>Free CPUs=0
>Free CPUs=64
>Total Jobs=132
>Total Jobs=36
>Total Jobs=42
>Unique Id=1
>Unique Id=2
>Unique Id=4
>
>
>It is worthless, since one cannot know which data belong to the same 
>context/object (queue), unless one has some rule to structure the data. A 
>schema defines the attributes as well as their context. A schema rule 
>could e.g. be in the above case that every third position (0, 3, 6,...; 
>1,4,7,...; and 2,5,8,...) belongs to the same queue. Such a rules comes 
>along with a schema but not with the list of attributes.
>So we do need to agree on the structure the data are presented as well as 
>on the attributes our "objects" will have. And if we do not want to invent 
>another schema we should find a best match for our minimum set of 
>attributes we would like to see represented in such an existing schema.
>
>In your first sentence you say that "This group is deciding on a minimal 
>set of attributes for everyone to advertise in their native schemas."
>But exactly that leads to the n^2 problem. Everyone has to understand each 
>other's schema in order to correctly identify the attributes from the 
>minimum set.
>
>So what is so bad about the idea to use one schema as a kind of 
>master/interface schema and populate or use only the minimum set of 
>attributes we are going to agree on?
>
>Thomas
>


Dr. Jennifer M. Schopf
Scientist                              eInfrastructure Policy Advisor
Distributed Systems Lab       National eScience Centre and JISC
Argonne National Laboratory  The University of Edinburgh
jms at mcs.anl.gov                 jms at nesc.ac.uk
http://www.mcs.anl.gov/~jms http://homepages.nesc.ac.uk/~jms