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

[John Arwe]

> 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. 

What I was reacting (strongly) to was something that could easily be read 
to mean 
"because X has type Y it MUST have property Z" or 
"because X has property Z it MUST be of type Y"
**based on** the vocabulary definition (classes, properties, RDFS) alone.
Any such implications/expectations are in error.

The (any) **domain spec** is allowed to constrain the vocabulary that way 
if it chooses to.


> I wasn't saying they couldn't use 
> ems:observes in the RDF extensibility sense.

Violent agreement is a beautiful thing.

> ems:observes can be used for any ems:Measure instance, not just the 
> ones containing metrics in the PerfMon namespace. 

At the risk of being pedantic: ems:observes (like any predicate) can be 
used in any resource of any class unless (1) something like a domain spec 
prohibits it in that context and (2) the actor sending the resource 
asserts that it is compliant with the spec from (1).

> 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?

That would be a sensible requirement for the PerfMon domain spec to levy 
IMO.
So, to be precise, I think the requirement you're contemplating is:
if ems:observes -> ems:metric -> X , and X is a subclass of any 
pm:*Metrics class, and the ems:metric's subject is s, then another triple 
< s , rdf:type , pm:PerformanceMonitoringRecord > must exist.  It would 
then be silent on some other cases:

(1) ems:metric's object is a subclass of ems:Metric (so it skips the PM 
namespace and inherits from their common superclass)
(2) ems:metric's object is any other class

> 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?

Quibble: "multi-" is superfluous.

The scenarios should be the arbiter, although to be fair they are likely 
to be silent unless updated on the case where a PMR is served and it has 
zero ems:observes instances.  That's the kind of thing that 
implementations and their testers tend to hold more dearly than general 
specs.

Generically it seems to me that allowing zero hurts no clients, but it 
also provides no obvious increase in usefulness, so I personally have no 
grounds to strongly prefer or object to either 0 or 1 as a min occurrence 
constraint.  Min=1 seems to me very mildly preferable, in the sense that 
it's more likely to meet client expectations.

If you get a really powerful microscope out and read Core, you'll also see 
that domain specs (despite the use of MUST) are setting expectations not 
testable compliance constraints.  Implementations can "deviate" from 
"compliance" because neither concept is well-defined.  The strongest 
statement someone could validly make is that client expectations are 
violated when an implementation breaks a domain spec requirement, and 
hence you'll be more vulnerable to interop issues.

> How about the contraposition: if the resource does not contain an 
> ems:observes predicate, must it not be typed a PMR? Agree/Disagree? 

>From a strictly RDF level, neither triple implies the other.  They are 
simply orthogonal, and the resource owner should assert whichever 
semantics apply.

>From strictly a domain spec level, I'm not seeing any utility in 
prohibiting any form of re-use.  MUST NOTs are the bane of extensibility. 
But maybe there is utility and I'm not seeing it, so if there is a 
scenario where doing that works and not doing it breaks, by all means 
share.

> 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?

My answer would be "should, yes; must, no."  Because all pm:PMR says 
(semantically) is "the resource has some performance monitoring 
information".  It says nothing about where or how to find it.  That's why 
domain specs are useful, to tie together sets of vocabulary that address 
specific scenarios.

> We'd have to say "no", unless we relaxed the requirement on 
> requiring ems:observes in resources of type PMR, 

I think that is a non sequitir.  I would take the presence of any pm:* 
predicate as sufficient evidence that also asserting the subject's type as 
PMR would be semantically consistent.  Other predicates might also be 
consistent, so my statement is a min with no max.

> which I don't think
> would then address our scenarios. 

*If* the domain spec said that < s, rdf:type , pm:PMR > MUST NOT occur 
unless at least one < s , ems:observes , ?object > occurs, then I would 
agree that the domain spec may not cover the documented scenarios... and 
for that matter, if it did cover them I would suspect that the scenarios 
are overly constrained so I would expect that constraint to be loosened as 
new scenarios come into scope in future spec versions.

> 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?

They can do so, independent of anything currently in the perfmon domain 
spec.

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario

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