[Oslc-pm] Continuing to evolve our example

[John Arwe]

Syntactically correct Turtle [1] representation corresponding to [2], with 
the resource shape filled out a bit more.  Turtle is usually easier for 
people to read than RDF/XML; if you want to convert, [3] is a site I've 
found useful. 

I've also figured out some of the other OSLC work that has gone on around 
metrics (in convergence for the past 2 years, so not moving terribly fast) 
for estimation and project scheduling [4].  It took me a while to figure 
out their Twiki pages, and they are short on instance examples that would 
be of interest to us (their Primer has at least one trivial example but 
its not an observed value its definitional), but in the end they are doing 
it as a "bucket of metrics" where each metric is a blank node (sub-tree, 
for XML folks).  The most direct analog I see to a PerfMonRecord is [5] 
(context) which uses [6] for the 0:* in-line resource definition of each 
Metric.

There are some issues/questions embedded in the Turtle comments (# to EOL) 
that led me to really go spend the time to figure out the SW Proj Mgmt 
WG's metrics work above.  The less hand-waving I do, i.e. the more precise 
I get in examples, the more I'm feeling "forced" back toward the model 
Julie started with ... forcing it to be any simpler means that some of the 
information (metadata) has to be baked into the predicate definition, 
which limits its potential re-use.  If simplicity is critical for 
consumers on some very small number of metrics, we could define narrowly 
scoped predicates to meet them, but I'm wary of making that the default 
(the vocabulary gets unusably large quite fast).  I'm likewise reluctant 
to start out by saying we'll have both the simple and the very general (2 
different syntaxes to cover the simple cases would be confusing on its 
own).  So, new alternatives happily considered.


@prefix pm: <http://open-services.net/ns/perfmon#> .
@prefix oslc: <http://open-services.net/ns/core#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix dcterms: <http://purl.org/dc/terms/> .
@prefix ex: <http://example.org#> . 

@base <http://perfmon-provider.example.org/> .

<rec001>   # a record instance
        a pm:PerformanceMonitoringRecord ;
       pm:cpuUtilization       80 ;
       pm:connections          68 ;
       oslc:instanceShape      <rec001shape> ;
       pm:collectedAt          "2012-06-13T19:48:09.5Z" ; 
           # NO time zone on following implementation-specific extension 
property
           # This is legal in xsd:dateTime, but not great for interop
           ex:aLocalTime           "2002-05-30T09:30:10.5" ; 
. 

<rec001shape> # the corresponding shape instance
        a oslc:ResourceShape ;
 
        oslc:property [
        # Minimum properties required if we want to re-use OSLC resource 
shape & property
        a oslc:Property ;
        oslc:name                                       "cpuUtilization" ;
        oslc:occurs                                     <oslc:Zero-or-one> 
;
        oslc:propertyDefinition         <pm:cpuUtilization> ;
        oslc:valueType                          <xsd:integer> ;
        # PM additions
        a pm:MetricDefinition ;
        dcterms:description                     "Describes how much CPU is 
in use verses how much is 
available for use" ;
        # Core does not allow >1 value type, so in pm ns for now.  Bring 
issue to Core.
        pm:valueType                            <pm:Percentage> ;
        pm:collectedEvery                       "P20S" ; # every 20 sec, 
xsd:duration format
        # implementation-specific extensions - example
        ex:sourceToken                          "percent_cpu_utilization" 
;
        ] ;
 
        oslc:property [
        # Minimum properties required if we want to re-use OSLC resource 
shape & property
        a oslc:Property ;
        oslc:name                                       "connections" ;
        oslc:occurs                                     <oslc:Zero-or-one> 
;
        oslc:propertyDefinition         <pm:connections> ;
        oslc:valueType                          <xsd:integer> ;  # float? 
double? if an avg...
        # PM additions
        a pm:MetricDefinition ;
        # Q: should we bake "average" into the property definition?
        #        that would lead to an explosion in the number of 
properties
        dcterms:description                     "Describes how many 
connections are available in the 
database connection pool on average" ;
        # pm:valueType omitted since integer covers a count
        pm:collectedEvery                       "P20S" ; # every 20 sec, 
xsd:duration format
        # implementation-specific extensions - example
        ex:sourceToken                          "DB Connection Pools" ;
        ]
.

[1] 
http://www.w3.org/TR/2011/WD-turtle-20110809/#an-introduction-to-turtle--informative
[2] 
http://open-services.net/pipermail/oslc-pm_open-services.net/2012-May/000014.html
[3] http://any23.org/
[4] http://open-services.net/bin/view/Main/MetricsHome
[5] http://open-services.net/bin/view/Main/MetricsEmsMeasurement
[6] http://open-services.net/bin/view/Main/MetricsEmsMeasure

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/20120620/a4277d5f/attachment-0003.html>