Some Datatype Properties are declared in multiple namespaces. De-dupe the concept declarations.

[rhohimer]

The same concept should not be declared multiple times in different namespaces.

[rhohimer]

The two namespaces are &stixCore and &cti

A solution that preserves what I think @CyberDaedalus00 is trying to do here is to make the &stixCore Datatype Properties subproperties of the &cti properties.

I'll chat with Paul to confirm that sub-property does what he wants (which I believe is to retain the knowledge that CTI-TC was the origin of the dataproperties).

If this is the path forward, the subproperty assertions should be done in the &stixCore namespace.

[rhohimer]

I have not yet talked to @CyberDaedalus00 about this issue.

It seems there are a couple of solutions available:

1. Delete the definitions from the duplicate definitions from the cti: namespace
2. Delete the definitions from the duplicate definitions from the stixCore: namespace
3. Make the stixCore: definitions subproperties of the cti: properties

Of these three solutions, I favor the first... Delete the defintions from the cti: namespace. This of course will require the assertion of the proper defintions in the stixCore:StixObject definition. (replacing cti: defintions with stixCore: defintions)

[rhohimer]

The following are Datatype Properties with multiple definitions:

abstract administrative_area analysis_ended analysis_started atime authors city comment confidence content context count country created creator_user_reference_id ctime defanged description display_name explanation extension_type extension_types external_id first_seen hash_algorithm hash_value id key_identifier key_value kill_chain_name labels lang languages last_seen machine_hex mime_type modified mtime name (x3) opinion phase_name priority published report_types resolves_to_refs_id revoked roles sid source_name _specversion start_time stop_time street_address subject submitted type url valid_from valid_until value (x5) vendor version (x4)

These should be reviewed and determined if multiple definitions are appropriate. Bolded and Italicized listing are involved with the stixCore:StixObject.

HOLY MOLY... this is a bigger issue that I first thought. This needs to be cleaned up and these dupes need to be disambiguated. Using an ontology with this many duplicated definitions in multiple namespaces is extremely confusing to users.

[rhohimer]

I'm starting with the Datatype Properties associated with the stixCore:StixObject.

I'll add the proper definitions, then delete the improper definitions.

[rhohimer]

I am very discouraged by the size and level of effort needed to address this issue. It is much larger in scope than I had first realized.

[rhohimer]

Here is a picture of the duplicates that still need to be addressed:

[rhohimer]

This problem is not limited to Datatype Properties. It also exists in the Object Properties.

[rhohimer]

Again, made cti: properties the super properties of stixCore: properties There are still a few duped definitions.

[rhohimer]

The stixCore:StixDomainObject still has some cti namespace properties that need to be examined.

It may be that we need to add subproperty definitions for these.

[rhohimer]

Sigh... This problem of duplicate definitions in multiple namespaces EXTENDS INTO THE CLASS DEFINITIONS!! The issue at the core of this problem is the assertion of two namespaces. One is the "cti:" namespace and the other is the "stixCore" namespace. Unfortunately, I can not see that the definitions of these classes, datatype properties, and object properties differ between the two namespaces.

The resolution that I am using is to subclass the stixCore defintions from the cti definitions. Subclassing in this way makes the stixCore definition EVERYTHING that a cti defintion is. The intent of a subclass is that a NamedIndividual of the subclass is equivalent to the superclass PLUS additional attributes that make it more specialized.

The problem with using this approach to resolve this multiple definition issue is that the stixCore subclasses are not bringing any added specializations to the table. However, I don't want to delete the cti definitions because I believe the original intent by @CyberDaedalus00 (Paul) was to capture the fact that the CTI-TC was the origin of the concept and that this generic definition may be used by other standards besides STIX.

If it turns out that the TAC-TC believes that the cti namespace is not necessary we can choose to delete the definitions altogether. This would mean a single stixCore namespace.

Last, but not least, is that the subclass and subproperty assertions are being done in the tac namespace. I believe this will make any future modifications easier.

[rhohimer]

Given the number of issues discovered in the structure of the classes and properties it may be best to close this Issue and open individual issues for smaller subsets of the problems. For instance, think of the logic represented in the following graphic:

It shows an assertion that stixCore:StixObject may have a cti:extensions object property that has a range of cti:ExtensionDefintion. It is my opinion that the StixObject predicate should be defined as a stixCore predicate with a range of stixCore:ExtensionDefinition

I think that we should discuss closing this issue and opening separate issues for things discovered like the issue above. I'm not closing this issue until discussed with the members. However, I am opening another issue to address the cti:ExtensionDefinition see: #17

[rhohimer]

This issue is being closed as #18 supersedes it.