## 3 ATON Framework
### Collections and Scenes  
The framework defines an important distinction between collection and scene concepts. A _collection_ is a set of items--including 3D models, panoramas, audio sources, etc.--that we intend to use to create an interactive 3D presentation or space. Formats of collection items within the framework must be suitable for the web (e.g., png. ; jpg, webm, mp4, mp3--just to name a few related to multimedia content). The main adopted format for 3D models is gITF with Draco compression (see state of the art section). Due to its interoperability, such standard offers content creators smooth integrations with several 3D software tools and engines (like Blender, Maya, Unreal Engine 4, etc....) while open-source tools (e.g., Cesium tools--[[https://github.com/CesiumGS](https://github.com/CesiumGS)]([https://github.com/CesiumGS](https://github.com/CesiumGS)), accessed on 22 November 2021) can be used to automate ingestion of desktop formats into collections. For more complex items (e.g., massive heterogeneous 3D geospatial content, or large photogrammetry models) Cesium 3D tiles open specification is adopted, thus offering smooth streaming of large multi-resolution items over the web (see Section 2). A _scene_ on the other hand, is an arrangement of collection items, with hierarchical organization and transformations offered by scene-graphs. A scene may indeed include specific viewpoints (POVs), keywords, semantics, soundscape, and much more. Such separation is quite common in several game-engines (e.g., Unreal Engine 4) where a collection of assets can be used and referenced to arrange multiple levels (scenes) in the project. A scene may indeed also consist of a single item (e.g., a 3D model) suitable for 3D galleries of online virtual museums, with each scene corresponding to a single collection item. Within a DN, each scene is assigned a unique identifier (a Scene-ID, or \"_sid_\" for short) in the form of a string (e.g., \"e45 huoj78\", \"demo/skyphos\", \"user3/site2/reconstruction\") which can be used by any ATON-based web-app to address a specific published 3D scene (see Figure 4). The scene itself is stored as a compact JSON file (scene descriptor), similar to the _svx JSON_ used by Voyager ([[https://smithsonian.github.io/dpo-voyager/explorer/scene-create/](https://smithsonian.github.io/dpo-voyager/explorer/scene-create/)]([https://smithsonian.github.io/dpo-voyager/explorer/scene-create/](https://smithsonian.github.io/dpo-voyager/explorer/scene-create/)), accessed on 22 November 2021). Scenes are thus very cheap in terms of storage (data layer) compared to collections. The JSON format offers direct manipulations by local ATON services, third-party services or web-based tools--as well as guaranteeing full extensibility. Several libraries (e.g., Three.js, Babylon.js, etc.) already provide import/export routines for entire scenes in their own JSON format, although they usually store information not required for CH scopes. ATON has the goal of keeping the JSON scene descriptor very light, since it targets a specific subset of features targeting Cultural Heritage (scene-graph, semantic graphs, soundscape, viewpoints, general scene information, etc.) that will be discussed in the next sections. Such an approach differs from other Web3D solutions (like SketchFab for instance) where the concepts of 3D model and scene overlap. The strict separation in ATON between scenes and collections has several advantages:  
* Re-use: the same item (3D model, panorama, audio, etc.) can be employed (and re-styled) in different scenes, avoiding unnecessary duplication in terms of storage Update: an item (e.g., a 3D model, a panorama, etc.)