Here it would mean initially a volume (as in a metric cuboid) per shared filesystem where each file would have coordinates in it.
Beyond that it would mean having recognized items from recognition services, i.e markers (ArUco, color discs, etc), but also OCR, HWR, even familiar objects (using e.g BundleSDF).
Inspired by DynamicLand, fold.computer and own work (with SpaSca, spacial scaffolding) combined with this work, extend the shared filesystem as a workspace (as done for Future of Text, cf https://git.benetou.fr/utopiah/offline-octopus/src/branch/responsive-workspace-demoday/index.js#L288 ) to have 3D coordinates for items.
Here it would mean initially a volume (as in a metric cuboid) per shared filesystem where each file would have coordinates in it.
Beyond that it would mean having recognized items from recognition services, i.e markers (ArUco, color discs, etc), but also OCR, HWR, even familiar objects (using e.g BundleSDF).
per directory and possible sub-directories ( e.g ~ and ~/this, ~/this/that, etc), basically a single database (much faster to query) or even
per file (e.g ~/filename getting its own ~/.spacialmetadata_filename )
To be coherent with (Linux) filesystems per directory might be the best option.
This makes quite some assumptions, i.e that a file is only represented relative to its current filesystem once. It's correct when there is a single spacial workspace shared. It is probably not correct in other contexts, e.g a shared workspace shared with other remote workspaces. Still, some pragmatic assumptions have to exist so it could be sufficient to start.
Consider sidecar files, could be :
* per directory (e.g ./here/ but not ./here/there )
* per directory and possible sub-directories ( e.g ~ and ~/this, ~/this/that, etc), basically a single database (much faster to query) or even
* per file (e.g ~/filename getting its own ~/.spacialmetadata_filename )
To be coherent with (Linux) filesystems per directory might be the best option.
This makes quite some assumptions, i.e that a file is only represented relative to its current filesystem once. It's correct when there is a single spacial workspace shared. It is probably not correct in other contexts, e.g a shared workspace shared with other remote workspaces. Still, some pragmatic assumptions have to exist so it could be sufficient to start.
Interesting to consider also in the context of XRShell where users interact directly with the filesystem in order to see visual changes in their 3D immersive space.
Interesting to consider also in the context of XRShell where users interact directly with the filesystem in order to see visual changes in their 3D immersive space.
Inspired by DynamicLand, fold.computer and own work (with SpaSca, spacial scaffolding) combined with this work, extend the shared filesystem as a workspace (as done for Future of Text, cf https://git.benetou.fr/utopiah/offline-octopus/src/branch/responsive-workspace-demoday/index.js#L288 ) to have 3D coordinates for items.
Here it would mean initially a volume (as in a metric cuboid) per shared filesystem where each file would have coordinates in it.
Beyond that it would mean having recognized items from recognition services, i.e markers (ArUco, color discs, etc), but also OCR, HWR, even familiar objects (using e.g BundleSDF).
Consider sidecar files, could be :
To be coherent with (Linux) filesystems per directory might be the best option.
This makes quite some assumptions, i.e that a file is only represented relative to its current filesystem once. It's correct when there is a single spacial workspace shared. It is probably not correct in other contexts, e.g a shared workspace shared with other remote workspaces. Still, some pragmatic assumptions have to exist so it could be sufficient to start.
Interesting to consider also in the context of XRShell where users interact directly with the filesystem in order to see visual changes in their 3D immersive space.