NTO/GFS: add Bardioc Graph File System namespace (5 entities, 2 verbs, 17 attributes)

[boosc]

Summary

This PR adds a new ogit.GFS: sub-namespace under NTO/GFS/
for the Bardioc Graph File System (GFS) -- a platform-level
filesystem that turns files, folders, symbolic links, sharing
tokens, and file-type-to-app mappings into first-class graph
constructs. Permissions and sharing are expressed through the
platform's existing scope, role-rule, and ACL-materialisation
mechanisms; this PR introduces no parallel permission layer.

The diff is intentionally minimal: five new entities, two new
verbs, seventeen new attributes. Two existing constructs
(ogit:contains, ogit.Auth:isMemberOf) are reused unchanged.

What is added

Entities (NTO/GFS/entities/)

Type	Purpose
ogit.GFS:File	Filesystem file; mandatory MIME plus content-pointer; blob=true
ogit.GFS:Folder	Container vertex; reuses ogit:contains; inheritPermissions toggle; optional vaultRoot marker
ogit.GFS:Symlink	Reference vertex with one outgoing refersTo edge
ogit.GFS:ShareLink	Capability-bearing token vertex for non-Bardioc recipients; token indexed
ogit.GFS:AppHandler	MIME-pattern-to-Bardioc-app mapping

Verbs (NTO/GFS/verbs/)

Verb	From	To	Purpose
ogit.GFS:refersTo	Symlink	ogit:Entity (type-agnostic)	Symlink target; 16-hop max resolution
ogit.GFS:sharedVia	File, Folder	ShareLink	external sharing

Attributes (NTO/GFS/attributes/)

Seventeen new attributes: mimeType, inheritPermissions,
vaultRoot, minDeviceSecurityLevel, restrictToDevices,
mimePattern, appId, priority, scopeRef, capability,
token, expiresAt, maxUses, usedCount, allowedEmails,
revokedAt, archivedAt. See each TTL for the per-property
description.

capability is a vertex-property on ShareLink (not an edge
attribute -- Bardioc edges cannot carry attributes). The five
recognised capability values are read, write, share,
admin, delete.

minDeviceSecurityLevel and restrictToDevices are defined
on both File and Folder. Folder-level usage is inherited
by every File reached through the Folder's ogit:contains-chain
(subject to inheritPermissions).

What is NOT in this PR

Platform-reserved materialised ACL attributes

The platform materialisation pipeline maintains two attributes
on every GFS vertex that are not part of this diff:

• _effectiveReaders -- multi-value Account-and-Team IDs,
  indexed; lists who may read.
• _effectiveDevices -- multi-value Device IDs, indexed; lists
  which devices may render.

These attributes belong in the platform-reserved namespace
(alongside ogit/_acl), not in ogit.GFS:, because the
maintaining party is the platform's materialisation pipeline,
not the GFS sub-system. Their exact naming is one of the open
issues below.

Platform extensions in NTO/Auth/ and SGO/sgo/

Four constructs outside NTO/GFS/ are needed for GFS to
function but ship in a separate platform-team PR, coordinated
with the OGIT review:

• ogit.Auth:Device (new entity in NTO/Auth/entities/) --
  end-user-device vertex with securityLevel 0-100. Distinct
  from the SGO datacenter-equipment ogit:Device.
• ogit.Auth:usesDevice (new verb in NTO/Auth/verbs/) --
  Account-to-Device, many-to-many.
• ogit:hasVault (new verb, location open: SGO/sgo/verbs/ or
  NTO/Auth/verbs/) -- Person-to-DataScope, anchors a Personal
  Vault to a Person so it survives Account deactivation.
• Workspace marker on ogit.Auth:Team -- new optional boolean
  attribute signalling "self-service Workspace, members manage
  themselves, has its own DataScope".

Audit events

GFS does not introduce an AuditEvent vertex type. Audit is a
platform-level concern and a separate consolidation project;
GFS commits to emitting audit-relevant events through the
existing platform AuditEventListenerRegistry.

Open issues for the OGIT review

Three points where the GFS team has chosen a direction but
wants the OGIT review to ratify or redirect.

Issue 1 -- Namespace of the materialised ACL attributes.
The diff proposes ogit/_effectiveReaders and
ogit/_effectiveDevices in the platform-reserved namespace
alongside ogit/_acl. They could equivalently live in
ogit.GFS: if the OGIT review prefers ownership symmetry. The
working assumption is that the maintaining party (the
platform's materialisation pipeline) owns the namespace, not
the consuming sub-system.

Issue 2 -- vaultRoot as property or subtype. This PR
carries vaultRoot as a boolean attribute on Folder. An
alternative is a small ogit.GFS:VaultRootFolder subtype. The
property path keeps the diff smaller; the subtype path is
semantically cleaner. OGIT-review preference welcome.

Issue 3 -- Capability vocabulary persistence. The five-
capability vocabulary (read, write, share, admin,
delete) lives only as constraint metadata on the ShareLink
capability attribute and as semantic vocabulary in the GFS
documentation. The OGIT review may want a formal capability
enumeration entity. The working assumption is no; a documented
string set is sufficient.

Owner-string convention question

These are the first new OGIT entities authored under Almato AG
(post arago-Almato merger). All seven new TTL types carry
dcterms:creator "Almato AG" plus ogit:admin-contact /
ogit:tech-contact "Almato AG" on the entity and verb files.
We assume this is the correct owner string going forward; please
flag if the OGIT convention requires arago GmbH as historical
owner-string constancy -- mechanical replace if so.

Diff stats

• 24 new TTL files under NTO/GFS/: 5 entities, 2 verbs, 17
  attributes.
• 0 files modified outside NTO/GFS/.
• All 24 files validate cleanly with rdflib 7.6.0
  (turtle parse).
• Total new triples added across the 24 files: roughly 280.

Companion concept document

The full concept that motivates this ontology lives at
bardioc_gfs/_concept/01_overall_concept.md (Overall Concept)
and bardioc_gfs/_concept/02_ogit_extensions.md (this PR's
narrative). A reviewer-friendly Word build of both lives in
the Bardioc Product Management Dropbox under
Bardioc GFS/Reviewable Deliverables/. Six reviewer passes
(Viktor R1+R2, Thommy R1, Patrick R1+R2, Cy R1+follow-ups) are
recorded in the change-log appendix of the Word documents.