iso/iec jtc 1/sc 32 n 2165jtc1sc32.org/doc/n2151-2200/32n2165-summ_of_voting-n2140-pdtr...iso/iec...

ISO/IEC JTC 1/SC 32 N 2165 Date: 2011-10-18

REPLACES: —

ISO/IEC JTC 1/SC 32

Data Management and Interchange

Secretariat: United States of America (ANSI)

Administered by Farance Inc. on behalf of ANSI

DOCUMENT TYPE Summary of Voting/Table of Replies TITLE Summary of Voting on 32N2140 ISO/IEC PDTR 19763-9 Information

technology - Metamodel framework for interoperability (MFI) Part 9: On demand model selection

SOURCE SC32 Secretariat PROJECT NUMBER 1.32.22.01.09.00 STATUS WG2 is requested to resolve the comments. The document failed to obtain

substantial support. REFERENCES ACTION ID. ACT REQUESTED ACTION

DUE DATE Number of Pages 20 LANGUAGE USED English DISTRIBUTION P & L Members

SC Chair WG Conveners and Secretaries

Dr. Timothy Schoechle, Secretary, ISO/IEC JTC 1/SC 32 Farance Inc *, 3066 Sixth Street, Boulder, CO, United States of America Telephone: +1 303-443-5490; E-mail: [email protected] available from the JTC 1/SC 32 WebSite http://www.jtc1sc32.org/ *Farance Inc. administers the ISO/IEC JTC 1/SC 32 Secretariat on behalf of ANSI

ISO/IEC JTC 1/SC 32 N2165 Summary of Voting on Document SC 32 N 2140 Title: ISO/IEC PDTR 19763-9 Information technology - Metamodel framework for interoperability (MFI) Part 9: On demand model selection Project: 1.32.22.01.09.00

“P” Member Approval Approval with

Comments

Disapproval with

Comments

Abstention with

Comments Canada 1 China 1 Czech Republic 1 Egypt 1 Finland 1 Germany 1 India 1 Japan 1 Korea, Republic of 1 Portugal 1 Russian Federation 1 Sweden 1 United Kingdom 1 United States 1

Total “P” 4 1 4 5 “O” Member

Austria Belgium France Ghana Hungary Indonesia Italy Kazakhstan Netherlands, The Norway Romania Switzerland

Total “O” Dr. Timothy Schoechle, Secretary, ISO/IEC JTC 1/SC 32 Farance Inc *, 3066 Sixth Street, Boulder, CO, United States of America Telephone: +1 303-443-5490; E-mail: [email protected] available from the JTC 1/SC 32 WebSite http://www.jtc1sc32.org/ *Farance Inc. administers the ISO/IEC JTC 1/SC 32 Secretariat on behalf of ANSI

COMMENTS: Canada NO. See comments below:

Finland ABSTAIN. Lack of expertise and interest.

India ABSTAIN. Lack of expertise and interest.

Japan NO. See comments below:

Korea YES. See comments below:

Portugal ABSTAIN. Lack of expertise and interest.

Sweden ABSTAIN. Lack of expertise and interest.

Germany ABSTAIN. Lack of expertise and interest.

United Kingdom NO. See comments below:

United States NO. See comments below:

Canadian Comments on SC32 N2140 PDTR 19763-9 Date: 2011-10-12 Document: 1 2 (3) 4 5 (6) (7)

MB1

Clause No./ Subclause No./

Annex (e.g. 3.1)

Paragraph/ Figure/Table/

Note (e.g. Table 1)

Type of

com-ment2

Comment (justification for change) by the MB Proposed change by the MB Secretariat observations on each comment submitted

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **) 2 Type of comment: ge = general te = technical ed = editorial NOTE Columns 1, 2, 4, 5 are compulsory.

page 1 of 3 ISO electronic balloting commenting template/version 2001-10

CA01 0 All All Te Having reviewed the ISO Directives descriptions of Technical Report and Technical Specification, we believe this document would be better as a Technical Specification.

3.1.4 Technical Specification TS document published by ISO or IEC for which there is the future possibility of agreement on an International Standard, but for which at present

• the required support for approval as an International Standard cannot be obtained,

• there is doubt on whether consensus has been achieved,

• the subject matter is still under technical development, or

• there is another reason precluding immediate publication as an International Standard

Note 1 to entry: The content of a Technical Specification, including its annexes, may include requirements.

Note 2 to entry: A Technical Specification is not allowed to conflict with an existing International Standard.

Note 3 to entry: Competing Technical Specifications on the same subject are permitted.

Note 4 to entry: Prior to mid-1999, Technical Specifications were designated as Technical Reports of type 1 or 2.

Convert the document to a Technical Specification.


MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




3.1.5 Technical Report TR document published by ISO or IEC containing collected data of a different kind from that normally published as an International Standard or Technical Specification

Note 1 to entry: Such data may include, for example, data obtained from a survey carried out among the national bodies, data on work in other international organizations or data on the “state of the art” in relation to standards of national bodies on a particular subject.

Note 2 to entry: Prior to mid-1999, Technical Reports were designated as Technical Reports of type 3.

CA02 0 Foreword List of parts Ed The list of parts of ISO/IEC 19763 is missing. The fact that this part is a TR does not mean is not just as much a part of 19763.

Add the list of parts of 19763: Parts 1, 3, 5 – 12.

CA03 0 introduction Para 2 & 3 Ed The references to e-Business and e-Commerce lead to an expectation that the standard will have some relationship to ISO/IEC 15944, but no such relationship is specified.

Delete paragraph 2, and the first part of the first sentence of paragraph 3, up to the comma.

CA04 2 Normative references

Part 2 Ed Part 2 has been cancelled, Remove the reference to part 2.

CA05 2 Normative references

Part 3 Ed It is not clear the Part 6 is referenced in a way that makes it indispensable to the use of this part.

Move the reference to Part 6 to the Bibliography.

CA06 3.1 Terms and definitions

Para 1 Ed The reference to Part 2 is inappropriate since the part has been cancelled.

Remove the reference to part 2.

CA07 3.2 Abbreviated terms

- Ed MFI, UML and XML are used in the document but are missing from the list of abbreviated terms

Add MFI, UML and XML and their expansions.

CA08 4.1 Figure 1 Te This and other parts of 19763 use references between Convert the model to use associations instead of


MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




5.1 Table 2 classes, instead associations as used in 11179-3. As a result, the pairing of the references is less clear. WG2 has previously expressed a desire to align the modelling techniques of 19763 and 11179. Canada has a strong preference for associations over references.

references.

CA09 4.1 5.1

Figure 1 Table 2

Te Figure 1 shows references in one direction only. Table 2 shows different references.

The figure should show references in both directions, and the table should show references in both directions. If there is a reason why some reference should not be considered in model selection, this should be explained, but we see no valid reason to exclude any.

CA10 4.2 All Te This clause introduces the concept of Semantic Annotation and different levels of matching. Similar, but different concepts are described in 20943-5 SMMP.

The levels of matching specified in this document should be aligned with the Semantic Mapping methods described in 20943-5.

CA11 5.1 Table 2 Te 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.

Rename InvolvedBy to ‘Involves’

CA12 All Te Any other errors found before or during the Ballot Resolution meeting should be corrected if consensus can be reached on a resolution.

To be addressed at the BRM as required.

END

Japanese comments on 32N2140-CD_19763-9.pdf Date: Document: 1 2 (3) 4 5 (6) (7)

MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




JP 01

ge ge 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.

See also JP-03.

JP 02

ge ge TR19763-9 only refers to ontology annotations and relationships specified at Table2, and not to most of the information of Process and Service, except their relationships to Role and Goal. TR19763-9 should also explain how to use the information not referred to..

Moreover, MFI registries only have common semantics (essential subsets) of models outside the registries, and so, the information in the MFI registries are not enough for semantic discovery of services and/or models, and the information of the models outside is necessary. TR19763-9 should specify a guideline also on how to use it via the models in the MFI registries.

JP 03

ge ed 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


MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




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 many be used to develop relationships between them. But, they is the only ones.)

JP 04

１Scope First paragraph

ed The first paragraph should be transferred to Introduction because it states the background and objectives of ODMS.

JP 05

1 Scope Second paragraph

te “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.

JP 06

4.1 Relationships in RGPS

Figure 1 te “isInvolvedIn” should be “involvedBy” and the direction of the black triangle should be opposite.

JP 4.2 Semantic ge The description is too specific to MFI-8. Semantic Also see JP-08.


MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




07 annotation annotation seems to be important to also MFI-5 and 7.

The description should be more general so that it can be applicable to MFI-5 and 7 also.

JP 08

4.2 Semantic annotation

Table 1 te “The concept in the user request “ is not clear. If it is an ontology_atomic_construct used in annotation, it is not clear how this matching level can be decided because in each of MFI-5, 7, 8, there are several (at least two) classes that have annotation and each annotation can have many ontology_atomic_constructs.

JP 09

4.2 Semantic annotation

Table 1 te 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.

JP 10

5.1 Model selection strategies

Table 2 te ”realizedBy” should be “realizes” at (Service, Process).

JP 11

5.2 Architecture of ODMS

First sentence

ed “In this section, we will discuss…” is not an appropriate phrase, because this is not a academic paper, but a standard document.

JP 12


Last sentence of the second paragraph

te The meaning “the relationships among RGPS” needs to be clarified. They should not be only the ones specified at Table 2. All other relationships within each part of MFI-5, 7, 8 should be included.

JP 13


Last half part ge The last half part explains an implementation example on a part of ODMS. This part should be removed because:

- this implementation covers only the usage of semantic annotation and not the one of the relationships among RGPS at all;

- some of the descriptions are too specific to this implementation, such as “a slash (“/”) can be used to


MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




separate item.”

- there are several unclear points such as what happens if, for example, user request type is goal, and expected return type is service?

JP 14

Annex A ge It may be better to move whole Annex A (or at least a complex example part) to the main text because this Annex illustrates well how ODMS work and TR19763-9 is a guideline on how to use Role&Goal, Process, and Service metamodels to select appropriate combinations of models and/or services to meet users’ goals.

We need a discussion and a consensus.

JP 15

Annex A Figure A.1

Figure A.2

ed The style and format should be the same as the ones of MFI Part3 Ed2 as much as possible.

We agree that the ones of MFI Part3 Ed2 are hard to read. We need a discussion and tit may be better to develop the better ones that can be applicable to all the parts of MFI.

JP 16

Annex A Figure A.2 te Process does not have any of attribute “type”, “constructType”, reference “nodeSet”.

JP 17

Annex A A complex example

te In this example, the decompositions of Goals, Processes and Services seem to be isomorphic. It suggests that Goal, Process and Service can be consolidated to one class. We need an example that thse decompositions are not isomorphic.

Template for comments and secretariat observations Date: Oct 12, 2011 Document: N2140 1 2 (3) 4 5 (6) (7)

MB1


Annex (e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




KR01

0-Introduction Para 1 Ed The main title of ISO/IEC 19763-9 is omitted. Insert the main title, “Meta Model Framework for Interoperability (MFI)”, in the appropriate position.

KR02

0-All All Ed MFI-8, MFI-5, and MFI-7 should be more specified. Suggest to change MFI-8, MFI-5, and MFI-7 to MFI-8(ISO/IEC 19763-8), MFI-5(ISO/IEC 19763-5), and MFI-7(ISO/IEC 19763-7) respectively.

Template for comments and secretariat observations Date: 22 September 2011 Document: ISO/IEC PDTR 19763-9

1 2 (3) 4 5 (6) (7)

MB1 Clause No./ Subclause No./ Annex

(e.g. 3.1)


Note (e.g. Table 1)

Type of

com-ment2




GB 01 3.1.1 ed The definition is for the plural 'roles'. Use a singular definition.

GB 02 3.1.7 ed This clause is formatted incorrectly. Adjust formatting.

GB 03 4.1 Figure 1 te Not all associations are named with a verb for the association itself and no metaclass involved in the association has a role name (noun), as agreed in Hawaii.

Provide association names and role names throughout.

GB 04 5.1 Table 2 and associated text

te In this table the column headings and the row 'headings' are the same, and it is unclear what this table is trying to show.

Provide clarification.

GB 05 5.1 Table 2 te At the Goal/Goal intersection there is an '/' included without any explanation as to its meaning.

Provide explanation.

GB 06 6 Figure 10 ed On the copy available to us this figure is obscured.

Comments on CD1 Text For: ISO/IEC PDTR 19763-9 Information technology — xx

Date: 2011-09-29 Document: SC32/N2140

0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2

Comment (justification for change) by the NB Proposed change by the NB Secretariat observations on each comment submitted

1 NB = National body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the Secretariat editing unit are identified by **) page 1 of 8 2 Type of comment: ge = general te = technical ed = editorial NOTE Columns 1, 2, 4, 5 are compulsory. ISO electronic balloting commenting template (enhanced 2002-08)

001 US Introduction 4th para, last sentence

ed clarify sentence “…on demand model selection so as to satisfy user requests.”

To: “…on demand model selection so as to help users discover process and service models that meet their needs.”

002 US 2 Reference 3rd para ed ISO/IEC 19763-2 should not be referenced remove reference to 19763-2 003 US 3.1 1st para ed ISO/IEC 19763-2 should not be referenced remove reference to 19763-2 004 US 3.1.1 role te use standard definition if possible to disambiguate

the meaning of role Suggestion – derive from: the expression of an object playing a part in a relationship (ISO/IEC 15476-4:2005 Information technology--CDIF semantic metamodel--Part 4: Data models, 6.5 Or a defined function to be performed by a project team member, such as testing, filing, inspecting, coding. (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) -- Fourth Edition)

005 US 3.1.2 goal te use standard IT definition of possible suggested definition for goal: intended outcome of user interaction with a product (ISO/IEC 25062:2006 Software engineering -- Software product Quality Requirements and Evaluation (SQuaRE) -- Common Industry Format (CIF) for usability test reports,

006 US 3.1.3 process te use standard IT definition if possible suggested definition for process: (1) set of interrelated or interacting activities which transforms inputs into outputs (ISO/IEC 15288:2008 Systems and software engineering--System life cycle processes, 4.16) (ISO/IEC 15939:2007 Systems and software engineering--Measurement process, 3.32)

007 US 3.1.4 service te use standard definition if possible W3C service: software system designed to support interoperable machine-to-machine interaction over a network.

008 US 3.1.5 role goal te clarify definition “descriptive statement that Suggest: “descriptive statement that



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



denotes the goals that a role is in charge of” denotes the intended outcome of a given role”

009 US 3.1.7 QoS te definition for QoS should refer to an existing standard….)

definition drawn from Quality of Service (ISO/IEC 10746-1:1998 Information technology -- Open Distributed Processing -- Reference model: Overview “nonfunctional description covering, for example, provision of timeliness, availability and reliability in the context of remote resources and interactions, together with provision of fault tolerance that allows

the remainder of a distributed system to continue to operate in the event of failure of some part.”

010 US 4.1 para 2 ed “MFI-5 Process Registry is mainly used to store the administrative information of the registered process models based on MFI process registration metamodel and corresponding relationships…” . sentence is a bit confusing

should it be “MFI-5 Process Registry is used to store the administrative and descriptive information of registered process models. The information recorded in the process model describes the corresponding relationship to the other types of MFI registries.”

010 US 4.1 para 3 ed “MFI-7 Service Registry is mainly used to store the administrative information of the registered services based on MFI service registration metamodel and corresponding relationships…” . sentence is a bit confusing

should it be “MFI-7 Service Registry is used to store the administrative and descriptive information of registered service models. The information recorded in the service model describes the corresponding relationship to the other types of MFI registries.”

012 US 4.1 para 4, 1st sentence

ed “MFI-8 specifies a metamodel for registering users’ roles and goals information in specific domains” sentence is a bit confusing

suggested change: MFI-8 specifies a metamodel for registering the users’ of a service or process roles and



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



goals in industry specific domains”

013 US 4.1 para 4, 3rd sentence

ed “MFI-8 Role and Goal Registry is mainly used to store the administrative information of the registered role and goal models based on MFI service registration metamodel and corresponding relationships…” . sentence is confusing

should it be “MFI-8 Service Registry is used to store the administrative and descriptive information of registered role and goal models. The information recorded in the role and goal model describes the corresponding relationship to the other types of MFI registries.”

014 US 4.1 para 5 ed “RGPS is viewed as a generic term referring to the method of applying metamodels in MFI and the relationships among them into ODMS” sentence is confusing

Suggest: “RGPS is viewed as a generic term referring to the method of applying relationships among MFI model to support ODMS.”

015 US 4.1 para 6, 3rd sentence

te The notion of decomposing goal is discussed, but not readily depicted in Figure 1. “The goal decomposition process does not end until the leaf-level subgoals are operational goals.

Illustrate goal decomposition or describe it better in the text

016 US 4.1 para 6, 2nd sentence

te “To sum up, roles take charge of their corresponding role goals, and actors prefer their respective personal goals” sentence is too vague

suggest: “From RGPS perspective, a role … (describe what is meant by ‘takes charge of their corresponding role goals” give an example – how does this differ from an Actor preferring a Personal Goal)….does the Role have some expected Goals that the Actor has no control over?

017 US 4.1 para 8, ed refine the paragraph: “To facilitate the model selection, the relationships in RGPS should be recorded.”

Suggest: “To facilitate ODMS, the Roles and Goals specific to the domain should be registered in the Role/Goal MFI-8 Registry, and the relationships between a process and its roles and goals, and a service and its roles and goals should be recorded in the Process (MFI-5) and Service (MDI-7) Registries.”

018 US 4.1 Figure 1 te inconsistency … figure 1 does not depict the resource, event, input and output classes that are



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



in figure 2 019 US 4.2 Figure 2 te figure 2 does not show a relationship between

Process and Goal so its hard to understand how annotation of the Goal operation and object with ontology concepts will result in linking the Process to the Goal.

020 US 4.2 paragraph 1 Ed “An essential issue in ODMS is how to match user requests with registration information of models in MFI registries. Semantic annotation for these registered models based on domain ontologies can be used to

bridge the gap between them” elaborate for clarity

An essential issue in ODMS is how to match user requests with information in MFI registries. The use of semantic annotation of registered models that has been based on domain specific ontologies can be used to bridge the gap between the different MFI models.

021 US 4.2 Paragraph 2 I think the use of ontologies for determining synonyms has been conflated with the use of the ontologies to annotate the registered models with unique concept identifiers and then using those identifiers to find matching registered items in the different MFI registries. When the models have been annotated with unique concepts, then matching a Role/Goal with a Service’s role or goal is automated by looking for matching concept identifiers on those classes. The ontology can also be used to query using synonyms to find the right concept before searching for a role/goal process or service that fits meets the users needs, but the notion should be that the same ontology is used to annotate all MFI models and thus serves as the ‘glue’ relating them to each other.

Suggest rewriting the paragraph to explain how using the onotology to annotate all parts of MFI allows the ontology to hold together the relationships between the registered models. “In order to semantically annotate role and goal models in MFI-8, two kinds of domain sub-ontologies, entity ontology and operation ontology, are considered (Figure 2). The entity ontology mainly describes the entity concepts and semantic relationships among them and the other parts of RGPS for the domain, and an operation ontology mainly describes the operational or functional concepts as well as



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



semantic relationships to the other parts of RGPS for the same domain. When registering the Process Models in MFI-5, the same ontology is used to annotate the Goals achieved by the Process. For example, given a transportation industry Goal with attributes <operation, object >. operation annotated by a concept in the transportation industry operation ontology while object would be annotated by concepts in the transportation entity ontology “Book Ticket”, and a Process Model annotated with “Book Ticket”. A user searching for a goal “Reserve a Ticket” might find the Goal annotated with “Book Ticket” and then search the MFI-5 registry to find a process that would facilite this operation. Using the same ontology to annotate both models allows the ontology to provide semantic support for matching a Goal with a Process. In other words, the goal “Reserve Ticket” can be found to be a synonym in the ontology for “Book a Ticket and the user can search for Processes that satisfy the user request “Book a ticket”. Similarly, the attributes of role, process, resource, service, input and output in RGPS can also be



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



semantically annotated by domain ontologies. The annotation relationships between ontology and the RGPS model constructs

should be recorded in each registry. 022 US 4.2 paragraph 3 Ed/te The next section describes how ontologies work

and should be framed that way. Essentially the section describes how ontologies are described using terms such as equivalentTo, subclassOf, superclassOf etc to help a user find the correct concept. Once the concept is found, then the query goes against the MFI registry.

Revise paragraph 3 to explain that it is describing how an ontology is used to support semantic queries.

023 US 4.2 paragraph 3 ed references to the figure should use the same string for the names of the items as used in the figure. process model

should be: process_model

024 US 4.2 paragraph 3 ed this comment applies to much of the text, it needs to be edited to improve the sentence structure to better convey the meaning of the sentences. “During the model selection, the concepts in models that are annotated by domain ontologies, such as…can be viewed as the matching items between user requests and the candidate model.”

suggested text: During model selection, the classes that are annotated by domain ontologies, such as….are the targets of queries by end users to support model discovery.

025 US 4.2 paragraph 3 ed another example of a sentence in which the language used needs to be simplified/clarified: Based on the subsumption relationship among concepts in domain ontologies, the matching level for model selection can be defined, as

Better: Based on the relationships defined between concepts in domain ontologies, the quality, or type of a match for query selection can be defined, as



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



shown in Table 1. shown in Table 1. 026 US 4.2 Table 1 ed There should be 3 column headings in Table 1

instead of two. Matching level between the user request and the candidate models | Related Description

Proposed fix: Type of Match | Web Ontology Relation | Description

027 US 4.2 Table 1 ed use the owl language for the Web Ontology Examples in Table 1 Exact Matching | equivalentTo | | subclassOf |

etc..

Proposed fix: ______________________________ Exact Match | owl:equivalentTo | | owl:subclassOf | Fuzzy Match | owl:superclassOf | owl:part of Mismatch | no relationship found

Etc…

028 US 4.2 paragraph 3 ed clarify sentence: When users submit their requests, they can also submit the expected matching level, such as exact matching (equivalentTo, subclassOf) or fuzzy matching (superclassOf / partOf). For example, the matching level between “ Book Ticket ” and “ Reserve Ticket ” mentioned above belongs to the “equivalentTo” matching level.

Proposed fix: To support an ODMS query, the interface should specify the type of match, such as “Exact Match” or “Fuzzy Match”. For example, the type of match between “Book Ticket” and “Reserve Ticket” mentioned above is an “Exact Match“ based on the presence of an owl:equivalentTo between “Book” and “Reserve” in the domain ontology.

029 US 5 Clarify the sentence: As the basis of model selection, the registered models should be semantically

Proposed fix: The basis for model selection is domain ontologies. Registered



0 1 2 (3) 4 5 (6) (7)

# NB1


Annex


Note #

Com- ment type2



annotated by domain ontologies and associated by the relationships in RGPS. And then, according to users' requests and corresponding selection strategies, appropriate models can be selected using the registration information of

models.

models are annotated using domain ontologies and each MFI model defines the classes and relationships between the model and the other parts of MFI. For example, a Process registered using MFI-5 needs to define a class for the Goal it achieves and annotate that class with a concept from the domain specific operation and object ontology such as “Reserve Ticket”. The, according to users' queries and corresponding selection strategies (Exact Match, Fuzzy Match), appropriate models can be selected using the concept annotation of the models and the domain specific ontology to expand the query.

030 US 5.2 paragraph 3

and 4 and figure 4

ed/te The purpose of “Request Description” is not clear. Please provide a more complete example

031 US 6 Figure 10 ed/te The text in Figure 10 is not readable and thus could not be reviewed.

Revise figure.

032 US General throughout document

ed Since MFI includes MFI-3 Ontology Registration, it might make sense to mention that the domain ontology used to annotate the models might be one that has been registered by MFI-3.

iso/iec jtc 1/sc 32 n 2165jtc1sc32.org/doc/n2151-2200/32n2165-summ_of_voting-n2140-pdtr...iso/iec...

Documents