Merge branch 'develop' into unstable

.github/ISSUE_TEMPLATE/bug_report.md

@@ -0,0 +1,30 @@
+---
+name: Bug report
+about: Create a report to help us improve.
+title: ''
+labels: 'bug'
+assignees: ''
+
+---
+
+<!--
+Note that text between the HTML comments will be recorded in this issue's source for future editing, but will not render on Github.  So, please feel free to delete whatever portion of these comments, or this template, that you do not use.
+-->
+
+
+# Bug description
+
+<!--
+A clear and concise description of what the bug is.
+
+If you are seeing an errant behavior or implementation related to a property, it helps with diagnosing the issue if you can identify the property, for instance by a line within the corresponding ontology Turtle file, the property short name, or some other means.
+-->
+
+
+## Steps to reproduce
+
+<!--
+Steps to reproduce the behavior.
+
+If you came across this error by seeing a SHACL validation result, please provide a Turtle or JSON-LD snippet that recreates the error.  Also, please note if you were testing against the current release (master branch) or a development pre-release (e.g. via downloading `CASE-develop.ttl`).  If you don't know, it's likely you encountered this via the current release.
+-->

.github/ISSUE_TEMPLATE/change-request.md

@@ -0,0 +1,99 @@
+---
+name: Change Request
+about: Propose a Change Request.
+title: ''
+labels: change request
+assignees: ''
+---
+
+<!--
+Note that text between the HTML comments will be recorded in this issue's source for future editing, but will not render on Github.  So, please delete whatever portion of these comments you do not use.
+
+Also, the Description box of the Issue you file will be edited at one or more points.  At least one edit will be done by a member of the Ontology Committee leadership to add a coordination-steps checklist.  Comment edit history is viewable:
+https://docs.github.com/en/communities/moderating-comments-and-conversations/tracking-changes-in-a-comment
+-->
+
+# Background
+
+<!--
+Give any background you find helpful, if you feel jumping straight to listing requirements might not flow well to a reader.  For instance, if revising a current implementation, explain what that implementation does and why it seems worth changing to you.
+
+It is helpful to at least provide a one-sentence comprehensive answer to the question "What do we achieve for whom and why does that matter?"
+-->
+
+
+# Requirements
+
+<!--Please provide one requirement per subsection.  (The use of sections is for linking to headers on Github.)-->
+
+
+## Requirement 1
+
+
+## Requirement 2
+
+
+# Risk / Benefit analysis
+
+
+## Benefits
+
+
+## Risks
+
+<!--
+If no risks are known, "The submitter is unaware of risks associated with this change" might suffice.
+
+Risks should include consequences for CDO resources (ontologies, documentation, and/or tooling) resulting from this Change Request.  Consequences can relate to impediments or degradations to functionality, interoperability, reliability, usability, efficiency, maintainability or portability.
+
+As risks are identified (e.g. as implementation-testing might reveal), they will be added to this section.
+-->
+
+
+# Competencies demonstrated
+
+<!--
+Please describe at least one enabled or upgraded competency, e.g. a competency question (CQ) you can answer with this proposal that you couldn't answer before. Probably, in order to show how the resulting answer emerges, some narrative or scenario is required to be described. As a minimum, describe the questions and resulting answers in English; optionally, include a SPARQL query or a link to a functioning draft implementation of this proposal that includes a SPARQL query.
+
+Please do consider a scenario that can have ground truth positive and ground truth negative encoded for implementation testing.  For instance, a scenario for CASE that exercises the uco-action:instrument property could be "Three picture files were produced on an analyst's workstation over the course of an investigation."  A competency question for this scenario could be "Which picture files were taken from the evidence, vs. taken of the evidence?"  The results would be "From reviewing the investigative actions in the chain of custody, picture files generated when the instrument was the analyst's camera would be 'taken of', while picture files generated when the instrument was a data extraction kiosk would be 'taken from.'"
+-->
+
+
+## Competency 1
+
+<!--
+Include competency narrative or scenario text here, as the preamble to the questions.
+-->
+
+
+### Competency Question 1.1
+
+
+#### Result 1.1
+
+
+### Competency Question 1.2
+
+<!--
+One scenario setup can fuel multiple questions.  To help with linking on Github, please use section numbering.
+-->
+
+
+#### Result 1.2
+
+
+# Solution suggestion
+
+<!--
+If possible, please summarize the concrete steps to take to satisfy the requirements, e.g.:
+* Define new property
+* Add unit test showing potential errors in property usage and how to avoid them
+
+To assist with voting, the Ontology Committee should see a summary of intended changes as early as possible.  Please do summarize steps and effects, even if a Pull Request accompanies the Issue.  Discovery of effects from implementation review can lead to disruption in the committee review flow.
+
+Some requirements are narrow enough they could be considered "Self-documenting."  One way to estimate if this is true is if a lone Git commit could have the requirement as a title, have no further message text, and be comprehensible.  In such cases, the following text could be used (though please cut the leading "> " if this line is used):
+
+> Requirement 1 also fully describes the solution, implemented in [PR X](https://github.com/ucoProject/UCO/pull/X).
+
+If there is an accompanying pull request, please do link it under the "Development" box on the right of the Issues page.
+-->

.github/ISSUE_TEMPLATE/config.yml

@@ -0,0 +1,17 @@
+blank_issues_enabled: false
+contact_links:
+  - name: CASE Website
+    url: https://caseontology.org/
+    about: See usage examples and other documentation here.
+  - name: UCO Website
+    url: https://unifiedcyberontology.org/
+    about: See UCO design documentation here.
+  - name: CASE Examples
+    url: https://github.com/casework/CASE-Examples/
+    about: Please request examples for concept usage here.
+  - name: CASE Website (source)
+    url: https://github.com/casework/casework.github.io/
+    about: Please request documentation updates pertaining to CASE and/or UCO here.
+  - name: UCO Website (source)
+    url: https://github.com/ucoProject/ucoproject.github.io/
+    about: Please request documentation updates pertaining to UCO here.

.github/ISSUE_TEMPLATE/question.md

@@ -0,0 +1,7 @@
+---
+name: Question
+about: Ask a general question, such as on how to represent or use a property.
+title: ''
+labels: question
+assignees: ''
+---

.github/pull_request_template.md

@@ -0,0 +1,21 @@
+<!--
+# Pull request instructions
+(Note that text between the HTML comments will be recorded in this pull request's source for future editing, but will not render on Github.  So, please delete whatever portion of this comment you do not use.  Text portions suggested to extract are at the bottom of this snippet.)
+
+CDO Pull Requests for ontology repositories generally follow one of two forms: "Bug-fix" pull requests, and all others.
+
+A "Bug-fix" pull request will typically be of low-to-zero risk to the ontology and its downstream resources.  This is different from a bug-reporting Issue.  Bugs described in an Issue can be significantly complex and require committee consensus to resolve.  A "Bug-fix" pull request will generally be close to a self-explaining correction.
+
+The risk assessment of a "Bug-fix" proposal is confirmed by two members of the Ontology Committee leadership agreeing that no committee review is required.
+
+It is difficult to describe what "Low risk" would be in general.  Typo corrections in documentation comments would be likely to qualify.  Correction (not addition) of type constraints are less likely, but still probable.  Cardinality corrections are improbable, as programming assumptions may have been made based on those specifications.  In summary, please be aware that what is submitted as a "Bug-fix" proposal may be treated as requiring committee review, and possibly further use case description.
+
+
+## Template text
+
+If you are writing a "Bug-fix" pull request, please use the following description (cutting the leading "> "):
+> This Pull Request is a bug-fix change proposal, believed to be of low risk to the ontology and its downstream resources.
+
+For a pull request of any other nature, please reference a Github Issue number that the Pull Request would resolve.  (Please remove the leading "> ".)
+> This Pull Request resolves all requirements of Issue # .
+-->

CONTRIBUTE.md

@@ -0,0 +1,6 @@
+# Contributing to the CASE ontology
+
+
+## Testing prerelease states
+
+Practices for users interested in testing prerelease states are documented on the [Cyber Domain Ontology website](https://cyberdomainontology.org/ontology/development/#testing-prereleases).