Every component parameter in RoIS 1.2 (and the RoIS 2.0 draft, if possible) must be instantiated and described in relation to the component.
As an example of detail missing for a PSM, there is a class named Direction with no properties or definitions for how a specific direction would be represented.

Definition of RoIS parameters to be described by name in addition to classes.

For Secion 7.3 Robotic Service Function Ontology,
1. Relationship between Function and Component renamed.

• Object property ‘hasFunction’ renamed to ‘features.’

2. Relationship between Function and Event/Action introduced.

• Object property ‘detects’ for sensors which detects events
• Object property ‘causes’ for actuators which causes action

Figure 7 in RoSO-10 to be updated with two figures as well as other two ontologies.

In Annex A,
4. Section title indicated as ‘Informative’ instead of ‘non-normative.’
5. Figure 6 in beta1 replaced with two new figures that represents Person Detection Component as an example.

• Figure 9: Classes for Person Detection
• Figure 10: RoIS Parameters used in Person Detection defined as object properties

Update of ontology RDF files are also attached with this issue.

Revise the examples in Annex B and C to make them simple enough to understand the service scenario and restrictions described using RoSO. Consider using triple format instead of RDF/XML for easy understanding, but the machine-readable files need not be printed in the standard document.

Examples in Appendix B and C to be revised with turtle format.

Turtle versions of those examples have been included in the RoIS 2.0 revised draft (robotics/2024-09-07).
XML/RDF representations of examples are to be removed from sub-sections C.X.4 and updated with graph representations attached at the end of C.X 3.
SVG figures and turtle files are attacjed as a zipped example file.

Definitions of Commons are not included in the (non-normative) XMI.
Should a UML version of Commons be needed (not necessarily a bad idea), that should be achieved through an update to the Commons spec—which could be through the RTF or, at a pinch, by detailing the changes in this new submission in the Changes to Other Specifications section. In no circumstances should the Commons classes (or indeed lcc:Location or owl:Thing) be included in this XMI but referenced via hrefs.

Definition of Commons to be included in the (non-normative) XMI.

As the resolution for ROSO-2 required to include Commons 1.1 definition to the model, this issue is merged to ROSO-2 and resolved simultaneously.

The name of AIST is to be corrected as 'National Institute of Advanced Industrial Science and Technology, Japan.'
That appears in section 6.1 and ontology metadata in section 7.

Institute name of AIST to be corrected

The name of AIST is to be corrected to 'National Institute of Advanced Industrial Science and Technology, Japan.'
It appears in section 6.1 and ontology metadata in section 7.

None of the properties (association ends) are named, which is not allowed by MOF, e.g. 3 ownedAttributes of Action. It seems all the names are only on the Associations.
There are 3 instances of uml:Connector, which is not in the subset of UML supported by MOF.
Values are included for default values for upperValue, lowerValue, and isSubstitutable.

Objects not supported by MOF to be removed from XMI.

As the resolution for ROSO-2 requires using the ODM stereotypes, this issue is merged with ROSO-2 and resolved simultaneously.

In the scope section, Figure 1 and Figure 2 refer to the RoSO 1.0 RFP, which was issued in 2018. Figures and corresponding text to be update to refer to recent update such as OMG Commons 1.1.

Reference to ontology and standards to be updated　

Regarding recent updates in robotics and related ontology, Figure 1 and Figure 2 updated to indicate publication of OMG Commons, IEEE 1872.1, IEEE 1872.2, ISO22166-201.

Consider describing the relationship between classes using EquivalentClass, DisjointClass, etc. For example, Robot and Person seem to disjoint parts of Agent. References to Commons or CORA classes may use EquivalentClass.
IEEE RAS, however, does not provide CORA-owl officially. Is it possible to refer them in OWL?

Relationships between classes when referring to other ontologies such as Commons and CORA to be described.

Definitions in Commons 1.1 are imported to the model (though it is ancillary), and then Figures are replaced with those using ODM prototypes.
Figures 3, 4, and 5 in beta 1.0, which represented classes, are replaced and renumbered to Figures 3, 5, and 7, respectively.
Figures 4 and 6 added to illustrate the hierarchy of properties. (Figure 7 contains both classes and properties.)

• The disjoint relationship between Robot and Person is defined as a class axiom of Robot.
• The domain of isLocatedAt is defined as a union of Point, Region, and Site with ODM stereotypes.
• The domain of hasRole is defined as a union of Agent and AgentGroup. (typo: \cap replaced with \cup)
• Incompatibility between figures and texts revised mostly about range and domain of property (missing axioms added as texts).
• The range and domain of actedOn is inverted.
• Removed AgentGroup from range or domain of properties in RoboticServiceInteractionOntology.

No particular relationship between RoSO and IEEE CORA is represented since RoSO is defined as independent from CORA.

Section 3 has several references that are not required for this specification, e.g., Terminology Work, which might have been used to help author the definitions in the spec, but an implementor does not need access to those.

Unnecessary references to be removed.

• Following references in the Section 3 are to be removed.
  • API4KP
  • BCP47
  • Dublin Core
  • ISO 704
  • ISO 1087
  • MOF
  • MOF XMI
  • MVF
  • SMOF
  • XSD
• The recent update of ISO22166-201 was added instead.
  • [ISO 22166-201] ISO 22166-201:2024 Robotics – Modularity for service robots – Part 201: Common information model for modules. Available at https://www.iso.org/standard/82334.html.
• Corresponding symbols in Section 5 (API4KP and MVF) are also removed.

Avatar is conceptually not limited to a subclass of Robot. To be renamed to AvatarRobot.
The abstract concept of an Avatar is to be defined independently, based on the relationship with the Person.

Consider to rename Avatar to AvatarRobot and re-define Avatar independently.

Avatar is an agent but not limited to that with physical body.
Avatar is defined as a sub-class of Agent, as well as Person and Robot, which has 'represents' property to Person.
AvatarRobot is also defined to replace the previous definition of Avatar that inherits both Robot and Avatar.
Those definitions are included in the Figure 3 and 4 (attached to ROSO-10).