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

[John Arwe]

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

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