Fixing parthood

[giacomodecolle]

No description provided.

[giacomodecolle]

Added this to map "contains" to "has continuant part". This seems to create inconsistencies when running a reasoner, so it will probably require more precise developments.

[giacomodecolle]

As an example

d3f:Certificate is Digital Information Bearer, i.e. an IBE in CCO terms, which d3f:contains some d3f:PublicKey. d3f:PublicKey is a d3f:DigitalInformation, i.e. an ICE in CCO terms.

Now, d3f:Certificate is an IBE and IBEs are material entities in CCO. Material Entity is axiomatized as only having sites, boundaries and other material entities as parts. And d3f:PublicKey being an information entity, it cannot be a part of d3f:Certificate.

Before we change the mappings, I wonder whether d3f:Certificate was meant to be a material entity in the first place.

[netfl0]

I suppose we need to decide if d3f:DigitalInformation is a material entity. This is from CCO:

We may want to remodel d3fend-cco in this context. CCO does not really seem to model Data, in D3FEND we call data DigitalInformation.

[giacomodecolle]

Yes, the question is whether d3f:DigitalInformation (and d3f:DigitalInformationBearer) are material or not. The information model of CCO is currently under scrutiny for changes (see this issue for example). So, I would rather focus on what we think is the case rather than the details of what current CCO subclasses of Information Bearing Artifact say.

For example, it makes more sense to me to say that a database is not material, because you and I can have two copies of the same database in our respective machines. The machines are physical but the database is not. And so on for most subclasses of d3f:DigitalInformation, and even for some of d3f:DigitalInformationBearer

Can you elaborate on what you mean by modeling Data? E.g. data structures and databases or digital files more broadly?

[netfl0]

Given the churn on CCO regarding these topics is feels premature for us to invest a ton of time in this.

The competency questions they've generated are interesting, but many are incomplete/in progress as pointed out here . The missing information Alan is referring to has major design implications.

All of these issues are why we've relented toward a single term, Digital Artifact to be stand-in while we collect data on actual use-cases by which we could justify some more complicated ontological model. We currently made the distinction between information and bearing entities as sort of an experiment to see if its too complicated to deal with in our applications.

We could easily fall into the trap of making endless distinctions. We need to better establish the criteria for reification and distinction, it is not clear what CCO's methodology for that is.

If there is a written cco design document explaining how these decisions are made, please make let us know.

[hack-sentinel]

The CCO certificate subclasses (as examples of intent) are aligned to true material artifacts, whereas we are using d3f:Certificate in the digital sense (there could be any number of copies of the certificate's information stored in different devices. If the keys are private that shouldn't be too widely spread, but it is possible.) I think for d3f purposes it would be fine, if not better, to call d3f:Certificate a subclass of DigitalInformation (an ICE). That would clear up the particular inconsistency flagged because of the materiality of the property's range. [There could be more of these kind of inconsistencies]

[I'll just say there's a lot of sifting and consistency work for CCO and D3FEND in representing the information and information systems at the core of cybersecurity. Identifying the distinctions we need to make with examples is probably the best way to make sure we have comprehensive (or nearly so) coverage across possible uses and we are actually talking about the same scenarios. Such examples is also far better at making engineers avoid miscasting individuals in their use, as they can compare to "cookbook examples" in addition to RTFO.]