[Oslc-pm] strawman + questions for resource definitions

[Julianne Bielski]

I like #3 because I think seeing a trend for a metric is more valuable 
than a snapshot in many cases.

Per Q1, I think one timestamp per record is sufficient.

Per Q2, that's a good question and I've been mulling it over myself for a 
long time. Since we also have a scenario for programmatic consumption of 
records, I can see us needing to provide the information in RDF as well as 
HTML. I'm interested in others' thoughts.

Per Q3, I don't object. I see you're using camel case in the property 
names, as that per some existing convention?





From:   John Arwe/Poughkeepsie/IBM at IBMUS
To:     oslc-pm at open-services.net, 
Date:   06/13/2012 07:49 AM
Subject:        [Oslc-pm] strawman + questions for resource definitions
Sent by:        oslc-pm-bounces at open-services.net



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 
_______________________________________________
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/20120613/58d280ec/attachment-0003.html>