Hi Salvatore, Some comments: GPUs: PhysicalGPUs "The number of physical GPUs in one ExecutionEnvironment instance, i.e. the number of video cards per Worker Node." The description isn't great. My rule-of-thumb is to cross out information that is in the Attribute name and the Entity name. This leaves: "The number of [--] in one [--] instance, i.e. the number of video cards per Worker Node." The second part ("the number of video cards per Worker Node") is an example, rather than a definitive statement. My guess is that PhysicalGPUs should be described something like: "The theoretical maximum number of independent SIMD co-processors that any one job may access. Note that site policies may further limit the number of available SIMD co-processes." I'm also not sure why PhysicalGPUs would be useful, but GPGPU isn't really my thing. The LogicalGPUs has similar problems: the description doesn't contain much information and uses "i.e." when what follows is an example. Here's a possible alternative. "The number of independent SIMD co-processors that a job may access." For GPUVendor, GPUModel and GPUModel I suggest setting up a registry of known values. Having a "free format" text is a recipe for breaking interoperability --- at the very least, it forces users to profile GLUE. One obvious omission is the API. If my executable uses some particular API (CUDA, for example), how do I know it will work? SLAs GLUE provides reader-agnostic information: two people/agents can read the same GLUE information and deduce information correctly. If there are any user-specific information then it is expressed as UserDomain in an object linked from a UserDomain (such as the Policy entities). An SLA is a legally binding agreement between a service provider and the consumer(s). A service provider can provide different SLAs to different individuals, making SLA information user-specific. Therefore it should go in either the UserDomain (bad), in one of the existing Policy entities, or as a completely separate entity --- perhaps another subclass of Policy. Providing SLA as an optional String is also not great. Putting aside that an SLA is a multi-dimension thing, just writing down the availability (which is what the description hints at) is problematic: what is the format of this string? Do I write "0.9999", "99.99", "99.99%", "4 nines", "4x9", "max 1 hour total outage every year", ... ? Doing reasoning with this information is also pretty difficult. My suggestions are: 1. don't call it "SLA", but "availability" (or similar). Using "SLA" is asking for trouble. 2. put it in some Policy entity, not in the object itself. This provides the linkage with the user-community that enjoys this SLA. 3. either call the value a human-readable description of the policy, or provide a registry where people can record key-words against the corresponding semantics. The alternative is remove SLA complete and do this outside of GLUE. There are languages for handling SLAs; since GLUE provides persistent IDs for all objects, these SLA languages should be usable with the GLUE ID as the subject. Files vs Data objects Renaming files as objects (or "data objects"). I really don't see why you want to do this. It would be better to make sure people understand what the term "file" means, rather than simply renaming it. HTH, Paul.