[oslc-core] [Oslc-pm] Review of PerfMon spec

Tue Jan 8 12:24:29 EST 2013

John,

I think you phrased it right when you said "safe" re-use.  If the
referencing of these vocabularies, ontologies and specifications are purely
exemplary then it is only a dependency on the informative prose of the
spec.  I got the impression from this spec that the use of ems:Measure goes
a little beyond that.  The statement "When the resource is of type
ems:Measure, that resource SHOULD contain an ems:Metric predicate whose
object is of class pm:Metric (either directly or indirectly)"  leads me to
believe that it is more than just an example.

-jim

From:	John Arwe/Poughkeepsie/IBM at IBMUS
To:	oslc-pm at open-services.net,
Cc:	oslc-core at open-services.net
Date:	01/08/2013 11:21 AM
Subject:	Re: [oslc-core] [Oslc-pm] Review of PerfMon spec
Sent by:	"Oslc-Core" <oslc-core-bounces at open-services.net>

> 5. This spec depends on other specifications that have not finalized
> (ESM and Recon). Either coordinate the finalization with or after
> the dependent specs, or remove the dependency on these specs.
>
> Do you consider vocabulary re-use a dependency? Or is there some
> other reason you considered the pm spec to have a dependency?
>
> [jc: yes, if the vocabulary is referenced and required for the use
> and understanding of the specification.  the concern is that before
> the dependency is finalized it might change, and thus affect the
> specification after it is finalized.]
>

This one I was not specifically asked about, but I'm going to weigh in
anyhow.  I think this is an issue Core is ultimately going to need to take
up even if this review was not formally "from" Core, given how far from my
thinking the comments sound like they are.  Re-using "what is" is hardly
something the WG did lightly, and I certainly thought I thought it through.

Reconciliation/CRTV:   Having just searched [1] again, I find exactly one
use of Reconciliation (namespaces section when crtv is "defined", as the
text of a hyperlink), and many of crtv vocabulary terms; all of the latter
either in the descriptions of predicates whose type is Resource + Reference
and made exemplary explicitly using the Core-approved boilerplate text, or
in the "Resource Properties" intro paragraph where they are similarly
qualified).  As long as the re-use is all exemplary, as I think it is here,
I disagree that it is required for the use or understanding of the spec.  I
think it is incrementally *easier* to understand by using those examples,
sure.  If Core were to ultimately determine that this dependency is
unacceptable (would gate Perf Mon's finalization) in the absence of a
finalized Reconciliation spec, then I suspect the PerfMon WG would (path of
least resistance) move that content into a non-normative companion
document.  I don't see how that helps readers or adopters, but it seems
like that would remove the dependency.  I think Core as a whole needs to
clarify its thinking on this, both in terms of what it ultimately wants and
the policies in place to produce that outcome, and get on the record so the
Perf Mon WG has more time to incorporate Core's thinking into its
documents.  FWIW, I expect the same pattern in other ISM domains in the
future ... there is nothing 'special' about PerfMon in this regard.

EMS: Here I think there is a requirement from PerfMon on EMS, so the
discussion becomes one of what needs to be true in order for Perf Mon's
re-use to be "safe".  If we accept the current state in OSLC of vocabulary
documents defining classes, properties (predicates), resources (terms that
are neither classes nor properties - Perf Mon has 0 of these, in case it
turns out to matter), and the prose semantics of each, and the domain
specifications defining a profiled use of those entities (effectively a
resource definition table == a resource shape), then in theory what we need
is some guarantee that the (subset of the ) vocabulary PerfMon depends upon
will not change.  The shape could be defined in either spec (or both)
without hurting any implementations, I assert.  If the EMS working group
agreed to hold the re-used vocabulary constant, would it satisfy the
dependency in your minds?  If not, what additional would be needed and why?
Perf Mon believed/s that their ability to re-use EMS:Measure without
changes was a feature (good thing), not a defect.

There is precedent in Core for modifying a domain vocabulary without
re-opening the associated finalized domain specification, so I don't think
we can say that a vocabulary's "status" is identical to the spec's.  Nor do
I think we can say that the WG owning the vocabulary must have a finalized
domain spec dependent on every vocabulary entity (same precedent case) in
order to be "safe" for re-use.

The simple "path of least resistance" approach, for a working group whose
members do not want to delay their finalization indefinitely (until the
other WG resumes active development, etc.), would be to copy everything
into a namespace they control (here: copy EMS:Measure and the 4ish
properties PerfMon needs into the PM namespace), thus removing the
dependency and (as a consequence) establishing a "measurement island" in PM
purely because of the vagaries of the schedules of those involved -- there
is a large set of EMS-draft vocabulary that Perf Mon has no stated intent
to re-use in any way, so this really is an island getting created.  The
onus would then by on the other WG (EMS) to re-use PM (or justify why NOT
to re-use work that started out, by definition, to be exactly what EMS
needed) in EMS's domain spec when it resumes.  If that is the effect Core
wants, the right policies and incentives are in place.  It seems to me a
perverse result, and one that *could* be solved without creating this
effect via the agreement above.  It is up to Core to enable it however.

Since several of us are on Core ;-) and there is a meeting next week,
perhaps we can get this on the agenda.

[1]
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/

Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario
_______________________________________________
Oslc-Core mailing list
Oslc-Core at open-services.net
http://open-services.net/mailman/listinfo/oslc-core_open-services.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130108/9e1a8dfd/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-core_open-services.net/attachments/20130108/9e1a8dfd/attachment.gif>