Annex to compilation of comments

COMMENT NO.	LINE RANGE	COMMENTS	RATIONALE FOR COMMENT	PROPOSED CHANGE	BP PT DISPOSITION OF COMMENT
1	93	Should the Business Entity class be the superclass of several additional classes in the metamodel, e.g. Party and Economic Resource (and maybe more)? (This would be in addition to its current subclasses.)	Why should EconomicResourceType be a Business Entity but not Party or Economic Resource or maybe some other classes?	Rationalize all classes that represent business objects into the Type Square or Dynamic Object pattern, under a set of metaclasses including BusinessEntity, BusinessEntityType, BusinessProperty, and BusinessPropertyType.	Subclasses of BusinessEntity now include: Economic Resource, Economic Resource Type, Agreement, and Partner Role. The Type Square pattern was tabled.
2	204	There is no definition of Business Entity	More precise definition of its purpose might help to clarify the preceding issue	Either define Business Entity precisely, or use the Type Square pattern as in comment #1.	Business Entity has been defined, and comment 1 resolved.
3	710-740	The collaboration diagrams were mapped to the metamodel classes as of the end of Brussels. The metamodel classes changed in V1.0 and so the collaboration diagram mappings need to be updated correspondingly.		Change the collaboration diagrams to conform to the same version of the metamodel in the same document.	Collaboration diagrams changed to the metamodel as of 6/22/00.
4	765-785	Some of the Metamodel Design Issues no longer apply due to metamodel class changes; some need to be applied to document line numbers.		Delete all Metamodel Design Issues and resolve comments 5 thru 8.	All metamodel design issues from collaboration diagrams resolved and deleted from Tech Spec document.
5	772	Issue 1.1 Recursive relationship from [Business Process Definition] to nested [Business Process Definition] no longer applies and can be deleted.		See above comment # 4(delete the issue).	Issue deleted.
6	775-777	The Auto Procurement Example requires two different recursive relationships between [Economic Resource Types] * higher and lower levels of abstraction (e.g. Component Family and Component Master); * subcomponents (e.g. bills of materials and tools). This issue applies to the diagram on line 138.	The Auto requirements will be shared by many other industries.	Add two recursive relationships to Economic Resource Type, one labeled ‘family’, the other ‘component’.	Recursive relationships added, labeled ‘classifies’ and ‘component’.
7	93	The metamodel does not specify relationships between Information Entities and Fundamental Information Entities and any of the other classes in the metamodel.	Information about metamodel classes will be sent in Business Documents, but the metamodel does not specify how this will happen.	Make Business Entity the super class of all metamodel classes where instances would be sent in Business Documents, and give Business Entity a relationship with Information Entity. If the Type Square pattern is used, the Properties have relationships with Fundamental Information Entities.	Superclass additions and relationship with Information Entity done. Type Square tabled.
8	93	Several of the metamodel classes will have complex implementations, that is, be composite objects with many parts. Should this decomposition happen in Core Components, or should at least part be done in the metamodel?		Use Type Square pattern as in Comment #1, which will include abstract properties and components in the metamodel. The details will be left to Core Components.	Tabled.
9	182-183	[Brian Hayes] Deprecated? The [RoseModel] shows Agent as an instance of BusinessServiceInterface. I don't think it is on any diagrams in the [TechSpec].
10	194-197	[Brian Hayes] Deprecated? Not part of the [RoseModel]. Has Business Activity been replaced by Business Event (see Resources and Contracts diagram). [Terry Allen] I didn't find Business Activity useful until I saw the definition of Business Transaction, which uses the concept without citing it.
11	212-215	[Brian Hayes] Not part of the [RoseModel].
12	224-229	[Terry Allen] Business Process Interface is incorrectly defined. An interface is not a definition of an interface. What is defined is a BP Interface Definition. [Brian Hayes] Is Business Process Interface supposed to be Business Service Interface?	In eCo it is straight forward to determine the mapping between a given [eCo] Business and its [eCo] Services, the Services and its [eCo] Interactions, and the Interactions and its Documents. Thus, through a service's Interactions, you know how to interact with the service. eCo Services are interfaces to a business process. Each Service offered by a [eCo] Business provides the ability for a trading partner to interact with that Business in some way.
13	231-234	[Brian Hayes] Business Rule is not part of the [RoseModel]. Has this been renamed to Business Transaction Constraint? [Terry Allen] Aside from describing choreography, there is no requirement for a Party to disclose its business rules, and most Parties would prefer not to. It does not appear that the business rule concept is used anywhere to any constructive end.
14	144	[Brian Hayes] Business Service appears in the [RoseModel]. No definition in [TechSpec].
15	144	[Brian Hayes] Business Service Interface appears in the [TechSpec] diagrams and the current [RoseModel]. No definition in [TechSpec]. Is this the same as Business Process Interface?
16	236-239	[Terry Allen] I don't understand the purpose of Business Signal. [Brian Hayes] From the eCo perspective, Business Signal and Information Flow may be redundant. I am unable to determine how they are usefully different.
17	253-255	[Brian Hayes] From a b2b e-commerce perspective, a commitment is important in the process flow (series of document interchange between services) definition. It can help define the service level agreements on the document interchanges. For example, buyer X sends a PO and supplier Y is required to respond within 48 hours.
18	257-264	[Brian Hayes] Community no longer appears in the current [RoseModel].
19	281-283	[Brian Hayes] DTDs are not sufficiently expressive. Replace DTD with "schemas." [Terry Allen] This is the Repository, but the definition isn't synched with what I hear - there is no mention of storing meta-models.	The eCo Document and Information Item Registry contains the type information for the documents define within Interactions. It is a hierarchical database that contains two sets of type definitions - one for the Documents themselves, and one for the Data Elements that are used within the Documents. These type definitions are used to classify Documents and the Data Elements within those Documents. [Terry Allen] Note that eCo envisions putting in a repository schemas (here "type definitions") and documents (not mentioned here but evident from the element name). They don't have to be the same repositories, and meta-data needs to be defined for both. The "two sets of type definitions" is not too useful a distinction, as a document schema is just another compound data element, distinguished by the author's desire that it be used as a document element (root element).
20	286-290	[Brian Hayes] Document Envelop no longer appears in the current [RoseModel].
21	312-314	[Terry Allen] there seems to be no difference between Fundamental Information Entity and Info Entity. There's nothing to say that a datatype can't have structure.			`
22	144	[Brian Hayes] Information Exchange appears in the current [RoseModel]. No definition in [TechSpec]. The model shows that a Business Transaction has an Information Exchange which as an Information Flow.
23	322-326	[Brian Hayes] The definition for Information Flow is a bit too abstract. Based on the model, I don't see why "business activities" is mentioned in the first sentence. In the second sentence, is not the "particular business document to be exchanged" also an information flow? What is the significance of mentioning this sentence as worded? The definition should also mention how information flow relates to Documents.
24	141	[Brian Hayes] Market Role appears in the current [RoseModel]. No definition in [TechSpec].
25	141	[Brian Hayes] Market Role Type appears in the current [RoseModel]. No definition in [TechSpec].
26	144	[Brian Hayes] Ordering Rule appears in the current [RoseModel]. No definition in [TechSpec].
27	336-338	[Brian Hayes] Partner does not appear in the current [RoseModel].
28	343-346	[Brian Hayes] Partner Type does not appear in the current [RoseModel].
29	353-355	[Brian Hayes] The Party Role class and the Role class do not appear in the current [RoseModel]. (Party Role is shown only as "Role" in the diagram.)
30	377-378	[Brian Hayes] Service does not appear in the current [RoseModel].
31	380-384	[Brian Hayes] Step does not appear in the current [RoseModel]. Has this been renamed to Step Definition? In any case, this definition could be easier to understand.
32	144	[Brian Hayes] Step Definition appears in the current [RoseModel]. No definition in [TechSpec]. Should the definition for Step be used?
33	84-92	The use of color coding the various lines is excellent but I (Melanie McCarthy) am concerned that many users of the document will print the document (in black/white), thus, loosing the concept.
34		Definitions have been provided for the following items that do NOT appear in the diagram: AGENT - line 182 BUSINESS ACTIVITY - line 194 BUSINESS PROCESS - line 212 BUSINESS PROCESS INTERFACT -line 224 COMMUNITY - line 257 CONTRACT TYPE - line 274 DOCUMEN			Alignment of classes to definitions should have resulted in all classes now having definitions
35		MISSING - I noticed that there was no class definition for Business Entity			It now has a definition.
36		The following definitions need to further clarify how the specific class differs from the class - Business Rules: DUALITY, INFORMATION ENTITY (assumed this is the Fundemental Information Entity), BUSINESS RULE, STEP			Business Rule (as referenced by Melanie) has been changed to Business Transaction Constraint which has the following definition: a business transaction constraint is a rule that guides and constrains the execution of business transactions within a business process. Duality is not a constraint; it is a relationship that always exists between or among Economic Event classes, such as a "pays for" link between purchase and cash disbursement. This link could itself be the subject of constraints on ordering (we don’t pay until goods are received) or constraints on cardinality (purchases can be paid in installments or all purchases must be paid for immediately upon shipment).
37		The following definitions need to further clarify how the specific class differs from the class - Agent: AGENT, PARTNER, PARTY			Agent and Partner are gone. Party and PartnerRole might be clear(er) from the new definitions.
38		An 'Economic Resource Type' sounds like something that would be included by Core Components. Yet I have never heard them discribe a CC in terms of this class			Economic Resource Type is an abstract class that covers Product, Service (in the sense of work-for-hire), FinancialInstrument, etc. Core Components PT is expected to define most of those subtypes.