[Oslc-pm] Questions on spec draft/vocabulary

[John Arwe]

> I need some help finding units for PerMinute and Count.

For Count, I think you want unit:Unitless  ... qudt.org appears to have a 
bug in their Web page (lists unit:Unity), but it is Unitless in two other 
places including the vocabulary document itself.  I emailed them for 
clarification of the intent.

For PerMinute, I think they would say use PerSecond and convert the 
numeric quantity (first choice, preferred), or define your own 
pm:PerMinute ala PerSecond but with a different multiplier, i.e. 60 (using 
[1] as a template)

I think ultimately what we're going to want is to be explicit about how to 
map "what it is you're trying to represent" to the syntax for doing so. By 
which I mean a simple table very much like what you started in your email 
(former contents of the resource definition), where we list the 
predicate(s) as columns and each row is a metric.  Same principle as your 
new in-line example but without all the XML "obfuscation".  Want me to 
take a pass at that on a different page for now, just to avoid edit 
collisions on the spec?

> http://open-services.net/ns/perfmon#ResourceUsed
> How much of a resource is currently consumed
> 
> http://open-services.net/ns/perfmon#Rate
> The rate at which some resource is being consumed

That pair seems odd.  Rates and amounts differ in their units (amount/time 
vs amount) only I think, so I would have expected only ResourceUsed and 
then variation in units.

I might also call it Consumed instead of ResourceUsed, just a thought.

> http://open-services.net/ns/perfmon#ResourceExhausted
> Amount of time for which a resource has been exhausted
...
> http://open-services.net/ns/perfmon#TotalCPUAvailable ResourceAvailable

Not sure how to interpret this - my brain wants to connect them, but they 
might have been separate thoughts.
I can see the need for an "available" concept (as in the example above for 
CPU); we need to be careful to distinguish that concept from "total 
capacity" as used, for example, in capacity planning.

"Exhausted" I see maps back to the "thread pool maxed" metrics.  So this 
is a time that some condition was true ... other metrics in a given state 
(available=0, used=total capacity, or similar).  Are there similar cases 
with different state information (if so, we might want to split/compose 
again).  For example, if I'm thinking about managing a cache-like 
resource, "unused", or "hits below threshold" times might be relevant. 
Likewise it might be a time *since* some condition was true, depending(?) 
on the units.  Thinking out loud here, not making a concrete proposal.


>From [2], you show (first one)
<rdf:Description rdf:about="http://example.org/rec001">
    <rdf:type rdf:resource="http://open-services.net/ns/ems#Measure"/>
    <dcterms:title>
        Virtual Memory Utilization
    </dcterms:title>
    <ems:metric rdf:resource="
http://open-services.net/ns/perfmon#ResourceUsage"/>
    <ems:numericValue rdf:datatype="
http://www.w3.org/2001/XMLSchema#double">
        50
    </ems:numericValue>
    <pm:metricQualifier rdf:resource="
http://open-services.net/ns/perfmon#virtualmemory"/>
    <ems:unitOfMeasure rdf:resource="http://dbpedia.org/Percentage"/>
</rdf:Description>

I had envisioned splitting virtualmemory (this is why I suggested making 
pm:metricQualifier multi-valued), so there would be 2 values on this 
metric:
    <pm:metricQualifier rdf:resource="
http://open-services.net/ns/perfmon#virtual"/>
    <pm:metricQualifier rdf:resource="
http://open-services.net/ns/perfmon#memory"/>
My reasoning being that there are many "sub-types" of memory on some 
platforms beyond the simple virtual/real distinction; ditto disk storage, 
and CPUs.

> If we do end up following some path like metricQualifier, I would 
> recommend making it multivalued.  Then I could define qualifiers 
> like real, virtual, memory and combine them as needed rather than 
> having to enumerate each combination as a separate URI.  I'd have to
> go back to ems:metric's definition to see if that is in fact any 
> different.... maybe we just make ems:metric itself multivalued, 
> under the "less is more" principle. 

I do still have some research to do on the last point if we want to pursue 
that option.


[1] http://www.qudt.org/qudt/owl/1.0.0/unit/Instances.html#Kilowatt
[2] 
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/#Performance-Monitoring-Metrics

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/20121002/4d5774e5/attachment-0003.html>