%% Commands for TeXCount
%TC:macro \cite [option:text,text]
%TC:macro \citep [option:text,text]
%TC:macro \citet [option:text,text]
%TC:envir table 0 1
%TC:envir table* 0 1
%TC:envir tabular [ignore] word
%TC:envir displaymath 0 word
%TC:envir math 0 word
%TC:envir comment 0 0
%%
%% The first command in your LaTeX source must be the \documentclass
%% command.
%%
%% For submission and review of your manuscript please change the
%% command to \documentclass[manuscript, screen, review]{acmart}.
%%
%% When submitting camera ready or to TAPS, please change the command
%% to \documentclass[sigconf]{acmart} or whichever template is required
%% for your publication.
%%
%%
\documentclass[sigconf,review,anonymous]{acmart}
%%\documentclass[sigconf]{acmart}

%% Figures should be in CMYK or Grey scale format, otherwise, colour 
%% shifting may occur during the printing process.

%% it is recomended to use ``\cref{sec:bla}'' instead of ``Fig.~\ref{sec:bla}''
\graphicspath{{figures/}{pictures/}{images/}{./}} % where to search for the images

%%
%% \BibTeX command to typeset BibTeX logo in the docs
\AtBeginDocument{%
  \providecommand\BibTeX{{%
    Bib\TeX}}}

%% Diogo's packages
\usepackage{cleveref}
\usepackage{svg}
\usepackage{tabularx}
\usepackage{booktabs}
\usepackage{listings}

% Diogo Custom colours
\colorlet{punct}{red!60!black}
\definecolor{delim}{RGB}{20,105,176}
\colorlet{numb}{magenta!60!black}
\lstdefinelanguage{json}{
    basicstyle=\footnotesize\ttfamily,
    numbers=left,
    numberstyle=\scriptsize,
    stepnumber=1,
    numbersep=8pt,
    showtabs=false,
    showstringspaces=false,
    breaklines=true,
    frame=single,
    literate=
     *{0}{{{\color{numb}0}}}{1}
      {1}{{{\color{numb}1}}}{1}
      {2}{{{\color{numb}2}}}{1}
      {3}{{{\color{numb}3}}}{1}
      {4}{{{\color{numb}4}}}{1}
      {5}{{{\color{numb}5}}}{1}
      {6}{{{\color{numb}6}}}{1}
      {7}{{{\color{numb}7}}}{1}
      {8}{{{\color{numb}8}}}{1}
      {9}{{{\color{numb}9}}}{1}
      {:}{{{\color{punct}{:}}}}{1}
      {,}{{{\color{punct}{,}}}}{1}
      {\{}{{{\color{delim}{\{}}}}{1}
      {\}}{{{\color{delim}{\}}}}}{1}
      {[}{{{\color{delim}{[}}}}{1}
      {]}{{{\color{delim}{]}}}}{1},
}

%% Rights management information.  This information is sent to you
%% when you complete the rights form.  These commands have SAMPLE
%% values in them; it is your responsibility as an author to replace
%% the commands and values with those provided to you when you
%% complete the rights form.
\setcopyright{acmlicensed}
\copyrightyear{2025}
\acmYear{2025}
\acmDOI{XXXXXXX.XXXXXXX}
%% These commands are for a PROCEEDINGS abstract or paper.
\acmConference[UIST '25]{Make sure to enter the correct
  conference title from your rights confirmation email}{September 28--October 01,
  2025}{Busan, Korea}
%%
%%  Uncomment \acmBooktitle if the title of the proceedings is different
%%  from ``Proceedings of ...''!
%%
\acmBooktitle{38th Annual ACM Symposium on User Interface Software and Technology (UIST '25),
  September 28--October 01, 2025, Busan, Korea}
\acmISBN{978-1-4503-XXXX-X/2018/06}

%%
%% Submission ID.
%% Use this when submitting an article to a sponsored event. You'll
%% receive a unique submission ID from the organizers
%% of the event, and this ID should be used as the parameter to this command.
%%\acmSubmissionID{123-A56-BU3}

%%
%% For managing citations, it is recommended to use bibliography
%% files in BibTeX format.
%%
%% You can then either use BibTeX with the ACM-Reference-Format style,
%% or BibLaTeX with the acmnumeric or acmauthoryear sytles, that include
%% support for advanced citation of software artefact from the
%% biblatex-software package, also separately available on CTAN.
%%
%% Look at the sample-*-biblatex.tex files for templates showcasing
%% the biblatex styles.
%%

%%
%% The majority of ACM publications use numbered citations and
%% references.  The command \citestyle{authoryear} switches to the
%% "author year" style.
%%
%% If you are preparing content for an event
%% sponsored by ACM SIGGRAPH, you must use the "author year" style of
%% citations and references.
%% Uncommenting
%% the next command will enable that style.
%%\citestyle{acmauthoryear}


%%
%% end of the preamble, start of the body of the document source.
\begin{document}

%%
%% The "title" command has an optional parameter,
%% allowing the author to define a "short title" to be used in page headers.
\title{AURA: The Augmented Reality Unified Representation Architecture}

%%
%% The "author" command and its associated commands are used to define
%% the authors and their affiliations.
%% Of note is the shared affiliation of the first two authors, and the
%% "authornote" and "authornotemark" commands
%% used to denote shared contribution to the research.
\author{Diogo Peralta Cordeiro}
\email{mail@diogo.site}
\orcid{0000-0002-0260-5121}
\author{João Borges de Sousa}
\email{jtasso@fe.up.pt}
\orcid{0000-0002-2528-4666}
\affiliation{%
  \institution{University of Porto}
  \city{Porto}
  \country{Portugal}
}

%%
%% By default, the full list of authors will be used in the page
%% headers. Often, this list is too long, and will overlap
%% other information printed in the page headers. This command allows
%% the author to define a more concise list
%% of authors' names for this purpose.
\renewcommand{\shortauthors}{Diogo et al.}

%%
%% The abstract is a short summary of the work to be presented in the
%% article.
\begin{abstract}
Current Augmented Reality (AR) frameworks lack standardisation and platform independence in how applications specify their spatial and system-level requirements, complicating cross-platform development and limiting the coexistence of multiple AR applications. We introduce AURA --- the \textbf{A}ugmented Reality \textbf{U}nified \textbf{R}epresentation \textbf{A}rchitecture ---, which defines a manifest format that allows applications to specify their spatial components, interaction patterns, participating agents, and required system resources. By assigning applications to scoped containers and managing shared physical surfaces access, AURA enables concurrent execution while preserving spatial coherence. It also supports dynamic behaviour through event-driven triggers and system-mediated data exchanges at runtime.
\end{abstract}

%%
%% The code below is generated by the tool at http://dl.acm.org/ccs.cfm.
%%
\begin{CCSXML}
<ccs2012>
   <concept>
       <concept_id>10003120.10003121.10003124.10010392</concept_id>
       <concept_desc>Human-centered computing~Mixed / augmented reality</concept_desc>
       <concept_significance>500</concept_significance>
       </concept>
   <concept>
       <concept_id>10003120.10003138.10003139.10010904</concept_id>
       <concept_desc>Human-centered computing~Ubiquitous computing</concept_desc>
       <concept_significance>300</concept_significance>
       </concept>
   <concept>
       <concept_id>10003120.10003123</concept_id>
       <concept_desc>Human-centered computing~Interaction design</concept_desc>
       <concept_significance>100</concept_significance>
       </concept>
 </ccs2012>
\end{CCSXML}

\ccsdesc[500]{Human-centered computing~Mixed / augmented reality}
\ccsdesc[300]{Human-centered computing~Ubiquitous computing}
\ccsdesc[100]{Human-centered computing~Interaction design}

%%
%% Keywords. The author(s) should pick words that accurately describe
%% the work being presented. Separate the keywords with commas.
\keywords{Spatial Computing, Application Manifest, Multi-application Systems, Intelligent Environments, Machine Perception, Interactive Spaces}

%% A "teaser" image appears between the author and affiliation
%% information and the body of the document, and typically spans the
%% page.
\begin{teaserfigure}
  \centering
  \includesvg[inkscapelatex=false, width=0.7\linewidth]{figures/teaser.drawio.svg}
  \caption{Overview of AURA's role during multi-application deployment, enabling Applications 1 and 2 to coexist within the same physical space.
  a) An AURA-based system scans the room, and independently created and launched applications submit their spatial and behavioural requirements through AURA manifests.
  b) The AURA-powered Head-Mounted Display (HMD) identifies suitable components in the environment and, with user input, assigns them to each application by creating dedicated ambients (e.g., $\alpha_1$, $\alpha_2$).}
  \label{fig:teaser}
\end{teaserfigure}

\received{11 July 2025}
%\received[revised]{12 March 2009}
%\received[accepted]{5 June 2009}

%%
%% This command processes the author and affiliation and title
%% information and builds the first part of the formatted document.
\maketitle

\section{Introduction}
Augmented Reality (AR) is emerging as a key paradigm for immersive computing, blending digital content with the physical world in real time. Currently, and in spite of rapid advances in hardware and toolkits, developing AR applications today remains a fragmented endeavour. Different platforms (e.g., mobile AR toolkits, smart-glasses) and engines (e.g., Unity, Unreal) impose distinct content representations and siloed runtime contexts, making it difficult to coordinate multiple AR experiences. In practice, users are often confined to one AR application at a time, and there is no straightforward way to allow multiple AR apps to augment the environment concurrently \cite{huynh2022layerable}.

Most existing AR development platforms, such as Unity's XR Interaction Toolkit and Unreal Engine's AR APIs, are geared toward building single-application experiences. These tools provide abstractions for tracking, rendering, and input (e.g., ARKit provides world tracking and scene understanding \cite{ARKitDocumentation}, ARCore offers similar capabilities \cite{ARCoreDocumentation}), but they lack a standardized model for representing application structure, coordinating access to physical components, or supporting interaction logic across applications. This single-app focus limits scalability, complicates cross-platform deployment, and hinders the development of multi-application AR environments.

Current AR experiences are typically built in isolation: there is no standard way for one AR application to expose or to incorporate content from others, limiting content reuse and preventing multi-application scenarios (e.g., a navigation app and a social AR app cannot easily co-exist and share the view \cite{lebeck2019multiple}). Prior efforts to standardize AR content (such as AR markup languages or model-based UI design tools like ARML~\cite{OGC_ARML2_Adoption} or SSIML/AR~\cite{vitzthum2006ssimlar}) have not been widely adopted by today's AR platforms, which favour imperative and engine-specific approaches.

There is a growing need for cross-application interoperability and consistency, akin to how web browsers unified content on the Internet. As illustrated in \cref{fig:teaser}, AURA addresses the standardisation problems by defining a unified representation layer that sits between AR applications and the underlying AR runtime or operating system. At its core, AURA introduces a manifest format, expressed in JSON-LD, that allows applications to formally declare their spatial and behavioural requirements, including entities, components, agents, and interaction logic. The AURA-based system, in turn, guides the runtime context definition, including available physical components, spatial subdivisions (\textit{ambients} and \textit{worlds}), and mappings between devices and applications. AURA does not enforce a single global spatial model; instead, each application is bound to an ambient-scoped view, enabling coexistence through a layered abstraction of space. The \textit{``unified''} nature of AURA refers to its consistent runtime contract: all applications interface with the system using a common schema, while the system tracks general interaction and coordinates access to components without requiring direct inter-application communication.

\section{Proposed Architecture and Runtime}\label{sec:aura-architecture}

Execution in AURA begins when a user launches one or more applications, each submitting its manifest to the AURA-based system. At runtime, the system monitors spatial triggers, schedules component updates, routes input and output, and manages state transitions, all according to the declarative contracts. This process explicitly ensures negotiated component use, avoids runtime conflicts (e.g., overlapping visual output or sensor contention) upfront, and facilitates a consistent understanding of spatial layout between the system and applications.

AURA provides a structured and extensible runtime model for AR systems by decoupling application behaviour from system-level resource management. AURA's contract is defined by two JSON-LD-based manifests: the static application manifest and the dynamic system manifest. The application manifest, authored by the developer, defines an AR application's structure, component requirements, entities, and behaviour. It specifies abstract requirements such as minimum spatial dimensions and expected coordinate systems, as well as roles for agents (e.g., tracked users with hand or position tracking services) and required physical characteristics and I/O capabilities for components (e.g., minimum dimensions for a flat surface, or visual output capabilities). The system manifest, generated at setup time or by an administrator, defines the physical AR environment, available concrete components (e.g., a specific ``table top'' with spatial attributes and capabilities), agents, ambients, and their grouping into worlds. Ambients define spatially and logically bounded contexts, grouping components and enforcing isolation. Ambients can be grouped into worlds, which are higher-level constructs enabling shared spatial and semantic contexts and defining global coordination rules such as data visibility and access policies. These manifests collectively define the logical, spatial, and operational interface between AR applications and their runtime environment.

\paragraph{Ambient/World Scope and Security Guarantees} Shared components must not be assigned to overlapping ambients, and applications can only observe and write to components within their assigned ambient. Outputs (e.g., visual rendering or actuator control) must target components currently available in the ambient. Cross-ambient observation requires explicit world-scoped coordination. These constraints mitigate several threats outlined by Ruth et al.~\cite{Ruth2019ARsecurity}, including attempts by one user to (1) share unwanted or undesirable content, (2) see private content belonging to another user, or (3) manipulate another user's AR content. By scoping visibility and interaction to well-defined ambients,  AURA provides strong default boundaries.

\paragraph{Component-Based Memory Sharing} Components in AURA expose structured data stores that act as shared memory spaces. This memory is accessible to the application assigned to the ambient the component belongs to, and may be readable across ambients if the component is part of a world, though writes are ambient-scoped. AURA supports data exchange between applications by attaching shared memory to components, enabling coordination without direct application dependencies. Applications may subscribe to updates on component storage (event-driven access) or query current/historical changes (request-based access). The system is responsible for producing consistent snapshots of component memory to avoid inconsistent histories.

AURA distinguishes between system-managed components and application-defined virtual elements. Virtual elements --- such as photos, tools, avatars, or icons --- are not explicitly declared in manifests, but their behavior can be grounded and made interoperable by binding them to component-based shared memory. This model allows for spatial anchoring, inter-application observability, and indirect coordination across loosely coupled applications.

\section{Conclusion and Future Work}

AURA enables modular development, scalable coordination, and conflict-free coexistence across applications. Currently, AURA assumes a centralized runtime and lacks global synchronization guarantees, which may lead to diverging histories when applications observe shared state independently. Future work includes implementing a reference runtime with arbitration and event routing, formal validation of manifests and ambient compatibility constraints, and distributed orchestration across heterogeneous AR platforms. We are particularly interested in probabilistic extensions to heuristic evaluation for improving tracking and rendering on moving objects, as well as developing an ambient calculus for structured data exchange between components.

%%
%% The next two lines define the bibliography style to be used, and
%% the bibliography file.
\bibliographystyle{ACM-Reference-Format}
\bibliography{biblio}

\end{document}
\endinput
