[Oslc-pm] Review of PerfMon spec
John Arwe
johnarwe at us.ibm.com
Tue Jan 8 10:17:37 EST 2013
Subsequent discussions have to some degree overtaken this, but let me get
a response to those issues I was specifically asked about into the
archives.
> 6. Why does spec guidance provide prefix suggestions for other domains?
In the case of EMS, because that vocabulary is re-used heavily in this
spec and referring to those instances by prefix is much more economical
and readable than by full URI. In the case of CRTV, probably should be
removed (I think it only shows up in examples, which should be
self-contained anyway). Since you were obviously clear that they were
*suggestions*, what's the problem exactly? Is this formatting, that you
want them more clearly separated?
> 8. In the samples Turtle is used. Turtle is never even mentioned in the
specification.
I have sympathy for the point of view that "if you require RDF/XML,
examples should be shown using that representation". I have less (but
still non-0) sympathy for "if you even mention X, then you need to make it
a MAY". Turtle being much *easier* to read, very popular in the linked
data community, both representations being semantically equivalent, and
HTTP ConNeg being there were enough reason for us to use it, even if all
current implementations represented in the WG are RDF/XML-only.
> 24. #Performance_Monitoring_Record rdf:type -- at least should include
perfmon:PerformanceMonitoringRecord, right?
That is the intent, as I think it is/was in every existing domain spec,
yet this is the first time I've heard the question. I suspect you're
concerned about explicit rdf:type properties in RDF/XML representations,
so XML-based clients (those without full RDF support) can more easily
process them, since that has been discussed in the past. I skimmed [1]
and [2] again, is there some Core-established convention to be followed?
The later response about re-using CM 2.0's statement seems problematic to
me (I think CM 2.0 is doing it wrong) if this is the reason behind the
question.
> 25. #Resource.3A-ems.3AMeasure The Turtle example has a weird trailing ;
and then ., suggest removing the ;. There is an unneeded comment "#
rdf:type". Note: the turtle samples in the
appendix have the same problem.
It is syntactically valid and accepted by validators. I use this style
intentionally in fact because it's more robust to changes (adding new
triples to a resource, etc.). Hence I see no up-side and small down-side
to changing. If I'm missing something, please point it out. The rdf:type
comment is a friendly concession to those more familiar with RDF/XML than
Turtle, since that little corner of Turtle syntax I've found does trip
them up.
> 25. #Resource.3A-ems.3AMeasure It would be good to add the @prefix
definitions to make it a valid Turtle doc.
That seems quite reasonable. It does (for very small examples) make the
examples harder to read, in the sense of a new reader seeing "what really
matters", but I see the value in having it be something that someone could
paste into a web-based validator/serializer to look at it in other
formats.
[1]
http://open-services.net/bin/view/Main/OSLCCoreSpecAppendixRepresentations
[2] http://open-services.net/wiki/core/Resource-Design-Guidelines/
Best Regards, John
Voice US 845-435-9470 BluePages
Tivoli OSLC Lead - Show me the Scenario
From: Julianne Bielski/Raleigh/IBM at IBMUS
To: Steve K Speicher/Raleigh/IBM at IBMUS
Cc: Oslc-Pm <oslc-pm-bounces at open-services.net>, James
Conallen/Philadelphia/IBM at IBMUS, oslc-pm at open-services.net
Date: 12/10/2012 12:53 PM
Subject: Re: [Oslc-pm] Review of PerfMon spec
Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
Thank you for the great feedback. I've removed from the list below the
comments I have addressed (as of this morning).
A few responses and follow up questions below.
John Arwe, I put your name next to a few I thought you may want to respond
to.
-- Regards,
Julianne Bielski, STSM
ITM Core Chief Architect
Tivoli, IBM Software Group
tel: (919) 224-1170 (T/L) 687-1170
e-mail: bielsk at us.ibm.com
"All growth is a leap in the dark, a spontaneous unpremeditated act
without benefit of experience." — Henry Miller
Steve K Speicher---11/30/2012 03:48:23 PM---Jim Conallen and I have
reviewed the Performance Monitoring 2.0 (dated Nov 28 [1]) and some
related
From: Steve K Speicher/Raleigh/IBM at IBMUS
To: oslc-pm at open-services.net
Cc: James Conallen/Philadelphia/IBM at IBMUS
Date: 11/30/2012 03:48 PM
Subject: [Oslc-pm] Review of PerfMon spec
Sent by: "Oslc-Pm" <oslc-pm-bounces at open-services.net>
Jim Conallen and I have reviewed the Performance Monitoring 2.0 (dated Nov
28 [1]) and some related documents
This review is NOT a review from the Core WG, though we are 2 Core WG
members who decided to provide some feedback.
Sorry these are in no particular order. Some are nit picky and some may
have a bigger impact:
4. If other query syntaxes are supported, how does the client know what
they are? The OSLC Core provides no guidance on query syntax other than
simple query. There are a number of things a PerfMon provider may do, not
sure it is worth listing all. Recommend getting rid of that MAY section
altogether.
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.
(John Arwe) 6. Why does spec guidance provide prefix suggestions for other
domains? It may be appropriate to suggest a prefix for the perfmon
domain, but not others. It is expected define prefixes that are used
throughout the rest of the spec, but not so suggest that others use them.
The namespaces section should look more like the other specs and just
state: "In addition to the namespace URIs and namespace prefixes defined
in the OSLC Core specification, OSLC Performance Monitoring defines the
namespace URI of http://open-services.net/ns/perfmon# with a namespace
prefix of pm."
(John Arwe) 8. In the samples Turtle is used. Turtle is never even
mentioned in the specification. Recommend either include turtle as a MAY
representation in the spec, or remove it from the samples.
9. #Reporting-Issues-on-the-Specification The Issues link is to a
non-existent page.
10. In the sample the property dcterms:date is used, and in the spec it is
specified as xsd:dateTime. In the sample it is not typed, and looks like
a string.
12. #Performance-Monitoring-Specification-Guidelines Recommend that the
Guidelines section either provide a lot more useful information or pull
it, as it does not seem to provide much useful information. We couldn't
make much sense out of how it would be applied and there are two sections
that are empty
13. #Appendix-B.3A-Resource-Shapes Shapes appendix is empty.
14. #Intellectual-Property-Covenant The patent non-assert document is
missing or unlinked
17. Mixture of formatting issues: MUST/MAY/SHOULD not always BOLD, etc
19. Why are last 2 of 4 scenarios in table have no data in table?
http://open-services.net/wiki/performance-monitoring/Performance-Monitoring-Scenarios/#Current-Iteration-Scenarios
20.
http://open-services.net/wiki/performance-monitoring/Scenario-Coverage-Report/
missing business goal like other scenarios (or some intro upfront text)
21. #Terminology definition of PMR is quite thin, be good to pull up some
of the text from the more detailed PMR definition like "This could be
numeric metrics, status, or some other kind of property of interest to
monitoring consumers."
24. #Performance_Monitoring_Record
(John Arwe) rdf:type -- at least should include
perfmon:PerformanceMonitoringRecord, right?
ems:observes -- read the description a couple times and still not sure I
get it.
...about a resource “EMS” -- what is *resource EMS*? This is a
formatting issue. The intent was that you read "Something observed and
measured about a resource" and then you can click on the EMS link to be
taken to the related text in the EMS spec.
...MAY be of any type Core -- what does it mean to be *of any type
Core*? Same as above. The intent is that you read "MAY be of any type" and
then click on the Core link to take you to the relevant part of the Core
spec.
When it refers to "the resource" talking about the subject or object
resource? The object ems:Metric pointed to by the ems:observes predicate.
(John Arwe) 25. #Resource.3A-ems.3AMeasure The Turtle example has a weird
trailing ; and then ., suggest removing the ;. There is an unneeded
comment "# rdf:type". Note: the turtle samples in the appendix have the
same problem. It would be good to add the @prefix definitions to make it
a valid Turtle doc.
26. #Metric-Categories consider Turtle example. Also RDFS is used and not
defined.
27. #Resource-Properties
pm:mobilityEnabled -- the description had me wanting more. I'm mobile,
would I be a valid value for this property? Not sure what "move about
dynamically" means. In the sense that a virtual machine can move by virtue
of support in the hypervisor platform.
pm:availabilityStatus -- "All values present MUST be semantically
compatible" how do I know if I do or don't conform to this?
[1] -
http://open-services.net/wiki/performance-monitoring/OSLC-Performance-Monitoring-Specification-Version-2.0/revision/1321/
Feel free to contact us with any clarifications needed.
Thanks,
jim conallen
Steve Speicher_______________________________________________
Oslc-Pm mailing list
Oslc-Pm at open-services.net
http://open-services.net/mailman/listinfo/oslc-pm_open-services.net
_______________________________________________
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/20130108/bbc06317/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://open-services.net/pipermail/oslc-pm_open-services.net/attachments/20130108/bbc06317/attachment.gif>
More information about the Oslc-Pm
mailing list