[Oslc-pm] should ems:observes be required for PerformanceMonitoringRecords
John Arwe
johnarwe at us.ibm.com
Wed Oct 31 10:14:40 EDT 2012
I'm putting the vocabulary update in within the next few minutes.
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
From: Julianne Bielski/Raleigh/IBM
To: John Arwe/Poughkeepsie/IBM at IBMUS
Cc: oslc-pm at open-services.net, "Oslc-Pm"
<oslc-pm-bounces at open-services.net>
Date: 10/26/2012 04:25 PM
Subject: Re: [Oslc-pm] should ems:observes be required
for PerformanceMonitoringRecords
I made all of the updates below.
-- 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/25/2012 05:38 PM
Subject: Re: [Oslc-pm] should ems:observes be required
for PerformanceMonitoringRecords
Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
NB: the [text] is mine to clarify how I read it. If substantively wrong,
yell.
In the process of responding to point 1. below, I see that the
ems:observes description also lacks a bit of important boilerplate.
append, before the period, "(EMS)" with hyperlink to EMS's definition of
observes.
append, after the period, boilerplate:
The resource will typically be of type ems:Measure [hyperlink to [2]], but
it MAY be of any type (Core [hyperlink to [3]], Core Links [[hyperlink to
[4]]).
> 1. If a Resource is of rdf:type PMR [and] has an ems:observes predicate,
> then [its] ems:observes [predicate(s)] should reference a pm metric or
subclass of pm metric.
> How would we express this in the domain specification?
Strawman change to [1] description of ems:observes in resource definition
table:
append: When the resource is of type ems:Measure [hyperlink to [2]], that
resource should contain an ems:metric predicate whose object is of class
pm:Metric (either directly or indirectly).
Strawman change to vocabulary: add pm:Metric as a superclass of all the
currently defined PerfMon metric categories. Basically, insert it in the
hierarchy between ems:Metric and those existing categories. Its only
purpose is to make the statement above more compact by allowing it to use
a single URI (pm:Metric) instead of listing all the metric categories.
An alternative to defining pm:Metric would be to replace its use in the
strawman text above with "of any class defined by Perf Mon that is of
class ems:Metric", which even I find hard to understand.
We could also, informatively e.g. in the guidance, put in the text from 1.
and say that its guidance is simply an easier to read restatement of the
normative text describing ems:observes in [1]. Could also refer to
guidance from this text, or just say "In other words, ... (no caps)" which
readers should interpret as an informative re-statement of the preceding
(and for the pedantic, you can update the RFC 2119 front matter to render
that interpretation explicit if you like).
> 2. If Resource is of rdf:type PMR, the expectation is that it "has
> performance monitoring information",
The existing text at [2] (first few lines, above the table) I think say
exactly that right now, within the limits of prose's ambiguity. No
objection if we need to make editorial changes to the description to
clarify that intent.
> but the occurrence of
> ems:observes is zero-to-many
Strawman change to [1], Occurs column, of ems:observes in resource
definition table:
from: one-or-many
to: zero-or-many
> 3. If a resource has "some monitoring information", it should be of type
PMR.
> How would we express this in the domain specification?
Strawman: add to section [5]
Performance Monitoring service providers SHOULD expose resources of type
pm:PerformanceMonitoringRecord [2]. Performance Monitoring service
providers SHOULD include the type pm:PerformanceMonitoringRecord [2] on
all resources that contain performance monitoring information.
Note that my strawman is less general than yours. But since the Perf Mon
spec only governs Perf Mon providers, it's as wide as I think is
reasonable.
> If we go with this, then the implication for the ITM implementation
> of crtv:Process, foaf:Agent, crtv:Database, crtv:ResourcePool, and
> crtv:StorageVolume reources be of rdf:type
> PerformanceMonitoringRecord
Agreed that this would be the logical conclusion from the strawman changes
above.
> with an isPartOf predicate that
> references the same URI as the rdf:about URI.
For the specific types you cited, this would be a valid choice (perhaps
for other types too, I simply stopped thinking beyond this set). I see no
reason myself to prefer this choice over having some different value (in
ITM's example case, the computer system's URI could be used). I think the
spec currently leaves that choice up to implementations, and that seems
the right choice to me given that we know some implementations multi-type
but do not want to require all implementations to do so. In the CS case,
saying that a Process+PMR instance isPartOf the CS instance seems both
semantically reasonable and my sense is that it more accurately reflects
my understanding of the example and the ITM implementation.
If clients are likely to start from the CS and go exclusively top-down, or
if they have the entire set of resources in the same graph to reason about
(e.g. if they took your example CS response and loaded it into a Jena
model), it doesn't matter. If the CS and the Process had different URIs,
in particular ones that resulted in different HTTP Request-URIs, and
clients had some way to find Processes without going through computer
systems, and wanted to "move up the chain" starting at Process, then it
would matter. But that's not ITM's implementation, so it's not a useful
criterion on which to make this choice.
[1]
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/#Performance_Monitoring_Record
[2]
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/#Resource.3A-ems.3AMeasure
[3]
http://open-services.net/bin/view/Main/OslcCoreSpecification?sortcol=table;table=up#OSLC_Defined_Resources
[4]
http://open-services.net/bin/view/Main/OslcCoreSpecAppendixLinks?sortcol=table;up=#Don_t_make_assumptions_about_the
[5]
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/#Service-Provider-Resource
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/20121031/e2edad89/attachment-0003.html>
More information about the Oslc-Pm
mailing list