Comments on MFI-9 to be discussed in BRM
1. Document type
CA01: Having reviewed the ISO Directives descriptions of Technical Report and Technical
Specification, we believe this document would be better as a Technical Specification.
Editor: We hope to get rationale from Canada and discuss or vote in WG2.
2. Scope
JP05: Second paragraph, “to select appropriate combinations of models and/or services to meet
user’s request” should be “to semantic discovery of services to support user’s request”.
Rationale:
-If we look at the whole document, including several use cases examples at 5.2, 5.3 and Annex A,
the expected result of semantic search is always (web) services.
- “to support user’s request” is better wording than “to meet user’s request” because usually, only
some part of the request is satisfied.
US01: To: “…on demand model selection so as to help users discover process and service models
that meet their needs.”
Editor:
Recommend the title changed to the original one “On demand model selection based on RGPS”
Title change request will be submitted to SC32. To get a draft resolution for part 9.
3. Terms and definitions
GB02: 3.1.7, this clause is formatted incorrectly.
Editor: Accepted.
US004: 3.1.1, use standard definition if possible to disambiguate the meaning of role.
US005-US009
Editor: The terms and definitions in MFI-5, 7, 8 apply for this part.
4. Normative Reference or Bibliography
CA05: It is not clear the Part 6 is referenced in a way that makes it indispensable to the use of this
part.
Suggestion: Move the reference to Part 6 to the Bibliography.
Editor: Add the reference to MDR-6. Move the reference to Part 6 to the Bibliography.
5. Levels of matching in the Semantic Annotation
CA10: This clause introduces the concept of Semantic Annotation and different levels of matching.
Similar, but different concepts are described in 20943-5 SMMP.
Suggest: The levels of matching specified in this document should be aligned with the Semantic
Mapping methods described in 20943-5.
US27: use the owl language for the Web Ontology Examples in Table 1
Proposed fix:
______________________________
Exact Match
| owl:equivalentTo |
| owl:subclassOf |
Fuzzy Match | owl:superclassOf | owl:part of
Mismatch | no relationship found
Etc…
Editor:
OWL will be the preference. That is, get conceptual alignment with SMMP, and use OWL
language to represent the relation.
6. Figure 1
involvedRole 0..*
playedRole
Role
0..*
0..* 1..* undertakingRole
involvedRole
plays
0..*
Role
Actor
0..*
0..* 1..*
1..*
1..*
takesChargeOf
playingActor
plays
1..*
Actor
1..*
takesChargeOf
prefers
prefers
1..* undertakenGoal
isInvolvedIn
1..*
0..*
RoleGoal
PersonalGoal
Goal
isInvolvedIn
preferingActor
0..*
RoleGoal
Goal
0..1
involves
preferedGoal
PersonalGoal
0..1
involves
achievedGoal
0..1
achievedGoal
0..1
achieves
achieves
0..*
0..*
0..*
achieves
Process
0..*
realizes
0..*
0..*
0..*
involvingProcess
achievingProcess
Process
achieves
0..* realizedProcess
realizes
0..* realizeingService
0..*
Service
Figure 1 — Relationships in RGPS(original)
involvingService
0..*
Service
0..*
achievingService
Figure 2 — Relationships in RGPS(new)
CA08: Convert the model to use associations instead of references.
CA09: should show references in both directions
GB03: Figure 1, Provide association names and role names throughout.
Editor: Accepted.
US018: Figure 1 does not depict the resource, event, input and output classes that are in figure 2.
Editor:
MFI-5,7,8.
Figure 1 only shows the relationships among role, goal, process and service, not all the classes in
Add in the text more explanation the difference between figure 1 and 2.
7. Table2
GB05: At the Goal/Goal intersection there is an '/' included without any explanation as to its
meaning. Provide explanation.
CA11: in Table 2, the references between Process and Role and between Service and Role are
named InvolvedBy. This is not a natural way to express the reference in English.
JP06:“isInvolvedIn” should be “involvedBy” and the direction of the black triangle should be
opposite.
Editor:
Delete Table2, add more explanation in text.
For the “involves” relationship in Figure 1, we will follow CA11. However, according to the further
discussion with experts from UK and CA, “involves” is too generic. According to Keith’s suggestion,
at least three separate associations between Role and Process. These are:
Each Process is performed by zero or more Roles; each Role is performer of zero or more Processes.
Each Role is customer of zero or more Processes; each Process has as customer zero or more Roles.
Each Role is beneficiary of zero or more Processes; each Process benefits zero or more Roles.
Baba’s suggestion is that we need not limit to the 3 associations, but instead enable a number of
associations by defining a role association type.
We follow the suggestions.
8. Figure 2
US019: Figure 2 does not show a relationship between Process and Goal so it’s hard to understand
how annotation of the Goal operation and object with ontology concepts will result in linking the
Process to the Goal.
Editor: Figure 1 shows the relationship between the process and goal. While figure 2 just shows
what kind of elements in MFI-5,7,8 will be annotated by domain ontologies.
Accepted. Add more explanation in text.
Explain why do MFI-5,7,8 have such annotations.
9. Table 1
JP08: “The concept in the user request “is not clear.
Editor: The terms in the user request will be annotated by the classes in domain
ontology( “ontology_atomic_construct”), also need to be tagged by the metaclasses such as input
of the process. We need to add more explanation.
JP09: The notion of subclass between concepts should be defined. Also, it needs to be explained
how it can be decided that “concept A is subclass of concept B”. Unfortunately, MFI-3 does not
have that kind of notion and cannot provide that kind of information.
Editor: Based on the source domain ontology that is registered in MFI-3. Add explanation about
that the definition of subclass should follow OWL.
10. Relationships with MFI-5, MFI-7, MFI-8 registries
JP01: In principle, MFI registries constitute common semantics (essential subsets) of models
outside the registries. The models outside the registries are independently developed each other
and common semantics (essential subsets) of them are extracted to MFI registries under some
authorization.
That means that in general a MFI -5 registry, a MFI-7 registry and a MFI -8 registry are also
independently developed and maintained.
Please note that TR19763-9 is for this kind of open environment under some authorization, unless
otherwise specified.
If TR19763-9 requires more uniformly controlled environment, for MFI-5, 7, 8 registries, please
clearly specify that.
JP03: TR19763-9 should specify a guideline also on how to develop ODMS registries (i.e. MFI-5,
7, 8 registries).
In principle, MFI registries have common semantics (essential subsets) extracted from models
outside the registries. But, especially, as for MFI-5 and 7, it does not seem that most of the
information can be extracted from the models outside the registries. TR19763-9 should explain
how it can be extracted or created.
TR19763-9 should explain how the relationships among MFI-5, 7, 8 registries and who are
responsible for that (for example, authorities of relationships between Goals and Processes are
ones of Goals or of Processes.) This is because the relationship among MFI registries of different
parts cannot be developed from the information in each MFI registry. (Note: Precondition and Post
condition of MFI-5 and 7 may be used to develop relationships between them. But, they is the
only ones.)
Editor:
This question has been proposed in Redwood meeting, which have also been discussed in Hawaii
meeting. I’m sorry that I forget to write down it in the document:
We do not need to maintain a separate registry to record the relationship among each part.
Process registry can register the relationships with Role&Goal; Service registry can register the
relationships with Role&Goal, and Process.
The relationships between ontology and the RGPS registries should be recorded by MFI-5,7,8,
respectively.
For how to extract common semantics from models outside the registries, the mapping tables in
MFI-5,7,8 shows the relationships between the corresponding description languages with
MFI-5,7,8 registry, respectively. Could we follow these mapping tables?
It should be more specific to RGPS. Add more explanations.
JP02: TR19763-9 should also explain how to use the information not referred to.
TR19763-9 should specify a guideline also on how to use it via the models in the MFI registries.
Semantic
annotation
Elements in Table2
essential subset
MFI registry
models
Editor: The information annotated by domain ontology is more important for model selection.
We still didn’t realize which element that is not referred to is important in model selection.
It should be more specific to RGPS, i.e., ODMS based on RGPS.
Based on the information registered in MFI-5,7,8
11. Last half part of Architecture of ODMS
JP13: The last half part explains an implementation example on a part of ODMS. This part should
be removed.
Editor: Do we need to provide such a template to express user’s request. The template is defined
according to a comment in Redwood meeting: Consider that different kinds of users (such as
developer and end user) may use different template when defining templates.
In the template, we want to show how users can express their requests, and denote what is their
expected result (a process model or a service).
Keep it in the main text.
US030: The purpose of “Request Description” is not clear.
example
Please provide a more complete
Editor: Request description denotes the content of user request. We will need to add more
explanations and give an example.
12. Annex A
JP14: It may be better to move whole Annex A (or at least a complex example part) to the main
text.
Editor: Need to get consensus. Keep it in the Annex since it is informative.
JP17: In this complex example, the decompositions of Goals, Processes and Services seem to be
isomorphic.
Editor: We need to provide a more illustrative example