The Part (Section 5.3.3.1), which takes one of three values.
Prior versions of the CPE specification(s) are currently available here, but they are not referenced further in this proposal.
Requirements
Requirement 1
UCO must constrain CPEs in cpeid to be specified as Well-Formed-Names of the current version, 2.3.
(Aside: This intentionally excludes URI forms from being used in cpeid.)
Requirement 2
UCO must constrain CPEs for Devices to use an h Part (for hardware devices).
Requirement 3
UCO must constrain CPEs for Software to use an a Part (for applications).
Requirement 4
UCO must constrain CPEs for OperatingSystem to use an o Part (for operating systems).
Non-Requirements
No further constraints on CPE WFN parts are suggested in this proposal. Handling the entire grammar, including escape sequences, makes even counting the number of fields by colon-delimiting likely too cumbersome for a single regular expression to be beneficial.
Risk / Benefit analysis
Benefits
Keeping recorded CPEs consistent between CPE's class hierarchy and UCO's offers improved interoperability potential, e.g., between multiple inventorying systems that have mixes of CPEs and UCO annotations.
Constraining the Part attribute will prevent confusion from errant assignments, e.g. designating a tablet device as having an oobservable:cpeid value because of conflation from its operating system.
Requiring WFNs would prevent errant assignment of URI forms of CPEs (NISTIR 7695 Section 6.1.1).
Risks
This proposal requires completion of #624.
This proposal requires, in spirit, either #596 or a reduced proposal of 596 that includes the move of OperatingSystem under Software. However, the implementation does not necessarily need to wait for either of these conditions to be met.
Because cpeid does not appear in OperatingSystemFacet, and Issue 596 will make OperatingSystems a subclass of Software, the SHACL spelling for operating system CPEs will necessarily be a bit different from the typical UCO spelling for other property constraints, and this difference will be visible to end users. The accompanying Pull Request targeting 1.4.0 shows the validation results of what seems like the most practical shape.
Competencies demonstrated
Competency 1
Error detection: A tablet device is given an operating system CPE.
The WFN having an o value implies the associated item (the observable:Tablet) should be an operating system. But, it is a device (i.e., an instance of an observable:Device subclass).
If that WFN is desired to appear in the graph, the operating system of the device should be modeled as a separate object and tied to the device with an observable:ObservableRelationship.
Solution suggestion
(I am fine with my examples being transcribed and credited.)
For DeviceFacet in UCO 1.4.0: Add a dedicated shape, severity sh:Warning, to require a pattern regular expression:
observable:DeviceFacet
sh:property [
sh:message "In UCO 2.0.0, cpeid in DeviceFacet will be constrained to be a CPE version 2.3 hardware name."@en ;
sh:path observable:cpeid ;
sh:pattern "^cpe:2.3:h:.+" ;
sh:severity sh:Warning ;
] ;
.
For DeviceFacet in UCO 2.0.0, cut that property shape, moving the sh:pattern statement into the property shape for observable:cpeid.
Do likewise for SoftwareFacet, only its pattern would be ^cpe:2.3:[a,o]:.+.
Disallow cpeid from OperatingSystemFacet, guiding users to use SoftwareFacet instead, and change severity from warning to violation for UCO 2.0.0:
observable:OperatingSystemFacet
sh:property [
sh:maxCount "0"^^xsd:integer ;
sh:message "observable:cpeid should appear on a SoftwareFacet instead of an OperatingSystemFacet."@en ;
sh:path observable:cpeid ;
sh:severity sh:Warning ;
] ;
.
For OperatingSystem, constrain CPEs to only use the o Part value. This property shape may sufficiently satisfy this implementation, by using a path through two predicates; however, it avoids qualifying which Facet this applies to.
# NOTE: The PropertyShape is not on a Facet subclass.
observable:OperatingSystem
sh:property [
sh:message "In UCO 2.0.0, cpeid in any Facet attached to an OperatingSystem will be constrained to be a CPE version 2.3 operating system name."@en ;
sh:path (
core:hasFacet
observable:cpeid
) ;
sh:pattern "^cpe:2.3:o:.+" ;
sh:severity sh:Warning ;
] ;
.
Aside on unpursued option
A "more correct" constraining would instead apply the o pattern only on a SoftwareFacet, which can be done in a few ways. Unfortunately, each is complex to implement without adding additional single-purpose OWL Classes never really meant for a user to explicitly instantiate, or complex spellings of "if P then Q" using sh:or. Any of these solutions is likely to be unnecessarily challenging to parse to any end user who ultimately put an a where an o should have gone.
For example (and it's hopefully clear why this is not in the pull request): In SHACL, spelling "If P, then Q" when custom classes are not an option needs to be done with the Implication-as-Or's spelling, "p → q ≡ ¬p ∨ q". Hence, the option for representing "IF this SoftwareFacet is a facet of an OperatingSystem object, THEN apply the 'o' CPE pattern constraint" is as follows:
observable:SoftwareFacet
sh:property [
sh:message "In UCO 2.0.0, cpeid in a SoftwareFacet attached to an OperatingSystem will be constrained to be a CPE version 2.3 operating system name."@en ;
sh:or (
[
sh:not [
sh:property [
sh:class observable:OperatingSystem ;
sh:path (
sh:inversePath [
observable:cpeid ;
]
sh:inversePath [
core:hasFacet
]
) ;
# The path starts at the string-literal of the CPE,
# then goes back to the SoftwareFacet,
# then goes back to the ObservableObject.
] ;
] ;
]
[
sh:pattern "^cpe:2.3:o:.+" ;
]
) ;
sh:path observable:cpeid ;
sh:severity sh:Warning ;
] ;
.
A blanket review of cpeid from observable:OperatingSystem seems more palatable.
Background
observable:cpeidis currently (as of UCO 1.3.0) an unconstrained string.The CPE 2.3 naming specification, NISTIR 7695 provides syntactic constraints for a "Well-Formed Name" (WFN). Some seem appropriate to include in UCO:
Prior versions of the CPE specification(s) are currently available here, but they are not referenced further in this proposal.
Requirements
Requirement 1
UCO must constrain CPEs in
cpeidto be specified as Well-Formed-Names of the current version, 2.3.(Aside: This intentionally excludes URI forms from being used in
cpeid.)Requirement 2
UCO must constrain CPEs for
Devices to use anhPart (for hardware devices).Requirement 3
UCO must constrain CPEs for
Softwareto use anaPart (for applications).Requirement 4
UCO must constrain CPEs for
OperatingSystemto use anoPart (for operating systems).Non-Requirements
No further constraints on CPE WFN parts are suggested in this proposal. Handling the entire grammar, including escape sequences, makes even counting the number of fields by colon-delimiting likely too cumbersome for a single regular expression to be beneficial.
Risk / Benefit analysis
Benefits
oobservable:cpeidvalue because of conflation from its operating system.Risks
OperatingSystemunderSoftware. However, the implementation does not necessarily need to wait for either of these conditions to be met.cpeiddoes not appear inOperatingSystemFacet, and Issue 596 will makeOperatingSystems a subclass ofSoftware, the SHACL spelling for operating system CPEs will necessarily be a bit different from the typical UCO spelling for other property constraints, and this difference will be visible to end users. The accompanying Pull Request targeting 1.4.0 shows the validation results of what seems like the most practical shape.Competencies demonstrated
Competency 1
Error detection: A tablet device is given an operating system CPE.
Competency Question 1.1
Is this a valid usage of that CPE WFN?
Result 1.1
No.
The WFN having an
ovalue implies the associated item (theobservable:Tablet) should be an operating system. But, it is a device (i.e., an instance of anobservable:Devicesubclass).If that WFN is desired to appear in the graph, the operating system of the device should be modeled as a separate object and tied to the device with an
observable:ObservableRelationship.Solution suggestion
(I am fine with my examples being transcribed and credited.)
DeviceFacetin UCO 1.4.0: Add a dedicated shape, severitysh:Warning, to require a pattern regular expression:For
DeviceFacetin UCO 2.0.0, cut that property shape, moving thesh:patternstatement into the property shape forobservable:cpeid.Do likewise for
SoftwareFacet, only its pattern would be^cpe:2.3:[a,o]:.+.Disallow
cpeidfromOperatingSystemFacet, guiding users to useSoftwareFacetinstead, and change severity from warning to violation for UCO 2.0.0:OperatingSystem, constrain CPEs to only use theoPart value. This property shape may sufficiently satisfy this implementation, by using a path through two predicates; however, it avoids qualifying whichFacetthis applies to.Aside on unpursued option
A "more correct" constraining would instead apply the
opattern only on aSoftwareFacet, which can be done in a few ways. Unfortunately, each is complex to implement without adding additional single-purpose OWL Classes never really meant for a user to explicitly instantiate, or complex spellings of "if P then Q" usingsh:or. Any of these solutions is likely to be unnecessarily challenging to parse to any end user who ultimately put anawhere anoshould have gone.For example (and it's hopefully clear why this is not in the pull request): In SHACL, spelling "If P, then Q" when custom classes are not an option needs to be done with the Implication-as-Or's spelling, "p → q ≡ ¬p ∨ q". Hence, the option for representing "IF this SoftwareFacet is a facet of an OperatingSystem object, THEN apply the 'o' CPE pattern constraint" is as follows:
A blanket review of
cpeidfromobservable:OperatingSystemseems more palatable.Coordination