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:cpeid
is 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
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
Device
s to use anh
Part (for hardware devices).Requirement 3
UCO must constrain CPEs for
Software
to use ana
Part (for applications).Requirement 4
UCO must constrain CPEs for
OperatingSystem
to use ano
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
o
observable:cpeid
value because of conflation from its operating system.Risks
OperatingSystem
underSoftware
. However, the implementation does not necessarily need to wait for either of these conditions to be met.cpeid
does not appear inOperatingSystemFacet
, and Issue 596 will makeOperatingSystem
s 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
o
value implies the associated item (theobservable:Tablet
) should be an operating system. But, it is a device (i.e., an instance of anobservable: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.)
DeviceFacet
in UCO 1.4.0: Add a dedicated shape, severitysh:Warning
, to require a pattern regular expression:For
DeviceFacet
in UCO 2.0.0, cut that property shape, moving thesh:pattern
statement into the property shape forobservable:cpeid
.Do likewise for
SoftwareFacet
, only its pattern would be^cpe:2.3:[a,o]:.+
.Disallow
cpeid
fromOperatingSystemFacet
, guiding users to useSoftwareFacet
instead, and change severity from warning to violation for UCO 2.0.0:OperatingSystem
, constrain CPEs to only use theo
Part value. This property shape may sufficiently satisfy this implementation, by using a path through two predicates; however, it avoids qualifying whichFacet
this applies to.Aside on unpursued option
A "more correct" constraining would instead apply the
o
pattern 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 ana
where ano
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:
A blanket review of
cpeid
fromobservable:OperatingSystem
seems more palatable.Coordination