Post Function Errors and UI Problems here

In a dataspace, policies define who may use which data, for what purpose, and under which obligations. Policies are part of contract offers and agreements, not optional extras. A policy agent (policy decision point) evaluates requests against rules and returns allow/deny before data leaves the provider.

Eclipse Dataspace Components use a policy engine on the control plane to attach constraints to assets and contract definitions. During negotiation, both sides must agree on compatible policies before contract finalization and data transfer. ODRL-based expressions are common for machine-readable rights: ODRL model (W3C).

For API-level runtime authorization (for example SPARQL endpoints), MAT-X can use Open Policy Agent (OPA) with Rego policies. OPA evaluates request attributes (method, path, bearer token, etc.) and keeps policy logic separate from application logic.

Further reading

• Open Policy Agent (Wikipedia) - policy-as-code overview
• EDC policy engine - connector policy evaluation
• ODRL Information Model (W3C) - rights and obligations vocabulary
• IDS RAM - data sovereignty - policy enforcement in IDS architecture
• Gaia-X trust framework - compliance, credentials, policy

A semantic data model describes what data means, not just how it is stored. Resources are linked to shared vocabulary concepts so machines and humans can interpret and query data consistently across systems.

On the web of data, meaning is represented with graph standards:

• RDF expresses facts as subject-predicate-object triples.
• OWL 2 defines classes, properties, and logical constraints.
• SHACL validates whether instance data matches expected structures.

An ontology formally specifies a domain: classes, object properties, datatype properties, and subclass axioms. Reference ontologies like PMD Core ontology anchor project-specific extensions so new terms stay interoperable. MAT-X pipelines (Autoencoder, Agent-TOM) extract or learn candidate classes but ground exports under reference rdfs:subClassOf parents.

Further reading

• Semantic Web (Wikipedia) - standards and linked data
• Ontology - information science (Wikipedia) - ontology role in knowledge representation
• RDF 1.1 Concepts (W3C) - graphs, IRIs, literals, datasets
• OWL 2 Web Ontology Language Primer (W3C) - classes, properties, reasoning
• Apache Jena documentation - RDF storage, SPARQL, Fuseki
• Gaia-X interoperability docs - semantic interoperability in federated ecosystems

A data space (dataspace) is a trusted ecosystem for sharing data across organizational boundaries while each participant keeps sovereignty over assets. Participants publish discoverable offerings, negotiate contracts, and exchange data under agreed rules instead of copying everything to a central warehouse.

The International Data Spaces Association (IDSA) defines reference architecture and certification for trustworthy data spaces. Gaia-X promotes a federated, open European cloud/data infrastructure with common trust, identity, and interoperability building blocks. Initiatives like Catena-X show sector-scale dataspace operation in practice.

Technically, many sovereign dataspaces use a connector pattern: each participant runs software that exposes a catalog, negotiates usage contracts, and transfers data only after policy checks pass. Eclipse Dataspace Components (EDC) implements this connector stack as open source. MAT-X local participant setup is based on EDC plus a semantic RDF layer.

Further reading

• Data space (Wikipedia) - concept overview
• EDC documentation - architecture and APIs
• Gaia-X technical documentation - trust framework and interoperability
• IDS Reference Architecture Model (RAM) - layers, roles, and building blocks

Concept

Each working ontology is stored as a public repository in the mds-ontologies organization. The canonical RDF file is ontology.ttl at the repo root. Fuseki holds the live graph; Git holds the versioned snapshot you commit and share. All kinds of ontology curation methods in MAT-X will use this.

GitHub personal access token (fine-grained)

MAT-X uses a fine-grained token (not a classic token). You must be a member of mds-ontologies before it appears in the token wizard. An org admin can invite you under the organization's People tab on GitHub.

Open github.com/settings/personal-access-tokens/new
(or: your avatar -> Settings -> Developer settings -> Personal access tokens -> Fine-grained tokens -> Generate new token).

1) Token name and expiration

Choose any name (e.g. Mat-X ontology curation) and an expiration you are comfortable with. You can rotate the token later in Profile.

2) Resource owner - this selects mds-ontologies

Under Resource owner, open the dropdown. You will see your personal GitHub username and, if you are a member, organizations such as mds-ontologies.

• Select mds-ontologies, not your personal username. The token is then scoped to that organization's repositories.
• If mds-ontologies is missing, you are not a member yet - ask an org admin to add you, then refresh and restart the wizard.

3) Repository access

Choose All repositories (essential as otherwise the options below do not work). MAT-X creates a new public repo per working ontology (e.g. mds-ontologies/cement-model), so the token must cover repositories that do not exist yet.

Only select repositories works only if you manually add every ontology repo to the token.

4) Repository permissions

Set these permissions under Repository permissions:

• Contents: Read and write - clone, pull, commit, and push ontology.ttl.
• Metadata: Read-only - usually required automatically.
• Administration: Read and write - allows MAT-X to create new public repositories in mds-ontologies.
• ** Issues**: ** Read and write** allows MAT-X to create issues in case you are unhappy with developments

You do not Pull requests, Actions, or other permissions for ontology curation.

5) Generate token and authorize SSO (if prompted)

Click Generate token and copy it immediately (GitHub shows it once). If your organization uses SAML SSO, go to Settings -> Personal access tokens -> Fine-grained tokens, find the new token, click Configure SSO, and authorize mds-ontologies.

Without SSO authorization, API calls return 403.

Save the token in MAT-X Profile

On the Profile page (/profile), add an API credential:

• Vendor: GitHub (or any label containing github)
• API URL: https://api.github.com
• API key: paste the fine-grained token

Keys are encrypted at rest with NEXTAUTH_SECRET. The server uses the first profile credential whose vendor or URL matches GitHub.

Quick checklist

Resource owner:     mds-ontologies  (not your username)
Repository access:  All repositories
Contents:           Read and write
Metadata:           Read-only
Administration:     Read and write
Issues: Read and write 
SSO:                Authorized for mds-ontologies (if your org uses SAML)

Register for the Mat-X dataspace

blaha

Welcome to your brand new NodeBB forum!

This is what a topic and post looks like. As an administrator, you can edit the post's title and content.
To customise your forum, go to the Administrator Control Panel. You can modify all aspects of your forum there, including installation of third-party plugins.

Additional Resources

• NodeBB Documentation
• Community Support Forum
• Project repository