[Requests] Fw: Comments on OpenMI 2.0 (OGC 11-014r1)

Satoshi Yamaguchi satoshi.yamaguchi.vk at hitachi.com
Thu May 30 21:45:45 EDT 2013


Dear OpenMI 2.0 authors,

We (Dr. Y. Kikumori and Dr. S. Yamaguchi) subscribe comments for 
OpenMI 2.0 Implementation Standard (OGC 11-014r1).

Please let me know if you receive this mail. I am afraid of that this 
mail may contain unreadable (garbled) characters (Japanese/Chinese Font).

Best regards,

----
Satoshi Yamaguchi
Social Information Systems Research Department
Central Research Laboratory, Hitachi, Ltd.
1-280, Higashi-Koigakubo, Kokubunji, Tokyo 185-8601, Japan
tel. +81-42-323-1111 ext. 4300

----
Part A
1. Evaluator
Dr. Yoshito Kikumori
Senior Researcher
Water Cycle Division, 
National Institute for Land and Infrastructure Management, 
Ministry of Land, Infrastructure, Transport and Tourism, Japan
Address: Asahi 1, Tsukuba, Ibaraki 305-0804, Japan
E-mail: kikumori-y92ta at nilim.go.jp 
Phone: +81-29-864-4849

Dr. Satoshi Yamaguchi, Researcher
Social Information Systems Research Department
Central Research Laboratory, Hitachi, Ltd.
Higashi-Koigakubo 1-280, Kokubunji, Tokyo 185-8601, Japan
E-mail: satoshi.yamaguchi.vk at hitachi.com 
Phone: +81-42-323-1111 ext. 4300

*Corresponding author is Satoshi Yamaguchi.

2. Submission
OpenMI 2.0 Implementation Standard (OGC 11-014r1)

Part B
#1: Clarification of the authors' IPR Policy notification
Requirement: Clarification of the authors' IPR Policy notification
Implementation Specification Section number: License agreement (page i) 
and 1.1. Background (page 1)
Criticality: Major
Comments/justifications for changes
We found the description below in 1.1: Background:
>the OpenMI Association, which has taken ownership of the IPR of the OpenMI. 
However, we cannot confirm that the authors' (OpenMI Association's) 
IPR policy is RAND-Royalty Free. 
We would suggest that their IPR policy should be written in the documents.

#2: Deletion of some parts other than technical specification 
Requirement: Deletion of some parts other than technical specification
Implementation Specification Section number: General 
Criticality: Major
Comments/justifications for changes
We think that a purpose of an implementation standard is to enable both 
client code and library to develop independently. An implementation 
standard defines interfaces to which client code and library should be 
compliant. A client code developer and a library developer are equal partners.
However, this implementation standard defines not only interfaces but 
required conditions for client code (e.g., linking with official library) and 
a client code developer (submitting xml documents to the official 
library developer). The library can only be developed by the official developer.
A client code developer and the official developer are not equal partners.
It seems that this implementation standard includes some rules made by 
the official developer to be followed by client code developers.
To make a client code developer and a library developer be equal 
partners, we would suggest that some parts other than technical 
specification should be removed.

#3: Clarification of all the requirement for conformance 
Requirement: Clarification of all the requirement for conformance
Implementation Specification Section number: 2. Conformance (page 4)
Criticality: Minor
Comments/justifications for changes
The specification indicates that some parts of the requirement for 
conformance are written in the source code.
>An OpenMI-compliant component shall implement the IBaseLinkableComponent interface according to specifications provided in this document and as comments in the OpenMI.Standard2 source code.
We think that source code should be changed without usual consensus 
formation processes in OGC, because source code and software should be 
updated frequently. 
On the other hand, usual consensus formation processes are needed before 
changing an OGC standard. Thus, we think that referring to comments in 
the source code is not adequate as an OGC specification documents. 
We would suggest that the entire requirement for conformance should be 
written in the specification document.

#4: Addition of OpenMICompliancyInfo.xsd schema
Requirement: Addition of Please describe OpenMICompliancyInfo.xsd schema
Implementation Specification Section number: 2. Conformance (page 4)
Criticality: Editorial
Comments/justifications for changes
We cannot find OpenMICompliancyInfo.xsd schema in the document. 
We would suggest adding it.

#5: Addition of runtime environment requirement
Requirement: Addition of Please describe runtime environment requirement
Implementation Specification Section number: 2. Conformance (page 4)
Criticality: Minor 
Comments/justifications for changes
Linking with official binary (dll/jar) is required, but runtime 
environment of the binary is not written. We would suggest adding it. 
For example, versions of Microsoft Windows (Windows XP/Vista/7/8), 
a version of Microsoft .Net Framework (3.5), 
and versions of compiler (Microsoft Visual Studio 2008/2010/2012).

#6: Deletion of authors' discretion from the judgment of conformance 
Requirement: Deletion of authors' discretion from the judgment of conformance
Implementation Specification Section number: 2. Conformance (page 4)
Criticality: Major 
Comments/justifications for changes
The requirements for conformance include submission of XML document to 
OpenMI Association.
>An OpenMI-compliant component shall be associated with an XML file, referred to as the compliancy info file, which conforms to (can be validated with) the OpenMICompliancyInfo.xsd schema. This file shall be submitted to the OpenMI Association.
The details of the requirements are written in a reference listed in 
"1.6 Further reading".
>"2 Standards", p.9, "OpenMI Document Series: The OpenMI 'in a Nutshell' for the OpenMI (Version 2.0)", The OpenMI Association Technical Committee, 2010.
>2.4 Compliance
>As mentioned earlier, it is a condition of compliance that the implementer must provide metadata about the model. 
>Apart from this model -specific information, additional general information is also required. 
>The purpose of this additional metadata is to provide an overview of the component's purpose, usage and implementation. 
>For compliance, a supplier should communicate this metadata as XML to the OpenMI Association. 
>The Association will then review, and if accepted, publish the data on the Association's website to promote its availability. 
>The metadata provides information such as:
>* What the component models and its utility
>* Who owns the component and its availability for usage by others
>* Which exchange items the component exposes
>* Which computational frameworks and platforms it implements
This requirement means that only OpenMI Association can judge a module 
passes the conformance test or not. We would suggest that definition of 
conformance should be independent from specification authors' 
discretion.

#7: Clarification of guidelines for terms of unit of measure
Requirement: Clarification of guidelines for terms of unit of measure
Implementation Specification Section number: 6.3 Value Definition (page 14)
Criticality: Minor 
Comments/justifications for changes
Is the Unit of Measure (UoM) stored as a string (IUnit.Caption)? 
If so, what is the adequate style for UoM? 
For example, which one should we use? (km, kilometer, kilometers, 
キロメートル (Japanese), 公里 (Chinese),... ). Or everything is OK? 
A guideline for UoM is shown in OGC standards (see examples below). 
We would suggest that guidelines for UoM should be shown in the 
specification.
>8.3 Units, p. 20, WaterML 2.0 - Timeseries - NetCDF Discussion Paper , OGC 12-031r2.
>Units of measure in WaterML are specified using the Unified Code for Units of Measure (UCUM)(Schadow & McDonald, 2009). 
>NetCDF conventions use the UDUNITS-2 unit database (Unidata Program Center, 2011).

#8: Deletion of requirement to use locale-dependant unit
Requirement: Deletion of requirement to use locale-dependant unit.
Implementation Specification Section number: 6.3 Value Definition (page 14)
Criticality: Minor 
Comments/justifications for changes
Unit of currency is locale-dependant unit. The authors also note that.
>Currency has no base quantity in the SI system. 
>Note that currency has conversion units that may vary over time.
Nevertheless, why the authors select EUR as the common currency unit? 
Fixing the constants of x0, x1, x2... is not a simple task.
1 EUR = x0 AUD = x1 CAD = x2 CHF = x3 GBP = x4 JPY = x5 USD = ...
Of course, this equation with fixed values is useful in limited situations.
On the other hand, authors show a guideline for dimensionless units (ppm, 
psu, dB, Sv, ...).
>Note that some units are dimensionless, represent logarithmic scales or present other problems when expressed in SI. 
>In such cases, extra attention should be paid to the descriptive part of the unit, to ensure that a user defining a link has a proper understanding of the meaning of the values for the given exchange item.
Currency is not physical quantity, but a man-made dimensionless index. 
As same as other dimensionless units, we would suggest that functions 
for conversion to the SI value are not needed for currency.

#9: Clarification of Normative References
Requirement: Clarification of Normative References
Implementation Specification Section number: 3 Normative References 
(page 5), 4 Terms and Definitions (page 7), and 5 Conventions (page 8)
Criticality: minor
Comments/justifications for changes:
The document should list every reference documents including C#, Java, 
UoM, Modified Julian day, WKT, etc. in 3 Normative References.
Furthermore, the document should describe the reference document of the 
data type "int" corresponding to the list in 3 Normative References so 
that readers would understand the definition and condition to use it.
Furthermore, URLs are described in the document (i.e. p.7, p.8) as well 
as some of those URLs are different from the list in 3 Normative 
References (i.e. p.5, p.8). 
To avoid confusion, it would be better to describe every URLs only in 
3 Normative References. 

#10: Clarification of Annex
Requirement: Clarification of Annex
Implementation Specification Section number: Annex A (page 65) and Annex B (page 78)
Criticality: Editorial
Comments/justifications for changes:
We would suggest to add the category "(Normative)" or 
"(Informative)" to Annex A and B.

#11: Deletion of duplication
Requirement: Deletion of duplication
Implementation Specification Section number: 4 Terms and Definitions (page 6)
Criticality: Editorial
Comments/justifications for changes:
If the meanings of the sentences below are equal, it would be better to 
delete one to avoid confusion. Otherwise, maybe miss-spelling?
>* to aggregate or disaggregate or interpolate between output values over time or space
>* to interpolate between output values over time or space

----







More information about the Requests mailing list