Short Version: The mofext tags at the end of the emof file are incorrect. The existing namespace prefix (nsPrefix) declarations need to be corrected and also need to be supplemented with additional mofext that include namespace URI (nsURI) declarations. Also consider changing the format of the FACE 3.0 namespaces to use the "#" separator, e.g. http://www.opengroup.us/face/3.0#platform

Details:
(from Pete Rivett) The URI property represents the identifier of the metamodel. This URI property, though it’s used by default for the interchange namespace, can be overridden to specify the namespace used for interchange. If you want to keep the opengroup website for the XML namespace, that is specified using the nsURI MOF tag I mentioned. It accompanies the tags you’re already using for the nsPrefix, which appear at the end of the file:, though they are currently wrong - the nsPrefix name must be itself prefixed org.omg.xmi. as shown below.

You’d need to declare a nsURI (namespace URI) for each nsPrefix (namespace prefix, you have 6), I just show the first, the others will just differ in the last line for the element and the value.

<!--- Original Text at end of emof file --->
<mofext:Tag xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmi:type="mofext:Tag"
xmi:id="_19_0_2_157603d2_1581698299484_395395_5638_nsPrefix" name="nsPrefix"
element="datamodel-platform" value="platform"/>

<!--- This is the recommended replacement text from Pete. --->
<mofext:Tag xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmi:type="mofext:Tag"
xmi:id="_19_0_2_157603d2_1581698299484_395395_5638_nsPrefix" name="org.omg.xmi.nsPrefix"
element="datamodel-platform" value="platform"/>

<mofext:Tag xmlns:mofext="http://www.omg.org/spec/MOF/20131001" xmi:type="mofext:Tag"
xmi:id="_19_0_2_157603d2_1581698299484_395395_5638_nsURI" name="org.omg.xmi.nsURI"
element="datamodel-platform" value=" http://www.opengroup.us/face/3.0/platform"/>

<!--- (you may instead want to use # as final separator) --->
value=" http://www.opengroup.us/face/3.0#platform"

Correct nsPrefix tags and add nsURI tags per Pete Rivett recommendation

Correct nsPrefix tags and add nsURI tags per Pete's recommendation.

No change to the URLs for the FACE namespaces, as this is a translation of the normative MOF 2.0 EMOF metamodel in the FACE Technical Standard, Edition 3.0 to MOF 2.5.1. Any changes in the resulting file format or contents due to the translation of the EMOF metamodel would violate the FACE Technical Standard.

(from Pete Rivett) There are many properties (ownedAttributes with xmi:type=”uml:Property”) that do not have types assigned to them in the .emof file. That is mandatory.

Add type declarations to ownedAttributes for which there are no types declared

Change the UML URL at the top of the file from "https" to "http"

Add (as appropriate) type declarations for attributes in the normative emof file. Type declarations are of the style:
<type href="http://www.omg.org/spec/UML/20161101/PrimitiveTypes.xmi#Boolean"/>
and valid types are: Boolean, Integer, Real, String, UnlimitedNatural

Look for comments marked "<!-- FACE-23" to find changes
79 changes made in file

Related to FACE-13. Modify the FACE Profile for UAF XMI to have the comments that reference the FACE technical standard use the same uniform string (FACE Technical Standard, Edition 3.0) as was applied to the standard document in proposal FACE-19.

Modify machine-readable FACE Profile for UAF for FACE Std Name Consistency

Change all descriptions that reference the "FACE 3.0 technical standard", "FACE 3.0 Technical Specification", or "FACE 3.0 standard" to instead refer to the "FACE Technical Standard, Edition 3.0"

(From Pete Rivette at June 22, 2020 AB review) FACE30metamodel.emof is incorrect for FACE – fix the namespace.

In discussion with Pete, he stated that the issue is that the URIs listed for the FACE metamodel schema in the FACE30metamodel.emof are faulty because they do not resolve to a "live" URL.

Discard/No Action: FACE URI does not resolve in emof

Discard this issue / Resolve with no action. There is no requirement for namespace URIs to resolve to "live" sites.

The XMI 2.5.1 specification (https://www.omg.org/spec/XMI/2.5.1/PDF), page 16, section 7.8.1 states, "“There is no requirement or expectation by the XML Namespace specification that the logical URI be resolved or dereferenced during processing of XML documents.”

(From Pete Rivette) Use same naming conventions for FACE Technical Standard throughout document (some inconsistencies)

Use "FACE Technical Standard" uniformly

Ensure that all references to the "FACE 3.0 Technical Standard" are replaced with "FACE Technical Standard, Edition 3.0" and that all references to "FACE Technical Specification" are changed to reference "FACE Technical Standard".

This is a PERVASIVE change that includes changes to headings. Although not reflected in the attached file, the Table of Contents will also need to be regenerated. See attached file to view changes. To find all the locations that were changed, look for comments marked FACE-13. There were 33 changes in all.

(From Pete Rivette) Other Normative References Put the explanation about the 3.0 and 2.1 versions of the standard IN THE DOCUMENT where the two standards are listed as normative

Put explanation about both FACE versions 3.0 and 2.1 in Section 3.2

Added explanations about the reason for both the FACE Technical Standard editions 3.0 and 2.1 to be referenced into section 3.2 Other Normative References.

To find the modified text, see changes commented with FACE-12 markings in the attached file.

(From Pete Rivette) Version numbers are confusing. Clarify that FACE Profile for UAF 1.0 is a representation of the FACE Tech Standard 3.0

Add reference to FACE-UAF profile version and additional references to FACE tech std version

See attached file in proposal

In Scope / background section, explicitly state that the FACE Profile for UAF v1.0 specification defines a profile to express ... Technical Standard, Edition 3.0. In this and subsequent sections, amplify references to the FACE Technical Standard to read "FACE Technical Standard, Edition 3.0".

Adding an explicit edition indicator was appropriate for most, but not all references to the FACE Technical Standard. To find all the places where a change was made, look for comments marked "FACE-11".

Also changed some existing "FACE 3.0 Technical Standard" strings to "FACE Technical Standard, Edition 3.0" for consistency.

(From Pete Rivette) Add explicit acknowledgement that FACE is a trademark of The Open Group

FACE Trademark ownership already indicated in footnote

In section 1. Scope, there is a footnote after the first reference to the trademarked FACE reference on the first line of the paragraph. The corresponding footnote at the bottom of page 2 states "FACE™ is a trademark of The Open Group®."

There are two FACE Metamodel files in this submission. One is the FACE Metamodel as it appears in the FACE Technical Standard, Edition 3.0, and uses the XMI 2.0 notation. The other is not an official product of The Open Group, but is a derivative product that represents the FACE Metamodel (Edition 3.0) using XMI 2.5.1. This file was generated in response to OMG review comments that the older version of XMI was not acceptable for a Normative file. Because the FACE Metamodel file is normative per the FACE Technical Standard it should remain Normative. The derivative file that uses XMI 2.5.1 is not official and should therefore be marked as Informative.

Add clarifications to descriptions of FACE Metamodel Files

Make the following changes to Table 1-1:

• Add a new row to Table 1-1 describing the normative FACE metamodel file.
• Change all instances of "normative" in the row referencing the FACE Metamodel EMOF 2.5.1 File to "informative".
• Change the name of the referenced FACE Metamodel EMOF 2.5.1 File to "FACE metamodel 3.0 EMOF 2.5.1.emof"

The XMI file c4i-20-05-06 has the old name space for UML and the standard profile namespace is wrong.

Replace UML URL to reference (current) UML 2.5.1 xmi

Replace all instances of "http://www.omg.org/spec/UML/20131001" with "http://www.omg.org/spec/UML/20161101"
192 replacements in total

Original references were the result of generating XML file using MagicDraw Strict UML XMI Exporter v17.0 SP2. No action taken with Dessault/NoMagic to resolve the underlying cause of the issue.

The emof file c4i-20-05-05 has an old UML namespace instead of https://www.omg.org/spec/UML/20161101

Replace UML URL to reference (current) UML 2.5.1 xmi

Replace "http://www.omg.org/spec/UML/20131001" with "http://www.omg.org/spec/UML/2016110"

(From JD Baker) I’m not sure how I feel about issues to be discussed as part of the specification. At the least this section needs to be flagged as non-normative

Mark Design Considerations as Non-Normative

Response to comment received at AB prior to FTF formation.

See Section 8. Design Considerations, page 201 for changes.

(From JD Baker) I’m not sure how I feel about issues to be discussed as part of the specification. At the least this section needs to be flagged as non-normative

(Sarah Douglass remarks) This section was added to respond to "Issues to Discuss" in the RFP. The standard did not include responses to these issues anywhere else. The Issues To Discuss topics are mostly discussion of the value of the standard, with some additional discussion about the approaches implementers might take to address OCL correctness of FACE data as described in the specification and the FACE 3.0 standard.

(from JD Baker) Section 3.1 – several OMG documents are not the latest versions. Is this intentional and if so, why?
Unified Modeling Language UML® 2.5.1 formal December 2017
Meta Object Facility MOF™ 2.5.1 formal October 2016
Diagram Definition DD™ 1.1 formal August 2015
Unified Architecture Framework UAF 1.1 formal April 2020

Fix incorrect references to normative OMG Documents

Response to comment received at AB review prior to formation of FTF.

See Section 3.1 OMG Documents (Normative References), page 5 for changes.

Original comment:
(from JD Baker) Section 3.1 – several OMG documents are not the latest versions. Is this intentional and if so, why?
Unified Modeling Language UML® 2.5.1 formal December 2017
Meta Object Facility MOF™ 2.5.1 formal October 2016
Diagram Definition DD™ 1.1 formal August 2015
Unified Architecture Framework UAF 1.1 formal April 2020

(Original comment from JD Baker) Table 1.3 has OMG document numbers that have a high likelihood of changing in the formalization process. Please remove them in the FTF.

There is no Table 1.3. Interpreting to mean Table 1-1 in section 1.3.

Remove related document numbers from section 1.3

Response to comment received at Proposal review prior to FTF charter.
See section 1.3 Related Documents on page 3 for changes.

(Original comment from JD Baker) Table 1.3 has OMG document numbers that have a high likelihood of changing in the formalization process. Please remove them in the FTF.
(Sarah Douglass) There is no Table 1.3. Interpreting to mean Table 1-1 in section 1.3.

Update headings of the DMM title page and make Normative, also align heading of appendix C to be Informative

Update headings of the DMM title page and make Normative, also align heading of appendix C to be Informative

"modify tile page dtc-17-04-07 with the appropriate fonts and
add (Normative) to the title page
centre justify title
moved appendix a, down to left justify and modify font
modify text on dtc-17-04-08 from Non-normative to Informative

Add section in report for adding the AffectsInContext element
Add Constraints in report for OwnsRiskElement
Modify report to reference UAF-38 issue error

Minor modifications on UAF-37 to complete FTF

Add section in report for adding the AffectsInContext element
Add Constraints in report for OwnsRiskElement
Modify report to reference UAF-38 issue error

Class Library Definition needs to be updated from

“A library of Measurements, MeasurementSets and SecurityAttributesGroup, derived from DoDAF.”

to

“A library of Measurements.”

Class Library Definition needs to be updated

Class Library Definition needs to be updated from

“A library of Measurements, MeasurementSets and SecurityAttributesGroup, derived from DoDAF.”

to

“A library of Measurements.”

security controls are currently stereotypes from UML Activity. Refactor and rename: current UML activity stereotype to be renamed SecurityProcess or SecurityActivity and refactor old SecurityControl element to be a stereotype of a SysML requirement type with a potential subtype of Information security control.

Modfiy the type of the security control element

security controls are currently stereotypes from UML Activity. Refactor and rename: current UML activity stereotype to be renamed SecurityProcess or SecurityActivity and refactor old SecurityControl element to be a stereotype of a SysML requirement type with a potential subtype of Information security control.

This proposal has had its formatting improved to make it easier to read.

ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram.

ActualEnduringTask and ActualRisk are missing from the ActualPropertySet diagram

need to add ActualEnduringTask and ActualRisk to ActualPropertySet

The Project Activity element was left out of the UAF 1.0 specification. This was previously in section 8.3.1.2.1.3 ProjectActivity of the UPDM 2.1 specification.

Modify DMM and Profile to have Project activties and associated views

Modify DMM and Profile to have Project activties and associated views

The Project activity views were left out of the UAF 1.0 specification. There were in the section 8.3.1.2.1.3 ProjectActivity of the UPDM 2.1 specification.

this is a duplicate of UAF43 but creating it as duplicate is causing problems

this is a duplicate of UAF43 but creating it as duplicate is causing problems

I see capability is defined as “A high level specification of the enterprise's ability to execute a specified course of action.” Not sure I like it. If you said ‘A high level specification of something that enables the enterprise's ability to execute a specified course of action I would be a whole lot happier.

The DODAF definition of capability is “The ability to achieve a Desired Effect under specified (performance) standards and conditions through combinations of ways and means (activities and resources) to perform a set of activities.” I think this is a better definition, but again, the way its represented in their meta model it would be better described as “A thing that adds to The ability to achieve a Desired Effect under specified (performance) standards

The way both “official” definitions are worded I don’t think there is anything that is “countable” and therefore there is nothing that exists as an item to be captured in a structured model. I would argue that the chanes is needed to make the items countable and to then appear in a UML model and also question why competing definitions are necessary.

Capability Definition

modify Capability definition

these are all the same, define once. profile: class library, elements called ExchangeProperties, SecurityCategoryProperties, SecurityControlProperties all have properties called criticality.

three properties called criticiality

a) criticality and interoperabilityLevelAchievable needs to be removed from ExchangeProperties. Need to think about backward compatibility.
b) rename criticality : String[1] to priorityofControl for SecurityControlProperties
c) update Security Taxonomy diagram by adding information and data elements
d) remove ClassificationType enumerated list
e) ExchangeProperties - remove: classificationCaveat, criticality, interoperabilityLevelAchievable, protectionDuration, protectionDurationCode, protectionSuspenseCalendarDate, protectionTypeName, releasability, Taxonomy,
f) remove InformationAssuranceProperties
g) rename SecurityCategoryProperties to SecurityImpactProperties
h) SecurityAttributes rename to Classification Attributes
i) Check if SecurityAttributes are up to date
j) Review definitions

Security Confidentiality missing from UAF-DMM see package Security, DMM has availability and integrity but not confidentiality.

Duplicates existing Issue

Duplicates existing Issue

There multiple occurrences of legacy terms in the spec.
1. Strategic Structure has a completely wrong definition (copy/paste) error. - 147
2. Operational Taxonomy definition needs to be reviewed - 152
3. OperationalPerformer Owners added as a stakeholder on page 151
4. "identifies the operational exchange requirements between NODES" - 151
5. "logical nodes" - 155
6. Operational Connectivity - "nodes"- 155
7. Information Element definition - "are capable of performing" change to "are Capable to perform" - 70
8. Resource structure BDD is missing from implementation methods - 181
9. Function definition p. 98 "of" to "to"
10. Figure 176 – ActualProject is missing relationship

Minor modifications to descriptions and some diagrams

There multiple occurrences of legacy terms in the spec.
1. Strategic Structure has a completely wrong definition (copy/paste) error. - 147
2. Operational Taxonomy definition needs to be reviewed - 152
3. OperationalPerformer Owners added as a stakeholder on page 151
4. "identifies the operational exchange requirements between NODES" - 151
5. "logical nodes" - 155
6. Operational Connectivity - "nodes"- 155
7. Information Element definition - "are capable of performing" change to "are Capable to perform" - 70
8. Resource structure BDD is missing from implementation methods - 181
9. Function definition p. 98 "of" to "to"
10. Figure 176 – ActualProject is missing relationship

Change "process" to "processes" or "transform" in view definitions for Op-Sr and probably Rs-Sr

Change "process" to "processes" or "transform" in view definitions

Change "process" to "processes" or "transform" in view definitions for Op-Sr and probably Rs-Sr

If I want to populate an L3 diagram I am asked for an operational exchange item and this quickly ends up in a selection of information elements.
When I create state machines the only trigger I can make use of is a signal event if I need to handle asynchronous information flowe. This to me indicates that the only way to tie the two together would be to create the same amount of information elements as there are signals and allow the signal to have a single parameter typed by the information element. This would allow me to create a trigger based on the signal and also get an operational exchange item that points to the information element by the same name.

To me this seems somewhat redundant. The question is therefore whether exchange should also be allowed to be a signal in order to open up the possibility of a consistent way of dealing with with state machines and other types of diagrams.

*Add signals to UAFP *

Add signals to UAFP at the operational and resource levels.
Add descriptions to the elements
Modify relevant diagrams

Old Definition:
“A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Software related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems.”

New Definition:
“A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. "

A type of risk is Information security risk: "Those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.”
users can define subtypes of risk to include Information security risk, cost risk, schedule risk, etc. UAF will define only Risk.

definition for element Risk includes Information security risk definition.

Old Definition:
“A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. Software related security risks are those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems.”

New Definition:
“A statement of the impact of an event on Assets. It represents a constraint on an Asset in terms of adverse effects, with an associated measure. The measure is used to capture the extent to which an entity is threatened by a potential circumstance or event. Risk is typically a function of: the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. "

A type of risk is Information security risk: "Those risks that arise from the loss of confidentiality, integrity, or availability of information or information systems and reflect the potential adverse impacts to organizational operations (i.e., mission, functions, image, or reputation), organizational assets, individuals, other organizations, and the Nation.”
users can define subtypes of risk to include Information security risk, cost risk, schedule risk, etc. UAF will define only Risk.

needs a space in the header line
<?xml version="1.0" encoding="UTF-8"standalone="yes"?>

note the space between 8" standalone, below
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

Missing an XMI version
needs a second line that looks like this
<xmi:XMI xmi:version="2.xx" where xx is the precises xmi version

small errors in UAF XMI

needs a space in the header line
<?xml version="1.0" encoding="UTF-8"standalone="yes"?>

note the space between 8" standalone, below
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

Missing an XMI version
needs a second line that looks like this
<xmi:XMI xmi:version="2.xx" where xx is the precises xmi version

The Scope of the work does not fulfil the requirements of the Scope statement at the start of the document. In integrated architecture can only exist if the full context of the organization/business/enterprise is described. This necessitates understanding Purpose, the strategic environment, (not just operational things like weather, light, but political, social, economic ), their associated forces and drivers and the role of value. Everything in this document is dependant on this context and all of it is ignored.

Based on a list of the participants I understand why these shortfalls exist, NATO does not create strategy, either does Canada DND, US DOD, strategy is created in Brussels, in the White House. These are the Board of Governors for their organizations.

An integrated architecture description requires that that a Systems View that concerns an understanding of a system by examining the linkages and interactions between the components that comprise the entirety of that defined system, it cannot be done by working just with the pieces. I am a business architect. I am concerned with the form and nature of the enterprise system, with mergers and acquisitions and their impact on capability, value creation and deliver, control (also completely missing from the framework), and none of these things are represented.

Also a huge disappoint is that the integration between process and information (BPMN and ERD) is not achieved. This is critical to execution

Scope

a) Strategic Domain allows to capture strategy, e.g. Enterprise Goals, Vision, Capabilities, Enduring Tasks, etc. UAF also allows to model Requirements and associate any UAF element to them.
b) Mergers and acquisitions can be captured in Operational Domain
c) BPMN compliance mode allows BPMN to be used to capture Operational Processes. Data objects in BPMN can be typed by Information Elements that can be further detailed in ERDs.
d) Most of the questions can be addressed using BMM. Combining BMM to UAF was not a requirement for UAF 1.0. This might be considered in the future versions of the standard.

Architecture in the diagram for Exhibits is not needed. It duplicates the tags on the Operational and Resource Architecture elements.

Architecture removed from the diagram for Exhibits

Architecture is related to Enterprise Phase by specific tags. Having exhibits relationship for the same purpose duplicates this capability and confuses end user. As a resolution Architecture is removed from Exhibits diagram.

It is Actual Enduring Task that is implemented by Operational Activities. Not the Enduring Task.

Implements removed from Enduring Task diagram

Implements relationship links Operational Activity to Actual Enduring Task not the Enduring task as it is depicted in diagrams for Enduring Task and Implements. As a resolution Enduring Task is removed from Implements diagram and Implements is removed from Enduring Task diagram.

This issue is related to multiple UAF classes and stereotypes but will be illustrated with “Organization” and “ActualOrganization”.

UAF contains a taxonomic structure defining useful concepts such as person and organization. These are then represented in UML & SysML and the UAF Profile. Other concepts (e.g. CommunicationsLinkProperties) are represented in a library of concepts. Our recommendation is to use the library of concepts approach more consistently and to have a much smaller profile.

There are multiple ways concepts like “Person” or “Organization” can be represented in UML/SysML: as classes, instances or stereotypes. UAF has chosen stereotypes.
The most common way to use UML would be to define a class (Or sysML Block) “Organization”. Instances of that class would be instance specifications such as “International Maritime Organization:Organizaiton”. Particular kinds of organizations would subclass “Organization”, for example “Corporation” may subclass “Organization”. Thus concepts like people and organizations are contained in UML models as classes. Such models may be standardized, reused and extended. This part of UML is well understood and quite functional. For an instance model, such a type is easily used as in “Object Management Group:Organzation”.

UAF has chosen to make each such concept into a pair of stereotypes e.g. <<Organization>> and <<Actual Organization>>. This makes “Organization” and even “Actual Organization” essentially metatypes instead of Supertypes and instances as one would expect in a UML class model. Another interpretation of a stereotype is as a “archetype” which is essentially a distinguished supertype – everything marked with such a archetype is a subtype of the archetype. However UAF stereotypes seem to represent metatypes, not Supertypes or archetypes.

The representation of the UAF taxonomy as stereotypes rather than a class model of Supertypes does not seem to have any clear advantage in terms of defining the concepts. Potential reasons would be: 1) To make the UAF concept appear in the class box, eg, "<<Organization>> Civil Defense Organization". Another may be to allow tools to apply special rules to these types. Both of these effects could be achieved with tooling enhancements referencing a class model. Disadvantage of using stereotypes are: 1) That it makes the taxonomy harder to extend & more brittle. 2) That it makes the UAF profile much larger 3) It requires special UAF tooling. 4) It ends up replicating some built-in UML concepts. 5) Complexity 6) Increased learning curve.

Recommendation: The UAF taxonomy should be represented as a normal UML class hierarchy that is part of the UAF standard – a library of concepts. User models may subclass these concepts as needed – this is simple and semantically clear. The “Non Actual” taxonomy may be removed as the classes are types (non actual) and instances of these classes would be “actual”. Having a class hierarchy for UAF concepts would be reusable with no dependence of any other part of UAF or SysML.

Option: If additional tooling help is required, stereotypes may be defined for distinguished classes in the taxonomy, with the same name. These stereotypes would simply mean that the user defined class is a (direct or indirect) subtype of the UAF defined class. Such stereotypes are sometimes thought of as “Archetypes”. Using this mechanism, there is no reason to define both “Organization” and “ActualOrganization” as UML already has a mechanism to define an instance for any class. Archetype stereotypes would retain more compatibility with Beta UAF.

Taxonomy as stereotypes rather than a class library

Not in the scope of FTF.
1. We cannot redefine the foundation in the scope of the FTF
2. The change in foundation would destroy compatibility with previous versions of the standard
3. Hard for modelers to understand and use

This issue applies to several UAF classes & stereotypes but will be illustrated with two – “Person” and “ActualPerson” as defined in UAF…
UAF::Person: A type of a human being used to define the characteristics that need to be described for ActualPersons (e.g. properties such as address, telephone number, nationality, etc).
UAF::ActualPerson: An individual human being.
We also note a common definition (dictionary.com): 1. a human being, whether an adult or child: 2. a human being as distinguished from an animal or a thing.

Therefor the common concept for the term “Person” is what is defined in UAF as “ActualPerson”. This pattern is consistent in UAF. While consistent it would seem confusing to most.

What then, is a UAF::Person? What is a “Type of human being”? Nationality? Age? Capability? These are things one would expect as properties of a person type. We don’t normally recognize subtypes of people.

Perhaps UAF::Person is a role or phase of a person like “Policeman” or “Teenager”? If so, this would seem to conflate the concept of person with roles they play, and UAF already provides for roles?

Perhaps it is an extension mechanism, just there to add properties or relationships not in UAF? If so, would not a simple subclass suffice?

Consulting the example for guidance we see “<<Person>> Marine Radio Operator”, <<Person>> Qualified Lifeboat Driver”. These are clearly roles of a person. Clearly separating what an entity is (A person) from roles they play (Marine Radio Operator) is fundamental to good architecture at any level.

Recommendation 1: UAF should clearly distinguish rigid(a) types (like “Person”) from non-rigid(a) roles and phases. Name the classes and stereotypes appropriately using terms like role and phase. Have a unifying concept of “A role of something”, add “Role of a person” only if clarifying.

Recommendation 2: UAF should use the common term for entities – e.g. “UAF::Person” should correspond to what is currently UAF::ActualPerson. If there is a necessity for a metaconcept, that concept should have a specialized prefix or suffix such as “Type”, “Kind” or “Role”.

Recommendation 3: Should it be required to add properties to a type like “actual person”, just use generalization – no additional mechanism should be required.

(a): Terms referenced are defined in: http://doc.utwente.nl/50826/

What is a “Person”?

The agreed naming convention in UAF is to name all instances as "Actual something", e.g. "Actual Person". And to name types just simply like Person. We are not using "Type" to name types.
Changing naming convention would destroy compatibility with previous versions of the standard and would confuse current users.

You have a package called information for data model (perspective or domain). you have another package also called information under metadata package (and others). Should rename the second one to information metadata just to make them distinguishable.

use of same term.

Does not affect the specification,
Package Information set by the namespace context of the owning package.

Resources Connectivity diagram is missing Function, Function action, Function control flow, Function object flow.
Diagram needs to be updated and aligned to Operational Connectivity diagram

Resources Connectivity diagram is missing activity diagram elements

This was fixed in a previous version of the specification

Typo: the DMM model for Service taxonomy states secific where it should be specific.

The DMM model for Service Taxonomy states secific where it should be specific

Cannot find the error in the documentation or model]

Found it in the model the following day and modified it.

Section 2.1.1 of Appendix C (c4i/16-05-04) contains multiple broken links:

1. "Search and Rescue Framework for the United Kingdom of Great Britain and Northern Ireland, Queen’s Printer and
Controller, June 2002". This document is no longer available at the given URL: http://www.mcga.gov.uk/c4mca/mcga-uk_sar_framework_document.pdf redirects to the UK maritime and coastguard agency main page. The current version of the document seems to date from April 2008, and is available at this link: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/291770/mca_uksar.pdf

2. “MODAF: Examples: Search and Rescue Example” and the corresponding files are no longer at
http://www.modaf.org.uk/file_download/33/SAR.zip

3. http://www.modaf.org.uk/vExamples/163/search-and-rescue-example also does not work (although the Internet Archive has two snapshots of this page from 2008, it turns out that the page has little content: http://web.archive.org/web/20081120133043/http://www.modaf.org.uk/vExamples/163/search-and-rescue-example).

4. On a more positive note, "ON SCENE - The Journal of U. S. Coast Guard Search and Rescue. Summer 2008, Exceptional SAR Stories” is available online at this link: https://www.uscg.mil/hq/cg5/cg534/On%20Scene/OSSum2008.pdf

(Reported by Andrew Watson on behalf of Cary Cupka <cary@cupkafamily.com>).

Multiple broken links in Appendix C section 2.1.1

1. "Search and Rescue Framework for the United Kingdom of Great Britain and Northern Ireland, Queen’s Printer and
Controller, June 2002". This document is no longer available at the given URL: http://www.mcga.gov.uk/c4mca/mcga-uk_sar_framework_document.pdf redirects to the UK maritime and coastguard agency main page. The current version of the document seems to date from April 2008, and is available at this link: https://www.gov.uk/government/uploads/system/uploads/attachment_data/file/291770/mca_uksar.pdf
2. “MODAF: Examples: Search and Rescue Example” and the corresponding files are no longer at
http://www.modaf.org.uk/file_download/33/SAR.zip
3. http://www.modaf.org.uk/vExamples/163/search-and-rescue-example also does not work (although the Internet Archive has two snapshots of this page from 2008, it turns out that the page has little content: http://web.archive.org/web/20081120133043/http://www.modaf.org.uk/vExamples/163/search-and-rescue-example).
4. On a more positive note, "ON SCENE - The Journal of U. S. Coast Guard Search and Rescue. Summer 2008, Exceptional SAR Stories” is available online at this link: https://www.uscg.mil/hq/cg5/cg534/On%20Scene/OSSum2008.pdf

Make all specific references to SysML comply with the specification's normative reference to SysML 1.4 (see Section 3.2).

The following three (3) sections and four (4) errors refer to SysML 1.3. They should refer to SysML 1.4

(1) Section 1.2 Intended Users (page 3) has one (1) error. It says,
"This document specifies a SysML v1.3 profile to enable practitioners to express architectural model elements and organize them in a
set of specified viewpoints and views that support the specific needs of systems engineers in the defense and manufacturing
industries."
AND
(2) Section 2.Conformance (page 5) has one (1) error. It says,
"UAFP 1.0 specifies one level of compliance corresponding to supporting a SysML TM profile using SysML v 1.3."
AND
(3). Section 6.2 Language Architecture (page 11) has two (2) errors. It says,
" The UAFP specification reuses a subset of UML 2 and SysML 1.3...
This specification documents the language architecture in terms of the UML 2 and SysML 1.3 parts..."

All sections and page numbers refer to: http://www.omg.org/members/cgi-bin/doc?c4i/16-05-01.pdf

SysML Version

Make all specific references to SysML comply with the specification's normative reference to SysML 1.4 (see Section 3.2).

The following three (3) sections and four (4) errors refer to SysML 1.3. They should refer to SysML 1.4

(1) Section 1.2 Intended Users (page 3) has one (1) error. It says,
"This document specifies a SysML v1.3 profile to enable practitioners to express architectural model elements and organize them in a
set of specified viewpoints and views that support the specific needs of systems engineers in the defense and manufacturing
industries."
AND
(2) Section 2.Conformance (page 5) has one (1) error. It says,
"UAFP 1.0 specifies one level of compliance corresponding to supporting a SysML TM profile using SysML v 1.3."
AND
(3). Section 6.2 Language Architecture (page 11) has two (2) errors. It says,
" The UAFP specification reuses a subset of UML 2 and SysML 1.3...
This specification documents the language architecture in terms of the UML 2 and SysML 1.3 parts..."

All sections and page numbers refer to: http://www.omg.org/members/cgi-bin/doc?c4i/16-05-01.pdf