\n

Overview

\n

Packages enable:

\n

\n
• Rapid dataspace setup with pre-configured domain vocabularies
\n
• Sharing and reusing common vocabulary definitions
\n
• Custom rendering for vocabulary-specific resources
\n
• Modular extension of dataspace functionality
\n

\n

\n

Package structure

\n

Each package consists of two files:

\n

\n

ns.ttl — Package ontology

\n

An RDF ontology file that imports the external vocabulary using owl:imports and attaches views to properties using ldh:view (forward relationships) or ldh:inverseView (inverse relationships). Views are typically ldh:View resources with SPARQL queries that render related data for property values.

\n

XSLT stylesheet — named by ac:stylesheet

\n

XSLT transformation file with templates that override default rendering using system modes like ac:*, ldh:* and xhtml:*. See the Stylesheets reference for details on XSLT customization.

\n

\n

Package files are organized in the LinkedDataHub-Apps repository, where the directory path is the package URI — a package under packages/a/b/ is published at https://packages.linkeddatahub.com/a/b/, so a path carries as many segments as the grouping needs:

\n

packages/\n├── editor/\n│   └── taxonomy/\n│       ├── ns.ttl     # Ontology with views\n│       └── skos.xsl   # XSLT stylesheet

\n

The ontology is always ns.ttl; the stylesheet filename is not a convention, it is whatever the package's ac:stylesheet names. The taxonomy editor is named for what it does and its stylesheet for the vocabulary it speaks.

\n

\n

Package metadata

\n

Package metadata is published as Linked Data that resolves from the package URI (e.g. https://packages.linkeddatahub.com/editor/taxonomy/#this).\n A package descriptor is an instance of the lds:Package class with these properties:

\n

\n

rdfs:label

\n

Human-readable package name

\n

dct:description

\n

Package description and purpose

\n

lds:ontology

\n

The package ontology URI (LDT vocabulary)

\n

ac:stylesheet

\n

The package stylesheet URI (AtomGraph Client vocabulary)

\n

\n

Example package metadata:

\n

@prefix lds: <https://w3id.org/atomgraph/linkeddatahub/dataspaces#> .\n@prefix ac:   <https://w3id.org/atomgraph/client#> .\n@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .\n@prefix dct:  <http://purl.org/dc/terms/> .\n\n<https://packages.linkeddatahub.com/editor/taxonomy/#this> a lds:Package ;\n    rdfs:label \"Taxonomy Editor\" ;\n    dct:description \"Taxonomy editing on SKOS, with custom templates\" ;\n    lds:ontology <https://raw.githubusercontent.com/AtomGraph/LinkedDataHub-Apps/master/packages/editor/taxonomy/ns.ttl#> ;\n    ac:stylesheet <https://raw.githubusercontent.com/AtomGraph/LinkedDataHub-Apps/master/packages/editor/taxonomy/skos.xsl> .

\n

\n

Package ontology

\n

The package ontology file contains two parts:

\n

Vocabulary import

\n

Imports the external vocabulary using owl:imports. See the Ontologies reference for ontology management details.

\n

<https://raw.githubusercontent.com/AtomGraph/LinkedDataHub-Apps/master/packages/editor/taxonomy/ns.ttl#> a owl:Ontology ;\n    owl:imports <http://www.w3.org/2004/02/skos/core> .

\n

Property views

\n

SPARQL-based views attached to properties from the imported vocabulary:

\n

skos:narrower ldh:view ns:NarrowerConcepts .\n\nns:NarrowerConcepts a ldh:View ;\n    dct:title \"Narrower concepts\" ;\n    spin:query ns:SelectNarrowerConcepts .\n\nns:SelectNarrowerConcepts a sp:Select ;\n    sp:text \"\"\"SELECT DISTINCT ?narrower\n    WHERE { GRAPH ?graph { $about skos:narrower ?narrower } }\n    ORDER BY ?narrower\"\"\" .

\n

Views are rendered when displaying resources that have the specified property. Use ldh:view for forward relationships (the resource carries the property) or ldh:inverseView for inverse relationships (other resources point at this resource through the property).

\n

\n

Package stylesheet

\n

XSLT templates in the platform's open modes, specialising the rendering of the package's own vocabulary:

\n

<!-- The hierarchy predicates render as the concept tree, not as statement rows -->\n<xsl:template match=\"skos:narrower | skos:broader | skos:related | skos:member\" mode=\"ac:PropertyEditor\"/>\n\n<!-- Fill the column beside the content body on a concept scheme's document -->\n<xsl:template match=\"rdf:RDF[...]\" mode=\"ldh:ContentColumn\">\n    <xsl:param name=\"mode\" as=\"xs:anyURI?\"/>\n    <!-- the concept tree -->\n</xsl:template>

\n

A package stylesheet is composed into the platform's import tree right after hooks.xsl, the module that declares the open modes and their generic fallbacks, and below everything else. Import precedence decides what a package can do: its rule for a node in an open mode outranks the fallback whatever the priorities, and it cannot contradict a sealed rule for the same node — a component mode, a typed rule, a global variable, named template or function — since that rule outranks the package. An open mode is a leaf: it renders or contributes for one node and carries no control flow. The open modes are:

\n

\n
• ldh:TreeNode — one tree node; replace the default renderer, or decorate it with xsl:next-match
\n
• ac:PropertyEditor — one resource's property list, or one statement row; replace or decorate, and an empty rule hides
\n
• ldh:ContentColumn — a slot beside the content body, empty unless a package fills it (the taxonomy editor's concept tree)
\n
• ldh:TreeChildrenLoad and ldh:RowHook — client only: the children fetch for one tree node, and deferred work for one rendered row
\n
• The value leaves — ac:FormControl, ac:PropertyListValue, ac:ValueAnnotations, ldh:TypeControl, ac:property-label, ac:object-label, ac:lang-tag, ac:ResultsTableHeaderCell, xhtml:Anchor and the unnamed mode's property row and value link. A rule for the package's own property or datatype replaces the generic one, or decorates it
\n

\n

The modes are documented in the Stylesheets reference. The package stylesheet reaches the browser as well: the platform composes each dataspace's client stylesheet with its package stylesheets and has the sef-compiler compile the result, so a package's rendering is the same on a direct page load and on client-side navigation.

\n

\n

Installing packages

\n

A dataspace imports a package with a single triple in its settings:

\n

<urn:linkeddatahub:apps/end-user> ldh:import <https://packages.linkeddatahub.com/editor/taxonomy/#this> .

\n

That declaration is the installation. Packages are installed into the end-user dataspace of a dataspace, and writing the triple requires write access to its settings document. See the step-by-step installation guide for the user interface and command line instructions.

\n

What the declaration does

\n

From the next request onwards, the server resolves the declaration:

\n

\n
1. Resolves the package description from the package URI. Bundled descriptions and cached graphs are read from the graph repository; other URIs are dereferenced over HTTP.
\n
2. Materializes the package ontology (lds:ontology) as a document under the admin dataspace's ontologies/ container, named after the package path — ontologies/editor-taxonomy/ for the taxonomy editor. The ontology is copied verbatim and the document names it as its foaf:primaryTopic; the copy is taken once, and the document is skipped on later requests.
\n
3. Adds the package ontology to the dataspace's ontology imports closure — it is declared as an owl:imports of the namespace ontology and resolves to the materialized document. The package's classes, constructors, constraints and views become available on the ns endpoint and in the UI, and are edited in that document like the namespace ontology's own.
\n
4. Copies the package stylesheet (ac:stylesheet) once under the platform's package root and serves it from the dataspace's own origin under /static/com/linkeddatahub/packages/, so what the instance compiles cannot change under it.
\n
5. Composes that copy into the dataspace stylesheet with an xsl:import right after hooks.xsl, so package templates outrank the open modes' fallbacks and nothing else; the client-side stylesheet is composed the same way and compiled by the sef-compiler.
\n

\n \n

Packages are applied in the order of their URIs. A package that declares only an ontology, or only a stylesheet, contributes only that, and one whose description cannot be resolved is skipped. If the composed stylesheet fails to compile — an unreachable package stylesheet URL, for instance — the dataspace falls back to its own stylesheet.

\n

On the Northwind Traders dataspace the taxonomy editor package pays off immediately: the product categories that the\n UNESCO mapping import doubled as skos:Concepts pick up the package's concept rendering and views,\n and their mapping relations link into the UNESCO Thesaurus dataspace.

\n \n

\n

Uninstalling packages

\n

Removing the ldh:import triple uninstalls the package: from the next request onwards its ontology is out of the imports closure and its stylesheet is no longer composed in.

\n

DELETE\n{\n    <urn:linkeddatahub:apps/end-user> ldh:import <https://packages.linkeddatahub.com/editor/taxonomy/#this> .\n}\nWHERE {}

\n \n

\n

Architecture

\n

Runtime composition

\n

Packages are composed at request time out of the declaration, not integrated into the dataspace ahead of it:

\n

\n
• The dataspace settings hold one ldh:import triple per package and nothing else
\n
• The ontology closure and the stylesheet imports are assembled from the resolved package descriptions
\n
• Installing and uninstalling take effect on the next request — no restart, and nothing is written into the webapp: the ontology copy is a document in the admin store and the stylesheet copy lives under the package root outside the war
\n

\n \n

\n

Creating custom packages

\n

Developers can create custom packages for their own domain vocabularies. The process has four steps.

\n

Write package ontology

\n

Create ns.ttl with vocabulary import and views:

\n

<https://raw.githubusercontent.com/you/repo/master/packages/schema.org/ns.ttl#> a owl:Ontology ;\n    owl:imports <https://schema.org/> .\n\n# Attach view to a property\nschema:knows ldh:view :PersonKnows .\n\n:PersonKnows a ldh:View ;\n    dct:title \"Knows\" ;\n    spin:query :SelectPersonKnows .\n\n:SelectPersonKnows a sp:Select ;\n    sp:text \"\"\"\n    SELECT DISTINCT ?person\n    WHERE { GRAPH ?graph { $about schema:knows ?person } }\n    ORDER BY ?person\n    \"\"\" .

\n

Write XSLT stylesheet

\n

Create the stylesheet — name the file for the vocabulary it covers — with XSLT templates using system modes like ac:*, ldh:* and xhtml:*. See the Stylesheets reference for template customization patterns.

\n

<xsl:template match=\"schema:knows\" mode=\"ac:PropertyEditor\"/>

\n

Publish package metadata

\n

Publish package metadata as Linked Data at your package URI:

\n

<https://packages.linkeddatahub.com/schema.org/#this> a lds:Package ;\n    rdfs:label \"Schema.org Package\" ;\n    dct:description \"Schema.org vocabulary support\" ;\n    lds:ontology <https://raw.githubusercontent.com/you/repo/master/packages/schema.org/ns.ttl#> ;\n    ac:stylesheet <https://raw.githubusercontent.com/you/repo/master/packages/schema.org/schema.xsl> .

\n

Ensure the metadata contains lds:ontology and ac:stylesheet properties pointing to the package resources.

\n

Test installation

\n

Declare the ldh:import triple in a test dataspace's settings document — see Management for the command.

\n

\n

Available packages

\n

Published packages resolve from packages.linkeddatahub.com; their sources live in the\n LinkedDataHub-Apps repository, where each package directory\n contains the package ontology (ns.ttl) and the stylesheet its ac:stylesheet names.

\n

\n

Taxonomy Editor

\n

Taxonomy editing on SKOS: a concept tree beside the content, hierarchy views in both assertion directions, and constructors and constraints for concepts, schemes and collections. Package URI: https://packages.linkeddatahub.com/editor/taxonomy/#this

\n

\n

\n

Management

\n

The packages group reads the registry and writes the ldh:import triple:

\n

ldh packages list\nldh packages add --package https://packages.linkeddatahub.com/editor/taxonomy/#this\nldh packages remove --package https://packages.linkeddatahub.com/editor/taxonomy/#this

\n

packages list prints one tab-separated line per package — state, URI, title — so the listing greps and cuts. The registry\n defaults to https://packages.linkeddatahub.com/ and --registry overrides it; it is read through the\n dataspace's Linked Data proxy rather than fetched directly, so list needs --base as much as the other two do.

\n

All three go through PATCH on the settings document, which is the live path: the change takes effect on the\n next request with no restart, but lives in the running dataspace's context dataset. Declaring the same ldh:import triple\n in config/dataspaces.trig is the permanent one, applied on restart. packages remove is idempotent.

\n