Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Draft
wants to merge 4 commits into
base: develop-2.0.0
Choose a base branch
from

Conversation

ajnelson-nist
Copy link
Contributor

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

Sean Barnum and others added 3 commits February 5, 2024 16:59
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 <[email protected]>
No effects were observed on Make-managed files.

References:
* #583

Signed-off-by: Alex Nelson <[email protected]>
]
;
rdfs:seeAlso observable:CompilerFacet ;
sh:message "uco-tool:CompilerType is deprecated. Please migrate usage of this class to uco-observable:CompilerFacet."@en ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 <[email protected]>
Signed-off-by: Alex Nelson <[email protected]>
;
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 ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

;
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 ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have to check on the DeviceFacet note here.

sh:path tool:swid ;
]
;
rdfs:seeAlso observable:BuildUtilityFacet ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

rdfs:subClassOf observable:Software ;
.

observable:SetConfigurationEntry
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

] ,
[
sh:datatype xsd:string ;
sh:maxCount "1"^^xsd:integer ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

sh:path observable:package ;
] ,
[
sh:class observable:Script ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be sh:class observable:BuildScript?

] ,
[
sh:class observable:Script ;
sh:maxCount "1"^^xsd:integer ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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

core:hasCharacterization
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

a owl:Ontology ;
rdfs:label "uco-deployment"@en ;
rdfs:comment "TODO"@en ;
owl:imports observable:1.3.0 ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

sh:NodeShape
;
rdfs:subClassOf core:UcoObject ;
sh:property
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

] ,
[
sh:datatype xsd:string ;
sh:maxCount "1"^^xsd:integer ;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

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
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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

@@ -54,139 +60,54 @@ tool:BuildFacet
tool:BuildInformationType
a
owl:Class ,
owl:DeprecatedClass ,
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@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.

ajnelson-nist added a commit to casework/casework.github.io that referenced this pull request May 3, 2024
A follow-on patch will regenerate Make-managed files.

References:
* ucoProject/UCO#573
* ucoProject/UCO#584
* ucoProject/UCO#589

Signed-off-by: Alex Nelson <[email protected]>
ajnelson-nist added a commit to casework/casework.github.io that referenced this pull request May 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
1 participant