Comments (13)
@aj-stein-nist I don't think they need to be worked together for a successful outcome. I do think based on conversation today, maybe it all ends up in one change request for OSCAL rather than multiple. Just keeps it simpler for us once we go to development.
from oscal-define.
Would you like me to pick this up? When and how?
Let's talk Monday. I want to make a pass through the facilitator guide and update first.
from oscal-define.
@Compton-NIST do you need someone to work on this spiral? Does this spiral need to be done directly with or alongside #27? I am ready to volunteer.
from oscal-define.
Would you like me to pick this up? When and how?
from oscal-define.
from oscal-define.
from oscal-define.
Very, very rough draft. What is needed at the moment is input on allowed values and terms used. Also input on cardinality.
from oscal-define.
Next week I will work on some examples using this assembly.
from oscal-define.
https://github.com/usnistgov/OSCAL/tree/compton-working-provenance
from oscal-define.
IMPORTANT: We cannot use matching
in this context since it conflicts with the Profile > import> include-controls > matching
The NISTIR 8278 r1 calls relationship rationale
rationale = a set of reasons or a logical basis for a course of action or a particular belief.
We labeled the information type matching
alluding to the matching type or approach (logical, lexical, semantical, etc).
If source-control < equivalent-to > target-control
using a functional
matching approach vs a semantic
matching approach, are we correct considering functional
or semantic
approach the rational
for the equivalent-to
relationship? If the answer is "yes", then maybe we should align this work with NIST's previous work and call the property rationale
. If the answer is "no" we could call it approach
or matching-type
.
Should we enforce, through the matching-type
property at the document/metadata level, for all relations within one document to be of the same type, or do we allow for the property to be overwritten at the relationship level?
from oscal-define.
Current set theory relationships defined in the experimental model are not suitable for all matching approaches listed: lexical, logical, semantical, syntactical, functional.
The NISTIR 8278 r1 supports set theory based relationships only for syntactic, semantic, and functional approaches.
The documents reads:
The basic reason why a Reference Document Element and a Focal Document Element are related is attributed to one of three rationales
:
Syntactic* – Compares the linguistic meaning of the two elements. For example, the following statements have the same syntax:
printf (“bar”); [... C programming language]
printf (“bar”); [... C programming language]
Semantic – Compares the contextual meaning of the two elements. For example, the following statements convey the same semantic meaning:
“The organization employs a firewall at the network perimeter.”
“The enterprise uses a device that has a network protection application installed to safeguard the network from intentional or unintentional intrusion.”
**Functional ** – Compares the functions of the two elements. For example, the following statements have the same functional result:
printf (“foo\n”); [... C programming language]
print “foo” [... BASIC programming language]
Lexical analysis is the process of breaking down a large text into smaller parts, such as words, phrases or symbols, while syntax analysis is the process of understanding how these parts fit together to form meaningful sentences. Lexical decomposition into fine-grain parts of the mapped controls and analysis of the correlation of the source control parts to the target control parts appears to be the most suitable for automation. Set theory can be applied to those fine-grain parts of the source control and the target control in determining the relationship.
Lexical analysis is used in natural language processing (NLP) to break down natural language text into individual words and phrases that can be more easily processed by NLP algorithms.
Syntax analysis is used in natural language processing to analyze and understand the structure of sentences in a language. It helps identify the parts of speech (noun, verb, pronoun, etc.), determines the relationships between the words, and constructs a parse tree that represents the hierarchical structure of the sentence.
Lexical analysis is the first step in natural language processing. It is the process of breaking down a large text into smaller parts, such as words, phrases, or symbols, and assigning them meaning. Next step is syntax analysis which is the process of understanding how words fit together to form meaningful sentences. This is done by using grammar rules, which define the structure of a sentence. For example, in English, grammar rules would determine whether a sentence should have a subject, verb, and object, or if it should be in the active or passive voice. Nice summary is available here
A more comprehensive logic analysis material is here. The lecture presents Logic Theory (Aristotelian, Hegel's dialectic, mathematical , logical connectives ) demonstrates that in NLP, logical analysis is essentially a semantic analysis, and syntactical analysis is necessary for semantic analysis.
Logical relationships in a language are briefly described here.
To sum:
- lexical analysis breaks down a large text into smaller parts, such as words, phrases or symbols,
- syntax analysis is the process of understanding the grammar (what are the words: nouns, verbs, etc., the voice used: passive, active, imperative, etc.), and supports the semantic analysis
- semantic analysis helps to determine the meaning of a sentence or phrase.
- functional analysis identifies the outcome, the result of the statement
- logical analysis is used as a tool for reasoning, combining ideas, deducing new rules
So, in the NISTIR 8278 r1 , the functional example also shows 2 statements that have the same syntax, such as: function(argument)
.
printf (“foo\n”)
print “foo”
Functionally they produce the same outcome: foo
gets printed.
TO CONCLUDE THE RESEARCH:
- f we keep only the set theory based relationships currently defined in the draft OSCAL Mapping model, then the
logical
andsyntactical
matching approaches should be eliminated from the list. We can allow them to be defined outside core OSCAL in association with proper relationships. - If we keep the
logical
andsyntactical
matching approaches, we need to define proper logical and syntactical relationships and provide clear examples highlighting the differences between them. I personally do not see any strong reason for supporting logical and syntactical (grammar analysis) matching approaches.
from oscal-define.
@iMichaela I placed this feedback into a spiral document.
Feel free to adjust directly in this branch if you want to add or change anything.
from oscal-define.
@Compton-NIST - I wanted us to discuss it first and see if it makes sense to you too. I used those comments to document my thoughts in one place to seed the discussion and share the references.
Here is a document for Logical relations amongst sentences. Will use the spiral document and include the latest link there too.
from oscal-define.
Related Issues (18)
- SAMPLE ONLY: Model needed for communicating shared responsibilities without exposing SSP in OSCAL. HOT 2
- Spiral 3: Create export examples for responsibility model HOT 4
- Spiral 4: Create draft of responsibility model. HOT 10
- Research Effort: Determine changes and revisions required in the development mapping model. HOT 5
- SAMPLE ONLY: Spiral 1: Use Case and Sample Data Creation HOT 2
- Spiral 1: Consolidate all issues and research into single spiral. HOT 2
- Spiral: Change Request creation for a qualifier assembly/tag in mapping. HOT 7
- Spiral: Determine approach for unmapped items in a mapping. HOT 2
- SAMPLE ONLY: Spiral 2: Map use case information to existing OSCAL model(s) and identify gaps.
- Spiral: Determine approach to mapping with context of evidence HOT 2
- Update process and documentation HOT 3
- Spiral: Determine approach to documenting in the SSP and Component Definition a mapped control or statement. HOT 1
- SSP system characteristics needs to be expanded to support multiple frameworks
- [Spiral]: This is a test spiral
- [Research Effort]: Lack of Cyber Resilience OSCAL control profile to assess and protect High Value Targets HOT 1
- Research Effort: A model is needed for customer responsibilities that does not expose the SSP. HOT 1
- Feedback and notes on research process as applied to the current effort/spirals. HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from oscal-define.