Notation in SOLVE-IT for CASE classes that do not yet exist

[chrishargreaves]

I know there is not tight integration between these projects at the moment, but there are increasing numbers of output entities that are identified through populating SOLVE-IT techniques, that are not yet represented in CASE.

Within SOLVE-IT we have a few options so I'm seeking preferred options from the CASE side (there may be no interest or preference, which is also fine!):

For example we have this:

{
    "id": "T1138",
    "name": "Browser cache examination",
    "description": "The examination of the content saved locally by browsers to improve performance",
    "synonyms": ["web cache examination",
                 "internet cache examination"],
    "details": "",
    "subtechniques": [],
    "examples": [],
    "weaknesses": [],
    "CASE_output_classes" : [],
    "references": []
}

Let's assume for this example we can think of output (termed Digital Forensic Technique Results) that is (without the need for exact relationships between these at this time, just a bag of entities if you will):

• browser cache
• browser cache entry
• stored cached object (file or internal database BLOB)
• various timestamps

The options available are:

a) move away from CASE representations for output and use something a bit more freeform.

• not great idea when there is this project working on representing all these concepts. The freeform entries will be a headache at some point too.

b) add another field, something like: generic_output_classes to accommodate anything that isn't modelled. This would then look like:

"CASE_output_classes" : ["observable:File"],
"generic_output_classes": ["Browser cache", "Browser cache entry"].  // we need to make up our own notation for this, which again is not the scope of the project really.

We could come up with some process to migrate these generic terms into CASE over time.

c) adopt a prefix e.g. "__future__" or "__to_be_proposed__" which would flag that it's not in CASE but the intention is to try and get it thought the proposal stages. This would look like:

"CASE_output_classes" : ["__proposed__observable:BrowserCache",
                         "__proposed__observable:BrowserCacheEntry",
                        "observable:File" ],

d) Question - is there any domain specific notation that is somewhat CASE compliant, so it would help on the path to integration with CASE, but not disrupt anything you are doing e.g.

"CASE_output_classes" : ["SOLVE-IT.observable:BrowserCache",
                         "SOLVE-IT.observable:BrowserCacheEntry",
                        "observable:File" ]

Again, if there is a CASE use case, then we could migrate these from SOLVE-IT DFTRs to CASE classes.

---

Any thoughts on this are most welcome.

For the moment I'm just dropping output entities that are highlighted during the technique mapping phase since I'm not sure how to accommodate them, which is rather unsatisfactory and can't continue.

b) is probably the most project independent approach, but something more integrated would be nice if there is a possibility for it, so I thought I'd reach out and see if there were any low resistance, higher benefit options.

[chrishargreaves]

@eoghanscasey, for info.

[vulnmaster]

@chrishargreaves I am willing to support you on this. Highlighting our gaps is very helpful and gives us new areas to focus on. We have near-weekly work sessions at 0830 EST on Wednesdays where we help CASE/UCO adopters if you would like to participate. Historically we use a "drafting" namespace to represent classes that don't have formal coverage yet.

Our ontology committee meets each month as long as there is business before it. The best way to move forward is to submit change proposals via this same forum. @ajnelson-nist has created a really useful template for change proposals. I am happy to help you with developing the change proposals to add new classes or properties as you identify the need for coverage. The change process can move fairly quickly, but it has to move through the established process that we have which allows us to gain a 3/4 consensus on changes across the four classes of participants that we have.

[chrishargreaves]

@vulnmaster, Cory, thanks very much for that! What would the 'drafting namespace' look like, for say: observable:BrowserCacheEntry?
Could I just create an equivalent 'pre-drafting namespace' at the SOLVE-IT level, with a documented progression path of pre-drafting, drafting, done? I don't necessarily want to mandate getting a draft CASE proposal submitted to include a type of result for a technique. I guess I can come up with whatever namespace I want, but if there is a stye/progression workflow that helps you later down on in the process then I may as well do that.

Re adoption, that's great. We have a 'keyword result' proposal that's being worked on but it has ended up being more complex than originally thought so is taking a little while. I may start something much simpler soonish just to get experience of getting through the whole process. I'd be in a better position to document succinctly this as part of the SOLVE-IT 'technique addition' documentation.

[vulnmaster]

@chrishargreaves we have only used this drafting approach sparingly and I don't think we have any live examples of it anymore based on my searching. Since you already have some ideas about where your concepts should go, and I generally agree, it would be easier to just write the change proposal. We should let @ajnelson-nist and @plbt5 chime in on their preference for usage of any interim drafting language that you should use for unrepresented concepts in CASE and UCO since they lead the ontology development efforts. @sbarnum can you review this when you get a chance?

I used AI to help me create this draft change proposal so that we have something to discuss:

Background

In the discussion at CASE Issue #185, @chrishargreaves highlighted the challenge of representing Digital Forensic Technique Results (DFTRs) from SOLVE-IT that correspond to UCO observable classes that do not yet exist in the CASE/UCO ecosystem. Currently, SOLVE-IT techniques like "Browser cache examination" (T1138) identify output entities such as browser cache, browser cache entry, and cached objects that are not yet modeled as UCO observables. This creates a gap between the practical needs of digital forensic techniques and the available ontological representation, limiting interoperability and data exchange capabilities.

The browser cache examination technique produces several types of observable entities:

• Browser cache - the overall cache storage mechanism
• Browser cache entry - individual cached items with metadata
• Cached object - the actual cached content (files or database BLOBs)
• Various timestamps - creation, access, and modification times

These concepts are clearly observable entities that should be represented in the UCO observable namespace, following the established pattern of classes like uco-observable:File, uco-observable:NetworkConnection, etc.

Requirements

Requirement 1

Create new UCO observable classes for browser cache-related entities as direct subclasses of uco-observable:ObservableObject, following the established pattern used by other observable classes in the UCO ontology.

Requirement 2

Define the new observable classes with appropriate rdfs:label and rdfs:comment properties that accurately describe browser cache entities and their relationships to digital forensic investigations.

Requirement 3

Establish proper relationships between the new observable classes using UCO properties, enabling accurate representation of browser cache examination results in digital forensic workflows.

Risk / Benefit analysis

Benefits

• Enhanced forensic coverage – enables accurate representation of browser cache examination results in digital forensic investigations
• Improved SOLVE-IT integration – provides proper ontological representation for SOLVE-IT technique outputs, enabling better interoperability
• Better provenance tracking – allows systems to distinguish between different types of cached content and their forensic significance
• Standardized terminology – aligns with digital forensic practice terminology and facilitates data exchange between forensic tools
• Extensible framework – establishes a pattern for adding other web browser-related observables (cookies, history, etc.)

Risks

The submitter is unaware of risks beyond routine ontology-maintenance overhead (documentation updates, potential SHACL test additions). No existing CASE/UCO instances break, as this is purely additive to the UCO observable namespace.

Competencies demonstrated

Competency 1 – Browser cache forensic analysis workflow

Scenario
A digital forensics investigation involves examining a suspect's web browser cache to identify evidence of malicious activity. The forensic examiner uses browser cache examination techniques to extract cached web pages, images, and other content. The knowledge graph contains provenance triples linking the examination actions to the discovered cache entities and their metadata.

The examination action produces several observable entities:

_:browserCache a uco-observable:BrowserCache ;
    uco-core:name "Chrome Cache Database" ;
    uco-core:description "Browser cache storage for user profile" ;
    uco-core:hasFacet _:browserCacheFacet .

_:browserCacheFacet a uco-observable:BrowserCacheFacet .

_:cacheEntry a uco-observable:BrowserCacheEntry ;
    uco-core:name "Cached webpage entry" ;
    uco-core:hasFacet _:cacheEntryFacet .

_:cacheEntryFacet a uco-observable:BrowserCacheEntryFacet ;
    uco-observable:cacheEntryKey "https://example.com/malicious-page" ;
    uco-observable:sizeInBytes 2048 ;
    uco-observable:accessedTime "2024-01-15T10:30:00Z"^^xsd:dateTime .

_:cachedObject a uco-observable:CachedObject ;
    uco-core:name "Cached HTML content" ;
    uco-core:hasFacet [
        a uco-observable:FileFacet ;
        uco-observable:sizeInBytes 4096 ;
    ] ,
    [
        a uco-observable:CachedObjectFacet ;
        uco-observable:mimeType "text/html" ;
    ] ;
    uco-core:hash [
        a types:Hash ;
        types:hashMethod "SHA256" ;
        types:hashValue "abc123..." ;
    ] .

Competency Question 1.1

What browser cache entries were accessed during the time period of interest?

SELECT ?cacheEntry ?accessTime ?entryKey
WHERE {
  ?cacheEntry a uco-observable:BrowserCacheEntry ;
              uco-core:hasFacet ?facet .
  ?facet a uco-observable:BrowserCacheEntryFacet ;
         uco-observable:accessedTime ?accessTime ;
         uco-observable:cacheEntryKey ?entryKey .
  FILTER(?accessTime >= "2024-01-15T00:00:00Z"^^xsd:dateTime)
  FILTER(?accessTime <= "2024-01-15T23:59:59Z"^^xsd:dateTime)
}

Result 1.1

Returns all browser cache entries accessed during the specified time period, enabling timeline analysis of web browsing activity.

Competency Question 1.2

What cached objects contain specific content types or patterns?

SELECT ?cachedObject ?contentType ?hashValue
WHERE {
  ?cachedObject a uco-observable:CachedObject ;
                uco-core:hasFacet ?facet ;
                uco-core:hash ?hash .
  ?facet a uco-observable:CachedObjectFacet ;
         uco-observable:mimeType ?contentType .
  ?hash types:hashValue ?hashValue .
  FILTER(?contentType IN ("text/html", "application/javascript", "image/png"))
}

Result 1.2

Returns cached objects filtered by content type, enabling forensic analysts to focus on specific types of cached content relevant to their investigation.

Competency 2 – Browser cache examination technique mapping

Scenario
A SOLVE-IT technique "Browser cache examination" (T1138) is mapped to its corresponding UCO observable outputs, enabling automated correlation between forensic techniques and their expected results.

Competency Question 2.1

Which SOLVE-IT techniques produce browser cache observables?

SELECT ?technique ?observableType
WHERE {
  ?technique a solve-it:DigitalForensicTechnique .
  ?technique solve-it:producesObservable ?observableType .
  FILTER(?observableType IN (
    uco-observable:BrowserCache,
    uco-observable:BrowserCacheEntry,
    uco-observable:CachedObject
  ))
}

Result 2.1

Returns the mapping between SOLVE-IT techniques and the browser cache observable types they produce, enabling automated technique-to-observable correlation.

Solution suggestion

1. UCO ontology edits

   • Add the new observable class definitions in the UCO observable ontology module following the established pattern, using facets for properties similar to BrowserCookieFacet (until we migrate away from using facets):

   uco-observable:BrowserCache
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-observable:ObservableObject ;
       rdfs:label "BrowserCache"@en ;
       rdfs:comment "A browser cache is a storage mechanism used by web browsers to store web page resources locally for improved performance and offline access."@en ;
       sh:targetClass uco-observable:BrowserCache ;
       .
   
   uco-observable:BrowserCacheFacet
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-core:Facet ;
       rdfs:label "BrowserCacheFacet"@en ;
       rdfs:comment "Properties describing browser caches."@en ;
       sh:targetClass uco-observable:BrowserCacheFacet ;
       .
   
   uco-observable:BrowserCacheEntry
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-observable:ObservableObject ;
       rdfs:label "BrowserCacheEntry"@en ;
       rdfs:comment "A browser cache entry is a single cached item within a browser cache, containing metadata about the cached resource and its access patterns."@en ;
       sh:targetClass uco-observable:BrowserCacheEntry ;
       .
   
   uco-observable:BrowserCacheEntryFacet
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-core:Facet ;
       rdfs:label "BrowserCacheEntryFacet"@en ;
       rdfs:comment "Properties describing browser cache entries."@en ;
       sh:property [
           sh:datatype xsd:string ;
           sh:maxCount "1"^^xsd:integer ;
           sh:nodeKind sh:Literal ;
           sh:path uco-observable:cacheEntryKey ;
       ] ,
       [
           sh:datatype xsd:integer ;
           sh:maxCount "1"^^xsd:integer ;
           sh:nodeKind sh:Literal ;
           sh:path uco-observable:sizeInBytes ;
       ] ,
       [
           sh:datatype xsd:dateTime ;
           sh:maxCount "1"^^xsd:integer ;
           sh:nodeKind sh:Literal ;
           sh:path uco-observable:accessedTime ;
       ] ;
       sh:targetClass uco-observable:BrowserCacheEntryFacet ;
       .
   
   uco-observable:CachedObject
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-observable:File ;  # Subclassing from File as it's actual content
       rdfs:label "CachedObject"@en ;
       rdfs:comment "A cached object is the actual content stored in a browser cache, such as HTML files, images, scripts, or other web resources."@en ;
       sh:targetClass uco-observable:CachedObject ;
       .
   
   uco-observable:CachedObjectFacet
       a
           owl:Class ,
           sh:NodeShape
           ;
       rdfs:subClassOf uco-core:Facet ;
       rdfs:label "CachedObjectFacet"@en ;
       rdfs:comment "Properties describing cached objects."@en ;
       sh:property [
           sh:datatype xsd:string ;
           sh:maxCount "1"^^xsd:integer ;
           sh:nodeKind sh:Literal ;
           sh:path uco-observable:mimeType ;
       ] ,
       [
           sh:class types:Hash ;
           sh:nodeKind sh:BlankNodeOrIRI ;
           sh:path uco-core:hash ;  # Using standard UCO hash model
       ] ;
       sh:targetClass uco-observable:CachedObjectFacet ;
       .

2. Property definitions and reuse

   • Reuse existing UCO properties where available to avoid conflicts:
     • uco-observable:sizeInBytes (from UCO observable) for entry/object size
     • uco-observable:accessedTime (from UCO observable) for last access timestamp
     • uco-observable:mimeType (from UCO observable) for content type (MIME)
     • uco-core:hash (from UCO core) linking to types:Hash instances for content integrity verification (standard UCO hash structure with types:hashMethod and types:hashValue properties)
   • Define only properties that are not currently covered by UCO:

   uco-observable:cacheEntryKey
       a owl:DatatypeProperty ;
       rdfs:label "cacheEntryKey"@en ;
       rdfs:comment "The unique identifier or URL key for a browser cache entry."@en ;
       rdfs:range xsd:string ;
       .

   • Note: All properties defined on facets should use the facet attachment pattern via uco-core:hasFacet to separate structural properties (on the observable object) from characteristic properties (on the facet), following the established UCO pattern as demonstrated in classes like uco-observable:BrowserCookie with uco-observable:BrowserCookieFacet.

3. SOLVE-IT integration

   • Update SOLVE-IT technique definitions to use the new UCO observable classes. This addresses the concern raised in CASE Issue #185 where @chrishargreaves identified the challenge of representing Digital Forensic Technique Results (DFTRs) that don't yet exist in CASE/UCO.
   • Recommended approach: Use the standard CASE namespace prefixes for the new classes once they are accepted into UCO, avoiding the need for temporary prefixes like __proposed__ or SOLVE-IT.observable: as discussed in the issue. This proposal directly addresses option (a) from Issue Notation in SOLVE-IT for CASE classes that do not yet exist #185 by formally adding these classes to UCO rather than using freeform or generic representations.
   • Example SOLVE-IT technique definition:

   {
       "id": "T1138",
       "name": "Browser cache examination",
       "description": "The examination of the content saved locally by browsers to improve performance",
       "synonyms": ["web cache examination", "internet cache examination"],
       "CASE_output_classes": [
           "uco-observable:BrowserCache",
           "uco-observable:BrowserCacheEntry",
           "uco-observable:CachedObject",
           "uco-observable:File"
       ]
   }

   • For techniques that produce observables not yet in UCO, the SOLVE-IT project should follow the CASE change proposal process (as demonstrated by this proposal) to add missing classes, ensuring proper integration rather than using temporary notations.

4. Documentation

   • Update UCO documentation to include the new browser cache observable classes
   • Add usage examples showing browser cache examination workflows
   • Document the relationship between SOLVE-IT techniques and UCO observables

5. Testing

   • Add validation tests to ensure proper integration with existing observable classes
   • Create example instances demonstrating browser cache examination scenarios
   • Add SHACL shapes for the new properties

This implementation maintains backward compatibility while enhancing the UCO observable namespace to support browser cache forensic analysis, enabling better integration between SOLVE-IT techniques and CASE/UCO representations.

Recommendations for Implementing Browser Cache Examination

Based on analysis of the Unified Cyber Ontology (UCO) and CASE ontologies:

The concept of "browser cache examination" is best implemented as an instance of case-investigation:InvestigativeAction from the CASE Investigation ontology (@https://ontology.caseontology.org/case/investigation/1.4.0). This class is a subclass of uco-action:Action (@https://ontology.unifiedcyberontology.org/uco/action/) and is specifically designed for actions performed within the context of an investigation, such as examining or analyzing evidence.

Why InvestigativeAction?

• Alignment with forensics: It represents actions like evidence examination, which fits browser cache analysis in digital forensic workflows.
• Not UCO Action alone: While uco-action:Action is general, InvestigativeAction adds investigation-specific semantics.
• Not UCO Analysis: uco-analysis:Analysis (@https://ontology.unifiedcyberontology.org/uco/analysis/) is more for analytic results or classifications, not the act of examination itself.
• Integration: You can link the InvestigativeAction to inputs (e.g., browser files) and outputs (e.g., instances of the new BrowserCache classes) using properties like uco-action:instrument, uco-action:object, and uco-action:result.

Example Usage

@prefix case-investigation: <https://ontology.caseontology.org/case/investigation/> .
@prefix uco-action: <https://ontology.unifiedcyberontology.org/uco/action/> .
@prefix uco-core: <https://ontology.unifiedcyberontology.org/uco/core/> .
@prefix uco-observable: <https://ontology.unifiedcyberontology.org/uco/observable/> .
@prefix uco-role: <https://ontology.unifiedcyberontology.org/uco/role/> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .

_:examination a case-investigation:InvestigativeAction ;
    uco-core:name "Browser Cache Examination" ;
    uco-core:description "Examination of browser cache for evidence" ;
    uco-action:instrument _:forensicTool ;
    uco-action:object _:browserCacheFile ;
    uco-action:result _:browserCacheEntry , _:provenanceRecord ;
    uco-action:performer _:examiner .

_:examiner a uco-core:Identity ;
    uco-core:name "Forensic Examiner" ;
    uco-core:role _:examinerRole .

_:examinerRole a case-investigation:Examiner .

_:forensicTool a uco-observable:Software ;
    uco-core:name "CacheAnalyzerPro" ;
    uco-core:hasFacet [
        a uco-observable:SoftwareFacet ;
        uco-observable:version "2.5.1" ;
    ] .

_:browserCacheFile a uco-observable:File ;
    uco-core:name "browser_cache.db" ;
    uco-core:hasFacet [
        a uco-observable:FileFacet ;
        uco-observable:fileName "cache.db" ;
        uco-observable:sizeInBytes 1048576 ;
    ] .

_:browserCacheEntry a uco-observable:BrowserCacheEntry ;
    uco-core:name "Extracted cache entry" ;
    uco-core:hasFacet [
        a uco-observable:BrowserCacheEntryFacet ;
        uco-observable:cacheEntryKey "https://example.com/page" ;
        uco-observable:accessedTime "2024-01-15T10:30:00Z"^^xsd:dateTime ;
    ] .

_:provenanceRecord a case-investigation:ProvenanceRecord ;
    case-investigation:exhibitNumber "EX-001" ;
    uco-core:object _:browserCacheEntry .

This approach ensures interoperability with existing CASE/UCO structures for forensic provenance and workflows. If more specificity is needed, a subclass of InvestigativeAction could be defined for browser-specific examinations.

[chrishargreaves]

Thanks so much for this. Very interesting to see a full worked example here.

The view on how a SOLVE-IT technique is represented as InvestigativeAction is also very interesting.

This looks great from the specific problem of Browser Cache artefacts and if approved at next ontology committee then I can update the SOLVE-IT entities easily.

Regarding the full workflow I'm still unsure about binding the addition of content to SOLVE-IT (specifically types of DFTRs) to the CASE proposal process. I'll give it some thought how we can adopt some sort of general holding pen for concepts within SOLVE-IT that need to be eventually be submitted to CASE officially with the rigour and competencies etc. and other details that you demonstrate above.

If you are able to share (perhaps even in the CASE documentation) the AI prompts that support generation of appropriate change proposals then that would also be helpful for future submissions.

Thanks again.

[vulnmaster]

@chrishargreaves we will need to work with @ajnelson-nist to tee up the change proposal so that it can be presented by us at the next ontology meeting as a requirement to review/approve. The Ontology Committee members will have a comment period prior to the meeting, then we will present the requirements and answer the member's questions online and at the meeting. Once the requirement is approved by the Ontology Committee, we will be invited to submit a PR with the specific ontology changes we want to see. To submit the PR we have to run the ontology validation successfully with our changes included. The PR is then announced by the committee chair, members are given a comment period, then we review/approve the change at the next Ontology Committee meeting. Sometimes the change is approved, and sometimes we have to go back to improve the change in response to member's questions. Once the change is approved, the Chair then decides which release our changes will be merged into (e.g.; UCO 1.5.0).

Here is my general approach to using AI prompts to make ontology change proposals.

1. I primarily use Cursor AI IDE to help me with this. I suppose you can use other AI paired programmer tools as well as they are fairly similar in how they work. Since I pay for tokens used in Cursor, I oftentimes will have a brainstorming session directly via ChatGPT/Grok outside of Cursor, then bring that analysis as a reference to Cursor reference. Honestly, its cheaper to do it this way.

2. Depending on where I want to target the change proposal, I clone the CASE or UCO repo to my personal Github account, then I clone it to a local repository. I open the repository in Cursor.

3. I ensure to highlight the change proposal template to the AI agent that I am using. Then I use Cursor to import the CASE and UCO documentation so that it is indexed by Cursor. Do this by importing from https://ontology.caseontology.org/documentation/index.html or https://ontology.unifiedcyberontology.org/documentation/index.html. This makes it possible to have a local index of all of the documentation and change proposal.

4. Then I manually write out a prompt explaining what I am trying to accomplish, what I think the concept mappings are, providing real data and public references that define the new concepts, determine if the concepts are classes or properties, determining which namespace they should align to based on my understanding of the namespaces, etc. In this prompt I include references to the change proposal and ontology docs as reference. Finally, I ask the AI agent to ask me any clarifying questions which helps improve the context of my prompt. Sometimes, I reference another recent change proposal to the agent for more reference if it is something published in the last few weeks as the LLM services won't have scraped it yet. I do this by providing the URL directly to the issue in Github. I also reference any source data examples or data standards if I have them.

5. Then I submit this prompt to a thinking/planning agent like GPT 5 and I ask it to write a draft change proposal into a new .md file.

6. I read through the agent's questions, analysis, and draft. Sometimes, I intervene if the agent is going in the wrong direction which is typically caused by an issue I introduce or fail to introduce in my prompting. Typically, the first draft change proposal is a ~50% solution. From the first draft, I will follow up with additional prompts or apply my own manual edits as necessary to further refine the draft. Once I get to the 3rd or 4th draft using GPT 5, or which ever other LLM model agent I am working with, I open a new context window and ask a different agent (e.g.; Grok 4 or Claude 4.5 Sonnet) to read and analyze the draft change proposal.

7. The new AI agent will definitely have it's own analysis and proposed changes which I then decide how I want to disposition them. I make manual edits as necessary here too. Then, I might rotate the change proposal to a third AI agent if the change is more complex.

8. The key is to be the human in the loop. The more you know about: the ontologies' structure, how you would want to query the data in an investigation, and the desired query results you expect, the better off you will be with using AI agents to assist you. These AI agents continue to get better over time so the results you saw 3 months ago from an AI service will be much different today. I have not even gotten to the point of using multiple AI agents at the same time like some people are doing.

9. Lastly, and most importantly, annotate your post to say that you used AI to help you write the change proposal. The Ontology Committee will have lots of questions and perspectives on your change proposal, which you can then use to further prompt the AI agent you are using.

I did not use AI to write this response. I hope that my example helps.

I am happy to hold a meeting to show you with an example.

[plbt5]

@vulnmaster @chrishargreaves, be advised that given the US government shutdown @ajnelson-nist won't be able to support this work for the moment, and probably next week either.

[vulnmaster]

@chrishargreaves would you be available to attend the ontology committee meeting on Tuesday 21 October starting at 10 AM EST to discuss this issue? We are not ready for requirements review on this yet, but I think that we would gain some value in having a live discussion. This discussion will give us a chance to make any modifications to the draft change proposal I put together and then bring it to a requirements review vote at our November meeting. Hopefully @ajnelson-nist will be able to return by then.

[vulnmaster]

@plbt5 this issue should still be open.

[chrishargreaves]

@vulnmaster Yes absolutely. I'll attend. I'm going to try to make most of these meeting in future anyway as they are interesting.