Merge pull request #939 from bact/caps-profile-names

Author: zvr

model/Build/Build.md

@@ -55,7 +55,7 @@ class. In addition, there must be at least three instances `Relationship`s with
 type `LifecycleScopedRelationship`, where the "scope" property must be "build"
 and the "from" property must be the Build instance.
 
-At the minimum, the build profile must contain a `hasInput`, `hasOutput`, and
+At the minimum, the Build profile must contain a `hasInput`, `hasOutput`, and
 `invokedBy` relationshipType. If an input is known to be a build configuration
 or a build tool, the `hasInput` relationshipType can be replaced by a
 `configures` or `usesTool` relationshipType.

model/Core/Classes/ElementCollection.md

@@ -11,10 +11,10 @@ A collection of Elements, not necessarily with unifying context.
 An ElementCollection is a collection of Elements, not necessarily with unifying
 context.
 
-Note that all ElementCollections must conform to the core profile even if the
-core profile is not specified in the profileConformance property.
+Note that all ElementCollections must conform to the Core profile even if the
+Core profile is not specified in the profileConformance property.
 
-If the profileConformance property is not provided, core is to be assumed as
+If the profileConformance property is not provided, "core" is to be assumed as
 the default.
 
 *Constraints*

model/Core/Properties/profileConformance.md

@@ -21,9 +21,9 @@ in the profile specific documentation and schema files.
 Use of this property allows the creator of an ElementCollection to communicate
 to consumers their intent to adhere to the profile additional restrictions.
 
-The profileConformance has a default value of core if no other
+The profileConformance has a default value of "core" if no other
 profileConformance is specified since all ElementCollections and Element must
-adhere to the core profile.
+adhere to the Core profile.
 
 ## Metadata
 

model/Core/Vocabularies/ProfileIdentifierType.md

@@ -11,7 +11,7 @@ Enumeration of the valid profiles.
 There are a set of profiles that have been defined by a profile team.
 
 A profile consists of a namespace that may add properties and classes to the
-core profile unique to the domain covered by the profile.
+Core profile unique to the domain covered by the profile.
 
 The profile may also contain additional restrictions on existing properties and
 classes defined in other profiles.
@@ -28,8 +28,8 @@ to all restrictions defined for that profile.
 
 - core: the element follows the Core profile specification
 - software: the element follows the Software profile specification
-- simpleLicensing: the element follows the simple Licensing profile specification
-- expandedLicensing: the element follows the expanded Licensing profile specification
+- simpleLicensing: the element follows the SimpleLicensing profile specification
+- expandedLicensing: the element follows the ExpandedLicensing profile specification
 - security: the element follows the Security profile specification
 - build: the element follows the Build profile specification
 - ai: the element follows the AI profile specification

model/Licensing/Licensing.md

@@ -12,10 +12,10 @@ facilitate compliance with typical license use cases.
 The Licensing profile only contains the additional requirement that any
 Software Artifact must have a `Relationship` of type `hasConcludedLicense`.
 
-Classes and Property restrictions are defined in the `SimpleLicensingProfile`
+Classes and Property restrictions are defined in the SimpleLicensing Profile
 (Classes and Properties associated with
 [license expression strings](../../annexes/spdx-license-expressions.md))
-and in the `ExpandedLicensingProfile` (Classes and Properties used for a
+and in the ExpandedLicensing Profile (Classes and Properties used for a
 fully parsed syntax tree of license expressions).
 
 There are 2 relationship types related to licensing - `hasDeclaredLicense` and