It looks like the questions raised 21-May [1] have molded, so I'll start by pointing out those that I think are open:
1, Need to prioritize scenario [3], based on what I see in [2]. 2. Are any of the already prioritized scenarios intended to include "anything -other than-value- (data) of a given metric"? Where would you see the scenarios eliciting a requirement for the "metadata" about a metric? -- If so, need to render them more explicit. 3. do/should we have scenarios where a client needs a consistent understanding of those properties below, across multiple providers, and is able to provide implementation feedback on whatever we specify during *this iteration* ? -- unit of measurement: percent -- source token: percent_cpu_utilization -- inverse frequency: 20 4. Is one timestamp for the entire record sufficient? is anyone able to provide implementation feedback on whatever we specify during *this iteration* ? 5. I showed the "Turtle" as a very simple class instance with concrete properties, rather than as a collection of metric objects and a collection of values, since that's what most RDF looks like. Is anyone UNwilling to live with that? Do you need to see the equivalent alternative in order to have a real opinion? 6. I have the feeling that [3] is talking about different resource(s) than the other scenarios, e.g. about controlling an agent (which might/not be the implementation behind a PM SP), but I cannot be sure at this point. (more context in [1]). What is the intent in [3]? [1] http://open-services.net/pipermail/oslc-pm_open-services.net/2012-May/000014.html [2] http://open-services.net/bin/view/Main/PmScenariosV2 [3] http://open-services.net/bin/view/Main/PmAppMonitAdmin Best Regards, John Voice US 845-435-9470 BluePages Tivoli OSLC Lead - Show me the Scenario
