Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Deduplicate the Datatype Property declarations #37

Closed
rhohimer opened this issue Feb 4, 2023 · 3 comments
Closed

Deduplicate the Datatype Property declarations #37

rhohimer opened this issue Feb 4, 2023 · 3 comments
Labels
Low Priority This is an issue that can be addressed when we have the manpower and time

Comments

@rhohimer
Copy link
Contributor

rhohimer commented Feb 4, 2023

When the stix.owl ontology was divided into many namespaces there were multiple definitions asserted for the properties in each namespace. For instance, multiple declarations for "name" or "value". Basically, common properties were declared in each namespace.

@mateusdz
Copy link
Contributor

After the ontology refactors, we have reduced the namespaces count to one (stix namespace). All common properties are collected in one file and reused in all STIX objects. However, there exist several properties (that are not common properties, but) many objects are using, e.g., "name" and "description."

@mateusdz
Copy link
Contributor

In file.owl, the file object is defined together with its extensions. Here both the base class and the extensions have the same property name and values in two properties, "name" and "size." In this case, to avoid conflicts, I have defined these properties only once without the descriptions of the properties.

@rhohimer rhohimer added the Low Priority This is an issue that can be addressed when we have the manpower and time label Jun 22, 2023
@rhohimer
Copy link
Contributor Author

This is a duplicate of Issue #20 regarding deduplication of datatype properties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Low Priority This is an issue that can be addressed when we have the manpower and time
Projects
None yet
Development

No branches or pull requests

2 participants