[Oslc-pm] strawman + questions for resource definitions

[John Arwe]

I have some ideas floating around in my head that I'm going to take a pass 
at laying out below.   
1: Monitoring SP = collection of monitoring records, one per monitored 
resource (perhaps, ...per agent on the resource), for the "latest 
observation" view 
2: Monitoring SP = collection of metric definitions per monitored resource 
(...same perhaps...), for the "metadata/admin view".  If the metric's 
property is updatable, then it's also a control interface. 
3: Monitoring SP = ala #1, but with an additional time dimension if it 
offers more than just "latest observation", e.g. repositories that expose 
a time series of historical observations. 
4: monitoring record = set of properties with values, may include a link 
to a resource shape, each Property definition in the shape may include a 
link to the metric definition for it.  Perhaps the metric definition *is* 
a/the resource shape, potentially with extensions. 
5: metric definition = set of properties whose values are metadata about a 
particular monitoring record or about how data in the monitoring records 
is gathered 
Q1: For the "latest observation" case, which seems like it would be the 
most common one, I know from our meetings that implementations may collect 
various properties at different times.  Those times are usually "pretty 
close" together however, so I'm not sure if we need to expose a separate 
timestamp for each monitored value, or if there is consensus that one 
timestamp for the entire record is "close enough" given that we're living 
in a distributed HTTP system anyway. 
Q2: [1] shows UI preview content for various situations.  Are these values 
needed in RDF as well as HTML?  I.e. is this content intended to appear in 
response to GET against a performance record resource where the response 
content type != HTML, so we need properties and/or shapes for them? 
Q3: Does the WG object to the perf record to as a collection of in-line 
resource instances, like this 
<record-instance-URL> 
        pm:cpuUtilization       80 
        pm:connections          68 
        oslc:instanceShape      <shape-URL> 
        pm:collectedAt          20120512 
. 


[1] http://open-services.net/bin/view/Main/PmAppMonitoring 


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/20120613/5cdf96d4/attachment-0003.html>