Issue 49 implement the stix 21 windows registry datatype enumeration

[brett-heffelfinger]

Closes #49

Need feedback/suggestions on the triples as they relate to the idea of enumeration, like in #103.

[uscholdm]

'reg' is redundant in the IRI. Suggest to make changes like this for each instance. If my memory serves me, this is consistent with what we have done elsewhere.

Suggested change

	gist:_WindowsRegistryDatatype_reg-binary
	a gist:WindowsRegistryDatatype ;
	skos:definition """STIX 2.1 description:
	Binary data in any form."""^^xsd:string ;
	skos:prefLabel "REG_BINARY"^^xsd:string ;
	gist:stixTerm "REG_BINARY"^^xsd:string ;
	.
	gist:_WindowsRegistryDatatype_binary
	a gist:WindowsRegistryDatatype ;
	skos:definition """STIX 2.1 description:
	Binary data in any form."""^^xsd:string ;
	skos:prefLabel "binary"^^xsd:string ;
	gist:stixTerm "REG_BINARY"^^xsd:string ;
	.

[rhohimer]

The vocabularies that are being implemented to support the STIX 2.1 specification should make it easy for current practitioners to recognize the STIX term in gistCyber. Ingesting code (such as SPARQL-Anything) maps from the STIX 2.1 JSON documents to the gistCyber concepts without problem because we know the STIX vocabulary term and the gistCyber term. The reasoning for keeping the exact representation of the STIX vocabulary term in the IRI construction was to minimize the disassociation between the STIX term and the gistCyber term. The STIX vocabularies are not of the quality that we at Semantic Arts would like. But, we should make sure that practitioners who use STIX are not confused by gistCyber. We need to be able to “round-trip” from STIX 2.1 JSON documents to gistCyber knowledge graphs and back to STIX 2.1 JSON. Of course, there is lossiness, but we need to be able to write as much back to STIX 2.1 JSON as possible. This holds true for all the STIX vocabularies. The implementations of these vocabularies and enumerations must support the writing of STIX 2.1 JSON. Because of this the implementation of gistCyber should capture the exact stix terms somewhere so that the knowledge is in the ontology not the translation code. Two considerations: 1. STIX Practitioner ease of use 2. Ingest and Export of STIX 2.1 JSON Cheers, Ryan Hohimer Journeyperson Ontologist Cell Phone: (509) 430-6890 ***@***.******@***.***> https://www.semanticarts.com<https://www.semanticarts.com/> ***@***.*** From: Michael Uschold ***@***.***> Sent: Friday, June 6, 2025 2:29 PM To: semanticarts/gistCyber ***@***.***> Cc: Ryan Hohimer ***@***.***>; Review requested ***@***.***> Subject: Re: [semanticarts/gistCyber] Issue 49 implement the stix 21 windows registry datatype enumeration (PR #105) @uscholdm requested changes on this pull request.

________________________________ In ontologies/vocabs.ttl<#105 (comment)>:

+gist:_WindowsRegistryDatatype_reg-binary

+ a gist:WindowsRegistryDatatype ; + skos:definition """STIX 2.1 description: +Binary data in any form."""^^xsd:string ; + skos:prefLabel "REG_BINARY"^^xsd:string ; + gist:stixTerm "REG_BINARY"^^xsd:string ; + . 'reg' is redundant in the IRI. Suggest to make changes like this for each instance. If my memory serves me, this is consistent with what we have done elsewhere. ⬇️ Suggested change

…

-gist:_WindowsRegistryDatatype_reg-binary - a gist:WindowsRegistryDatatype ; - skos:definition """STIX 2.1 description:

-Binary data in any form."""^^xsd:string ; - skos:prefLabel "REG_BINARY"^^xsd:string ; - gist:stixTerm "REG_BINARY"^^xsd:string ; - . +gist:_WindowsRegistryDatatype_binary + a gist:WindowsRegistryDatatype ; + skos:definition """STIX 2.1 description: +Binary data in any form."""^^xsd:string ; + skos:prefLabel "binary"^^xsd:string ; + gist:stixTerm "REG_BINARY"^^xsd:string ; + . — Reply to this email directly, view it on GitHub<#105 (review)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACLF2VLWJD2RXDOMQ5VWPXL3CH2ZNAVCNFSM6AAAAAB6YUDH3WVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZDSMBWGA3TOOJTGA>. You are receiving this because your review was requested.Message ID: ***@***.******@***.***>>

[uscholdm]

This holds true for all the STIX vocabularies. The implementations of these vocabularies and enumerations must support the writing of STIX 2.1 JSON. Because of this the implementation of gistCyber should capture the exact stix terms somewhere so that the knowledge is in the ontology not the translation code.
Two considerations:

1. STIX Practitioner ease of use
2. Ingest and Export of STIX 2.1 JSON

Using gist:stixTerm makes round-tripping possible, but its more work and for those already familiar with STIX, it could be initially confusing. For those unfamiliar with STIX, removing redundancy in labels may be preferred, and it is better practice (IMHO). It's a tradeoff. I'm ok with going the simple route for now, knowing that it might be adding a tad of technical debt.