Question on mapping - uco-core:Bundle vs uco-core:Compilation

[vulnmaster]

Ontology Committee,

I am looking to map the concept of a collection of multimedia files like a multimedia library (e.g.; Vulnmaster's Jazz Guitar Playlist) found on a popular service like iTunes, or a collection of pictures and videos from a birthday party (e.g.; Vulnmaster's 21st Birthday Party).

I can't find any current CASE examples of this so am thinking we might need a change proposal.

I'm thinking that we might need to create a new class named observable:MultimediaLibrary that subclasses from core:Bundle or core:Compilation

I am trying to determine the main differences between these two core classes as the rdfs:comment for each does not identify this, and I could not find any example of using core:Compilation in CASE-Examples.

For reference, here are the two classes from core.ttl

core:Bundle a owl:Class , sh:NodeShape ; rdfs:subClassOf core:EnclosingCompilation ; rdfs:label "Bundle"@en ; rdfs:comment "A bundle is a container for a grouping of UCO content with no presumption of shared context."@en ; sh:targetClass core:Bundle ; .

core:Compilation a owl:Class , sh:NodeShape ; rdfs:subClassOf core:UcoObject ; rdfs:label "Compilation"@en ; rdfs:comment "A compilation is a grouping of things."@en ; sh:targetClass core:Compilation ;

I created a custom OpenAI GPT for helping me map concepts to Cyber Domain Ontology. I asked my custom GPT to compare and contrast core:Bundle and core:Compilation for me. I'd like to know if there is general agreement in the Ontology Committee on this analysis and simple use cases. If so, we can use this to bolster the rdfs:comment descriptions of these classes, and then create working examples of using both of these uco-core classes in contrasting ways.

GPT Generated Text to Follow:

In UCO (Unified Cyber Ontology) and similar ontologies, core:Compilation and core:Bundle are both concepts used to represent groupings of objects, but they typically serve different purposes and have distinct connotations. Here's how they compare and contrast:

core:Compilation Purpose: core:Compilation is generally used to represent a collection of items that are brought together for a specific purpose or theme. The emphasis is on the thematic or functional unity of the items.

Examples: This could include a photo album, a playlist of songs, a collection of related documents, etc. The items in a compilation are usually related by subject, theme, or purpose.

Properties and Relationships: A core:Compilation may have properties describing its overall purpose, the criteria for inclusion of items, and relationships linking to each item within the compilation.

core:Bundle

Purpose: core:Bundle is typically used to represent a physical or logical grouping of items, where the focus is more on the act of grouping itself rather than the thematic relationship between the items.

Examples: This can be used to represent a digital file archive (like a ZIP file), a folder containing various files, or a packet of data sent over a network. The items in a bundle are grouped together more for convenience, packaging, or transmission rather than thematic content.

Properties and Relationships: A core:Bundle would have properties related to the mechanism of bundling (like compression, file paths, etc.) and relationships to the items it contains.

Key Differences

Context of Use: core:Compilation is more about thematic or purposeful aggregation, while core:Bundle is about the practical aspects of grouping items together.

Relationship Nature: In a compilation, the items are related by a common theme or purpose. In a bundle, the relationship is more about the container-contained dynamic.

Properties: The properties of a compilation would relate to its thematic aspects, whereas the properties of a bundle would relate to its physical or logical structure.

Use in Ontologies When modeling in UCO or similar ontologies, the choice between core:Compilation and core:Bundle would depend on the nature of the grouping you want to represent and the context in which this grouping is relevant to your data or analysis.

[vulnmaster]

After the UCO ontology committee discussion on 12/12/2023, the consensus was that core:Compilation class should not be directly map as it is a super class. Rather core:Bundle or another future proposed subclass should be mapped. This got me and another colleague thinking about various potential compilations that contain media based on how we actually compile media ourselves with a file system.

1. GenreBasedCompilation - represents media albums grouped based on music or image genre (e.g.; rock, classical, landscape, portrait). An example might be "Stadium Rock Hits" album that contains 5 selected hit songs in .mp3 format from the Stadium Rock genre.

2. EventDrivenCompilation - represents media albums organized by events (e.g., weddings, concerts, vacation). An example might be "Vulnmaster's Wedding Picture Album - February 2023" that contains images and videos.

3. CreatorCompilation - represents albums based on the creator or artist and may be useful for collections focusing on specific photographers or musicians. An example might be "Van Halen All-Time Hits" that contains 10 hit songs in .mp3 format.

4. DateBasedCompilation - represents albums sorted by creation or release date. An example might be "Vulnmaster's Pictures from Walk 20 Dec 2023" or "Vulnmaster's Text Messages 20 Dec 2023".

5. ThemeBasedCompilation - represents albums by them (e.g., nature, urban, mood-based playlist). An example might be "Vulnmaster's Yoga Music".

6. MixedMediaCompilation - represents a compilation that contains a bunch of mixed media. This could still be contextual in nature (think core.ContextualCompilation class) or just a loose grouping of media (think core:Bundle class).

With that said, it is still not clear which way to subclass these concepts under core:Compilation. Right now there are two subclasses for core:Compilation:

1. core:ContextualCompilation - a contextual compilation is a grouping of things sharing some context (e.g., a set of network connections observed on a given day, all accounts associated witha given person)
2. core:EnclosingCompilation - An enclosing compilation is a container for a grouping of things. This class has a subclass of core:Bundle - a bundle is a container for a grouping of UCO content with no presumption of shared context.

What I don't understand is the design intent behind the two existing subclasses derived from core:Compilation. The definition for core:ContextCompilation seems to be clear enough but it seems to be slanted towards things grouped together by a cyber-domain investigator or analyst focused on a certain context. In contrast core:EnclosingCompilation's definition does not adequatly set it apart from core:ContextCompilation as it is purely a container for a grouping of things with the core:Bundle class further decomposing the concept into a grouping of content with no presumption of shared context. What seems to be missing is a contextual bundle concept considering that we have asserted a no-context bundle concept.

Considering the example classes I provided above in this response is it safe to assume that example classes 1-5 are all contextual compilations thus making it possible to propose these as new subclasses under core:CompilationClass, or should we think about proposing a new class like core:ContextualBundle that would be a subclass from core:EnclosingCompilation? The later would give us room to re-imagine the definition of core:ContextualCompilation into something that an analyst or investigator creates on purpose that is completely seperate of what groupings a user or a subject of investigation might create.

Lastly, when thinking in terms of how users organize multimedia files they oftentimes have a library (e.g., iTunes or Google Photos) that then would have albums or individual files in them. I'm not sure exactly how we would accomodate this library concept, but I think that a multimedia library would be a subclass of core:EnclosingCompilation.

@sbarnum and @ajnelson-nist thoughts?

[ajnelson-nist]

@vulnmaster - I unfortunately don't have a lot of experiential insight into the nuances of those classes.

While they're currently implemented as two different class hierarchies, they are not encoded as disjoint. So, if you think you found a reason to define a compilation that "checks all the boxes" of a core:ContextualCompilation and core:Bundle, you could define this:

{
  "@id": "kb:Compilation-6779071f-6f97-4eb3-b611-cc5f7b654ee5",
  "@type": [
    "core:ContextualCompilation",
    "core:Bundle"
  ]
}

The English in the definitions makes it look like that's OK. The Bundle groups objects without assuming, or imposing, a shared context; the ContextualCompilation says "this group has a shared context". If Bundle said "These objects have no shared context," this situation would be different.

What I don't understand is why core:Compilation doesn't accomplish the goal of Bundle by itself. EnclosingCompilation and Bundle do not look, to me, like they do anything more than Compilation does, except for EnclosingCompilation imposing that there must be one member linked with core:object (which ContextualCompilation also does). Why there must be a member is not documented. Why Compilation does not require a member is not documented.

This conversation might be easier if UCO had a formal definition (i.e. class-encoding) of "Context". Until that concept comes around, if you have remaining questions about whether a thing you have should be an A or a B, and it matches the definitions of both, I suggest you call it both if nothing in the class hierarchy prevents you from doing so. I.e., if there is no owl:disjointWith statement saying two classes, or either of their parent classes, are disjoint, then you can say that your thing is a member of both classes. If this lets you encode something that feels wrong, then we're happy to look at whether UCO needs to adjust something, or whether there's another nuance with your thing.

[vulnmaster]

@ajnelson-nist Happy Holidays and thank you for your comments and your example. Your discussion on concepts being in dijoint or overlapping classes was helpful.

Your response also got me thinking about a working definition for "context". Thank you to my custom "CDO Mapper" @chatgpt for helping with the brainstorm for the definition!

Context is a conceptual framework that connects individual elements, providing a coherent and unified view of their collective significance. Within UCO, context is a set of circumstances or attributes that gives meaning to a group of related items or events within the cyber domain. Context encompasses the environmental, situational, and relational aspects that define or influence the understanding, interpretation, or relevance of these items or events.

A simple example of the encoding might look like this. I will have to defer to the ontologists (@sbarnum, @plbt5 and the others) on making recommendations on the proper implementation. I'm happy to lead a change proposal if others see value in this.

`@prefix uco-core: https://ontology.unifiedcyberontology.org/uco/core/ . @prefix rdfs: http://www.w3.org/2000/01/rdf-schema# .

uco-core:Context a rdfs:Class ; rdfs:label "Context" ; rdfs:comment "Context is a conceptual framework that connects individual elements, providing a coherent and unified view of their collective significance. Within UCO, context is a set of circumstances or attributes that gives meaning to a group of related items or events within the cyber domain. It encompasses the environmental, situational, and relational aspects that define or influence the understanding, interpretation, or relevance of these items or events." . `

[ajnelson-nist]

@vulnmaster I think I see a GitHub Markdown syntax typo - use triple backticks followed by the word turtle to turn on syntax highlighting. E.g.:

uco-core:Context
    a owl:Class ;
    ...
    .

(Also, UCO does not use rdfs:Class, it uses owl:Class.)

Meanwhile, if you are interested in pursuing this class, especially as it pertains to this proposal, try giving an example few individuals that exercise the class.

Take this English sketch, which I've drawn from one of your examples above: You stumble on a collection of MP3s you haven't listened to in a while. You set up a ContextualCompilation, into which you put two MP3s that, though of different bands, you recall contain songs you heard at a dual-header concert at one point. You set up another ContextualCompilation, into which you put all MP3s that you know are by bands that have a lead singer in common.

Did I describe two Contexts to you? If so, what do those two Context objects look like, as RDF data?

Can a core:Event be a Context?

Can an identy:Person be a Context?