Issue 583: Overhaul Software, Configuration, and Tool #589

ajnelson-nist · 2024-02-05T22:31:42Z

This Pull Request might or might not address Issue #583 . It is posted for ongoing review of implementation progress.

AJN: This is a transcription of Sean's suggested specific changes to UCO, and will serve as a starting point for discussion markup. I've denoted Sean the patch-author because these changes were his suggestion initially. I enacted a few revisions in this patch that are either deviations are additions to Sean's notes, and seemed necessary for the first patch: * Concepts marked for removal, migration, and/or deletion are instead marked deprecated. A follow-on patch will implement shapes for deprecation. * I guessed on where the property `hasCharacterization` should be defined. * Another revision is I guessed on how some of the new namespaces' direct-imports directions would have to be. * The tool namesapce needed to pick up a stub reference to `ObservableObject`. A follow-on patch will regenerate Make-managed files. References: * #583 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

No effects were observed on Make-managed files. References: * #583 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

ajnelson-nist · 2024-02-05T22:34:42Z

ontology/uco/tool/tool.ttl

-		]
-		;
+	rdfs:seeAlso observable:CompilerFacet ;
+	sh:message "uco-tool:CompilerType is deprecated.  Please migrate usage of this class to uco-observable:CompilerFacet."@en ;


CompilerFacet was not described directly in the proposal, but was referenced in some of the migration notes.

@sbarnum - Do you have an rdfs:comment for this class?

AJN: This was one of Sean's noted changes. I set it aside on not finding a `hasConfiguration` property, but assume it was meant to be `configure:usesConfiguration`. No effects were observed on Make-managed files. Co-authored-by: Sean Barnum <sbarnum@mitre.org> Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

ajnelson-nist · 2024-02-05T22:45:19Z

ontology/uco/tool/tool.ttl

+		;
+	sh:property [
+		sh:maxCount "0"^^xsd:integer ;
+		sh:message "uco-tool:cpeid is deprecated.  Please instead use the path uco-core:hasFacet (linking a uco-observable:DeviceFacet or uco-observable:SoftwareFacet) / uco-observable:cpeid."@en ;


I realized :cpeid is not associated with observable:DeviceFacet. That should come in a separate proposal.

ajnelson-nist · 2024-02-05T22:45:42Z

ontology/uco/tool/tool.ttl

+		;
+	sh:property [
+		sh:maxCount "0"^^xsd:integer ;
+		sh:message "uco-tool:swid is deprecated.  Please instead use the path uco-core:hasFacet (linking a uco-observable:DeviceFacet or uco-observable:SoftwareFacet) / uco-observable:swid."@en ;


I have to check on the DeviceFacet note here.

ajnelson-nist · 2024-02-05T22:47:08Z

ontology/uco/tool/tool.ttl

-			sh:path tool:swid ;
-		]
-		;
+	rdfs:seeAlso observable:BuildUtilityFacet ;


BuildUtilityFacet was not described directly in the proposal, but was referenced in some of the migration notes.

@sbarnum - Do you have an rdfs:comment for this class?

ajnelson-nist · 2024-02-05T22:48:57Z

ontology/uco/observable/observable.ttl

+	rdfs:subClassOf observable:Software ;
+	.
+
+observable:SetConfigurationEntry


@sbarnum - Could you please confirm the subclass hierarchy under SetConfigurationEntry is as you intended?

ajnelson-nist · 2024-02-05T22:49:59Z

ontology/uco/observable/observable.ttl

+		] ,
+		[
+			sh:datatype xsd:string ;
+			sh:maxCount "1"^^xsd:integer ;


@sbarnum - Is observable:version intended to be (0..1) on DeviceFacet?

ajnelson-nist · 2024-02-05T22:50:40Z

ontology/uco/observable/observable.ttl

+			sh:path observable:package ;
+		] ,
+		[
+			sh:class observable:Script ;


Should this be sh:class observable:BuildScript?

ajnelson-nist · 2024-02-05T22:55:18Z

ontology/uco/observable/observable.ttl

+		] ,
+		[
+			sh:class observable:Script ;
+			sh:maxCount "1"^^xsd:integer ;


Why is this maximum-count 1? Some software follows a multi-step build process. For instance, Autotools-style projects can still ostensibly build with ./bootstrap.sh && ./configure && make && make install, which could challenge this max-1 constraint. For another example, some IDEs provide a push-button build, not necessarily a script; would that build style induce observable:buildScript to be omitted?

ajnelson-nist · 2024-02-05T22:56:49Z

ontology/uco/core/core.ttl

@@ -598,6 +598,13 @@ core:externalReference
 	rdfs:range core:ExternalReference ;
 	.

+core:hasCharacterization


This property had no accompanying namespace suggestion. Should this go into core:? I'm guessing so for now, because of the appearances in the Environment and Tool namespaces.

What is its domain?

What is its range - anything aside from UcoObject, at the most-general property level? Why did the definition string you provided say "references the Software or Device that make up the actual tool," when the suggested constraints in property shapes were much more general?

ajnelson-nist · 2024-02-05T22:58:50Z

ontology/uco/deployment/deployment.ttl

+	a owl:Ontology ;
+	rdfs:label "uco-deployment"@en ;
+	rdfs:comment "TODO"@en ;
+	owl:imports observable:1.3.0 ;


I set the Deployment ontology to import the Observable ontology because of the dependence in deploymentAction.

Why is deployment getting an entire namespace, instead of being in the Observable namespace? Why is Deployment not an ObservableObject subclass?

ajnelson-nist · 2024-02-05T23:00:37Z

ontology/uco/deployment/deployment.ttl

+		sh:NodeShape
+		;
+	rdfs:subClassOf core:UcoObject ;
+	sh:property


Note: I set the three properties deploymentAction, deploymentObject, and deploymentContext to be in the deployment: namespace. The properties were not given definition strings or implementation specifics beyond what was suggested in the initial proposal.

ontology/uco/deployment/deployment.ttl

ajnelson-nist · 2024-02-05T23:04:53Z

ontology/uco/observable/observable.ttl

+		] ,
+		[
+			sh:datatype xsd:string ;
+			sh:maxCount "1"^^xsd:integer ;


The migration note on tool:buildOutputLog suggests moving that property to observable:SoftwareBuildFacet with cardinality 0..*. But, the observable: notes had 0..1. Which should this be?

ajnelson-nist · 2024-02-05T23:05:57Z

ontology/uco/tool/tool.ttl

+		sh:message "uco-tool:buildOutputLog is deprecated.  Please instead use the path uco-core:hasFacet (linking a uco-observable:SoftwareBuildFacet ) / uco-observable:buildOutputLog."@en ;
+		sh:path tool:buildOutputLog ;
+	] ;
+	sh:targetSubjectsOf tool:buildOutputLog ;
 	.

 tool:buildProject


@sbarnum - These properties no longer have any references in the tool: namespace. Did you intend for them all to migrate to the observable: namespace, and change their types (e.g. some were datatype properties and are now object properties)?

tool:buildProject

tool:buildScript

tool:buildUtility

tool:compilationDate

tool:compilers

ajnelson-nist · 2024-02-05T23:15:11Z

ontology/uco/tool/tool.ttl

@@ -54,139 +60,54 @@ tool:BuildFacet
 tool:BuildInformationType
 	a
 		owl:Class ,
+		owl:DeprecatedClass ,


@sbarnum : With this deprecation, tool:buildInformation is constrained to use a deprecated class in tool:buildFacet. Should tool:BuildFacet also be deprecated and/or migrated to observable:?

A potential conflict - the class observable:Build added in this proposal is a subclass of ObservableAction.

A follow-on patch will regenerate Make-managed files. References: * ucoProject/UCO#573 * ucoProject/UCO#584 * ucoProject/UCO#589 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

References: * ucoProject/UCO#573 * ucoProject/UCO#584 * ucoProject/UCO#589 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

Sean Barnum and others added 3 commits February 5, 2024 16:59

Regenerate Make-managed files

5cf28be

Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

Add deprecation shapes

623c5f4

No effects were observed on Make-managed files. References: * #583 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

ajnelson-nist added the Change Proposal label Feb 5, 2024

ajnelson-nist added this to the UCO 2.0.0 milestone Feb 5, 2024

ajnelson-nist linked an issue Feb 5, 2024 that may be closed by this pull request

Need improved and extended abilities to express contextual details around software such as its build, configuration, and deployment #583

Open

ajnelson-nist commented Feb 5, 2024

View reviewed changes

ontology/uco/deployment/deployment.ttl Show resolved Hide resolved

ajnelson-nist commented Feb 5, 2024

View reviewed changes

ajnelson-nist mentioned this pull request Feb 5, 2024

Need improved and extended abilities to express contextual details around software such as its build, configuration, and deployment #583

Open

ajnelson-nist commented Feb 5, 2024

View reviewed changes

ajnelson-nist added a commit to casework/casework.github.io that referenced this pull request May 3, 2024

Regenerate Make-managed files

1db05c9

References: * ucoProject/UCO#573 * ucoProject/UCO#584 * ucoProject/UCO#589 Signed-off-by: Alex Nelson <alexander.nelson@nist.gov>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Issue 583: Overhaul Software, Configuration, and Tool #589

Issue 583: Overhaul Software, Configuration, and Tool #589

ajnelson-nist commented Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

ajnelson-nist Feb 5, 2024

Issue 583: Overhaul Software, Configuration, and Tool #589

Are you sure you want to change the base?

Issue 583: Overhaul Software, Configuration, and Tool #589

Conversation

ajnelson-nist commented Feb 5, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment