Revision: Architectural Direction

In-progress Working document - supporting specification development for the next version of PM. This is not an official list of committed items but a live working document to help prioritize and elaborate on the specification efforts.

Contents

• Items for Consideration for 2.0
  • Themes
  • Item Details
    • Re-use of Other Vocabularies
• Supporting References

The purpose of this page is to collect the architectural direction as driven by scenario priorities for the next version of PM specifications (V1). It also contains any issues left unaddressed in previous version(s), if any.

Items for Consideration for 2.0

Themes

• Low entry point

Others to consider:

• Specific examples are intended to be exemplary, not limiting. The assumption is, that unless something is specifically excluded in normative text (MUST NOT), it is “possible”. The intent is to allow a broad range of alternative implementations and implementation decisions.
• Re-use existing material when possible, rather than defining new, especially vocabularies widely used in the global RDF community, like Dublin Core.
• Enable whatever is defined-new here for wide re-use by other specifications, for potentially unforeseen scenarios.
• Avoid using reification, even though it is allowed by Core 2.0 Appendix C

Item Details

Re-use of Other Vocabularies

Potential re-use of software estimation and measurement work from the Software Project Management working group, which they call EMS.

1. EMS-defined metric URIs: see especially
   1. ems:Metric = a name for something that can be measured. For example, duration is the EMS metric that measures the amount of time that a project takes.
   2. ems:UnitOfMeasure = the units associated with the specific measured value of a metric. For example, project duration is typically measured in units of months or years.
   3. NASA’s QUDT vocabulary defines a substantial set of metrics that EMS metrics have a defined relationship to QUDT, a few of which appear to be ripe for re-use in Performance Monitoring, like the following. Diving directly in QUDT is not trivial, so the EMS page introductory material may be useful.
      1. Dimensionless for counts, like database connections
      2. DimensionlessRatio for percentages like CPU utilization
      3. Frequency if we need to expose how often a particular metric is collected
      4. Time as an alternative to EMS for durations and timestamps. Would need to decide between them if both are viable for our scenarios.
   4. ems:TimeMetrics: see if Duration, Start/Finish times make sense to re-use
2. Representing the value of a particular value, e.g. CPU utilization is 95%, or an average of 200.5 database connections are in use
   1. Metric Entities gives a bit of context for EMS’s approach to things.
   2. ems:Measure = a single measured value of a metric in specific unit: contains title, name of metric, name of units of measure, numeric value
   3. Issue to investigate: EMS metric values appear to be all double (timestamps are represented as Unix time). For averages etc. suspect PerfMon will need floats.

Potential re-use of W3C Recommendation-track linked data vocabularies, or (if more applicable) the inputs they reference.

1. W3C Government Linked Data WG - the inputs/outputs for the “statistical cube” vocabulary may be relevant. Find drafts off the WG wiki, and some others (that may eventually migrate to the WG wiki page) on their vocabulary discussion wiki page.

Supporting References

• Specification backlog