Terms and Definitions to be updated to include core concept vocabularies in RoSO and RoIS.
RoSO definitions of Object (PhysicalThing) and Environment to be updated to describe interaction with PhysicalThing or Environment.
The section title for 7.3 should be "Robotic Service Function Ontology."
section title for 7.3 is to be fixed
The section title for 7.3 should be "Robotic Service Function Ontology."
Figures 1 and 2 are taken from the RoSO RFP, which was issued in 2018. The references to other standards need to be updated, and the main text in Section 1 (scope) and Section 3 (reference) need to be synchronized.
Reference to ontology and standards to be updated
This issue was a duplicate submission in RoSO 1.0 FTF and has been resolved under ROSO-9.
There is a lack of definitions of vocabularies to define parameters of RoIS component functions and it causes insufficience in some of the use cases.
More vocabularies should be defined.
Terms for component parameter added and demonstrated in Annex A
There is a lack of definitions of vocabularies to define parameters of RoIS component functions and it causes insufficience in some of the use cases.
In RoSO 1.0, Annex A is described with an example of Person Detection component in RoIS. To demonstrate with components with different message types, two examples for Person Localization and Follow are added.
As a result, Annex A is reorganized into five subsections, A.1 for RoIS Functional Component Ontology with modified Table A.1 and A.2; following three subsections for demonstrating RoIS Components with A.2 Person Detection, A.3 Person Localization and A.4 Follow; then demonstration for representing requirements in addition to RoIS parameters is described in A.5 Extension to RoIS Requirements.
To describe them, a new primitive class 'PhysicalThing' is added to Figure 3, and Table 7.2 in section 7.1.
Relationships between function/component and event/action are not described.
To describe them, vocabularies such as 'detects' and 'causes' have to be defined.
Repationships between function/component and event/action to be merged to ROIS11-2
This issue is to be merged with ROSO11-2.
The terms 'detects' and 'causes' have already been adopted in the RoSO 1.0 FTF.
This issue should address 'notifies' and 'executes' instead; however, the proposals for them can be merged with ROSO11-2.
The current document already defines the events detected from environments by functional components and the actions caused in the environments by functional components.
However, there is a lack of definitions of vocabulary to describe the events notified to services and the actions requested from services.
Therefore, it is currently impossible to describe relationships between the environment, components, and services.
'CommandExecution' and 'EventDetection' added as components' activity and 'notifies' and 'executes' to describe those instances.
Two component behaviors 'EventDetection' and 'CommandExecution' are defined as subclasses of 'Event' and 'Action.'
For describing relationship between Component and them, 'notifies' and 'executes' are defined as follows:
Figure 7 is revised to describe changes among those classes.
Figure 8 is revised to describe properties notifies and executes.
Definitions in Table 7.6 also include those entities.
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.
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.
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.
2. Relationship between Function and Event/Action introduced.
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.
Update of ontology RDF files are also attached with this issue.
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.
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.
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.
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).
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.
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.)
No particular relationship between RoSO and IEEE CORA is represented since RoSO is defined as independent from CORA.
Figures 1 and 2 are taken from the RoSO RFP, which was issued in 2018. The references to other standards need to be updated, and the main text in Section 1 (scope) and Section 3 (reference) need to be synchronized.
This Issue was not resolved in this Task Force and was automatically deferred to the next Task Force
