[Oslc-pm] should ems:observes be required for PerformanceMonitoringRecords

[Julianne Bielski]

I agree with you, but the reason I wrote what I wrote was b/c I was 
pointing out that ITM's Process and StorageVolume resources have no 
relationship to PMRs at the moment even though they have ems:observes 
properties. I wasn't saying they couldn't use ems:observes in the RDF 
extensibility sense.

ems:observes can be used for any ems:Measure instance, not just the ones 
containing metrics in the PerfMon namespace. In our scenarios, consumers 
are specifically looking for performance-related metrics, so I assert that 
if ems:observes refers to the measurement of a PM metric, the observed 
resource should either be multi-typed as a PMR or there must be a PMR 
instance whose isPartOf predicate refers to the resource. This then 
implies that the ITM provider's payloads for Processes and StorageVolumes 
should be multi-typed as PMRs. Agree/Disagree?

The next question is about the converse: if the resource is multi-typed as 
a PMR, must it contain an ems:observes predicate that points to a perfmon 
metric? I say yes going back to the scenarios again as my premise. This 
then implies that the ITM implementation either add ems:observes to the CS 
resource with a pm metric (overall CPU and memory utilization come to 
mind), or we stop typing it as a PMR. Agree/Disagree?

How about the contraposition: if the resource does not contain an 
ems:observes predicate, must it not be typed a PMR? Agree/Disagree? This 
is Janet's question (she actually said 'can it be typed a PMR') and I 
would like the workgroup's input on this.

For example, if a resource is using a predicate in the perfmon namespace, 
but the predicate is not ems:observes, but some other value interesting to 
a a monitoring consumer (e.g. pm:mobilityEnabled, 
pm:tableReorganizationNeeded,pm:AvailabilityStatus), should it also or can 
it also be a PMR instance?

We'd have to say "no", unless we relaxed the requirement on requiring 
ems:observes in resources of type PMR, which I don't think would then 
address our scenarios. The providers using these non-ems:observes 
predicates could use resource shapes to advertise the usage of the 'pm' 
predicates to interested consumers. Agree/Disagree?

-- Regards,

Julianne Bielski, STSM
ITM Core Chief Architect
Tivoli, IBM Software Group
tel: (919) 224-1170      (T/L) 687-1170
e-mail: bielsk at us.ibm.com

"All growth is a leap in the dark, a spontaneous unpremeditated act 
without benefit of experience." — Henry Miller



From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     oslc-pm at open-services.net, 
Date:   10/24/2012 05:48 PM
Subject:        Re: [Oslc-pm] should ems:observes be required   for 
PerformanceMonitoringRecords
Sent by:        "Oslc-Pm" <oslc-pm-bounces at open-services.net>



> ... and other 
> resources with ems:observes predicates and no rdf:type 
> PerformanceMonitoringRecord. 

That is absolutely encouraged.  As originally promulgated, the EMS spec 
had (+continues to have) resource definitions where ems:observes was used 
in exactly this way.  If EMS had added the equivalent constraint to what 
the excerpt above might suggest is needed, Perf Mon would have been UNable 
to re-use the ems vocabulary. 
This is RDF where to the best of our ability we try to give a concept one 
identifier in a vocabulary (ems:observes means the object contains some 
kind of observed information) and *re-use* that same vocabulary in as many 
contexts as it is relevant to.  Each specification is one such context, 
and may layer on additional constraints (like occurrences) appropriate to 
the scenarios that comprise the context.  Hence you "always" have at least 
one spec for a vocabulary term (that is our minimalist practice, not a 
Requirement From Above).  It does not imply that vocabulary == 
specification/domain, however. 
If you want a system where wide, serendipitous, uncoordinated vocabulary 
re-use is discouraged, we have 20 years of OO systems waiting to be used 
and lots of people happy to use them.  It's just a different world-view, 
each appropriate to some set of problems and constraints.  Don't get 
tangled up in that thinking in RDF, those constraints are not there by 
default and they generally inhibit re-use. 
Best Regards, John

Voice US 845-435-9470  BluePages 
Tivoli OSLC Lead - Show me the Scenario 
_______________________________________________
Oslc-Pm mailing list
Oslc-Pm at open-services.net
http://open-services.net/mailman/listinfo/oslc-pm_open-services.net


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20121025/adba5a77/attachment-0003.html>