\n

User-defined classes

\n

User-defined classes live in the dataspace's namespace ontology, which is managed in the admin dataspace. A class becomes creatable in the UI once it has a constructor: it then appears in the Create dropdown alongside the built-in classes, and its instances are created and edited using the same forms. See Change the model for a walkthrough of defining classes, constructors and constraints.

\n

\n

Built-in classes

\n

LinkedDataHub's built-in classes have pre-defined constructors, constraints and often a customized UI rendering (implemented by overriding generic XSLT templates with type-specific templates) as well, for example a query editor or a chart.

\n

The table lists the built-in classes creatable from the Create dropdown; the two content block classes, ldh:XHTML and ldh:Object, are documented on the Content blocks page.

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Built-in classes by type

Type	Class	Description
ASK	sp:Ask	SPARQL ASK query
Dataspace	lds:Dataspace	Remote LinkedDataHub dataspace
CONSTRUCT	sp:Construct	SPARQL CONSTRUCT query
CSV import	ldh:CSVImport	Asynchronous CSV data import
DESCRIBE	sp:Describe	SPARQL DESCRIBE query
File	nfo:FileDataObject	An uploaded file, stored content-addressed under uploads/
Graph chart	ldh:GraphChart	Chart based on CONSTRUCT/DESCRIBE query results
RDF import	ldh:RDFImport	Asynchronous RDF data import
Result set chart	ldh:ResultSetChart	Chart based on SELECT query results
Select	sp:Select	SPARQL SELECT query
Service	sd:Service	SPARQL service (identified by its endpoint URL)
View	ldh:View	View based on SELECT query results

\n

Resources that have customized UIs (such as queries, views, charts) are documented in more detail below.

\n

\n

RDF vocabulary

\n

A chart references its query with spin:query and describes its rendering with the following properties:

\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Vocabulary properties and what they apply to

Property	Applies to	Description
ldh:chartType	both	One of ac:Table, ac:LineChart, ac:BarChart, ac:ScatterChart, ac:Timeline
ldh:categoryVarName	ldh:ResultSetChart	Name of the SELECT variable that provides the category values
ldh:seriesVarName	ldh:ResultSetChart	Name(s) of the SELECT variable(s) that provide the series values
ldh:categoryProperty	ldh:GraphChart	URI of the property that provides the category values
ldh:seriesProperty	ldh:GraphChart	URI(s) of the property(ies) that provide the series values

\n

<#category-revenue-query> a sp:Select ;\n    dct:title \"Category revenue\" ;\n    sp:text '''PREFIX schema: <https://schema.org/>\n\nSELECT ?categoryName (SUM(?sale) AS ?revenue)\nWHERE {\n    GRAPH ?orderGraph {\n        ?order schema:orderedItem ?orderItem .\n        ?orderItem schema:orderedItem ?product ;\n                   schema:price ?sale .\n    }\n    GRAPH ?productGraph {\n        ?product schema:category ?category .\n    }\n    GRAPH ?categoryGraph {\n        ?category schema:name ?categoryName .\n    }\n}\nGROUP BY ?category ?categoryName\nORDER BY DESC(?revenue)''' .\n\n<#category-revenue> a ldh:ResultSetChart ;\n    dct:title \"Revenue by category\" ;\n    spin:query <#category-revenue-query> ;\n    ldh:chartType <https://w3id.org/atomgraph/client#BarChart> ;\n    ldh:categoryVarName \"categoryName\" ;\n    ldh:seriesVarName \"revenue\" .\n\n<#category-revenue-block> a ldh:Object ;\n    dct:title \"Revenue by category\" ;\n    rdf:value <#category-revenue> .

<#select-categories-view> a ldh:View ;\n    spin:query <#select-categories-query> ;\n    ac:mode <https://w3id.org/atomgraph/client#GridMode> .

\n

Projecting variables

\n

Because the SELECT is rewritten into a DESCRIBE over its projected variables, a view can only render terms that the triplestore is able to describe:

\n

\n
• Project resources (IRIs) that exist in the dataset — their labels, images and links are resolved from each resource's own description. Projecting literals (a ?label, a ?date, or any computed value) describes nothing, so the view renders empty.
\n
• Project IRIs that are stored locally. An IRI that only occurs as an object but is not itself described in the dataset — for example an external image URL — contributes no triples.
\n
• Project a single entity type. Projecting several resource variables of different types blends their descriptions into one result set, which rarely renders coherently; select the one type you want to list and reach the related resources through their properties instead.
\n

\n

The query that drives the categories grid above projects the category resource, so the view renders the category documents:

\n

SELECT DISTINCT ?category\nWHERE {\n    GRAPH ?doc {\n        ?category\n            a schema:ProductGroup ;\n            schema:name ?categoryName\n    }\n}

\n

This query looks equivalent, but it projects the name literal instead of the category resource — so it describes nothing and renders an empty view:

\n

SELECT DISTINCT ?categoryName\nWHERE {\n    GRAPH ?doc {\n        ?category\n            a schema:ProductGroup ;\n            schema:name ?categoryName\n    }\n}

\n

\n

Layout modes

\n

View results are rendered in the view's own set of layout modes — properties, list, grid, table, map, chart, and graph — a larger set than the document layout modes.

\n

\n

Inline creation

\n

A view attached to a property in the dataspace's ontology renders a Create button in its header, so a view can double as an entry point for the data it lists. The class to construct is inferred from the attaching property: its rdfs:range for a forward ldh:view, its rdfs:domain for an inverse ldh:inverseView. A property whose range is not a named class — an owl:unionOf list, say — gets no button, because there is nothing to construct.

\n

Where the new instance is stored is not declared anywhere. LinkedDataHub works it out from the view's own results: a second query, derived from the view's SELECT pattern with LIMIT, OFFSET and ORDER BY removed, asks which containers hold the documents that describe the existing solutions. A view is a projection and its rows are its solutions, so creating a row means making a new solution appear in that projection — and the existing solutions already say where their descriptions live.

\n

\n
• Exactly one container — the button renders and targets it.
\n
• No container, because the result set is empty — no button. There is nothing to generalise from, so the first instance of a kind is created through its container the usual way.
\n
• More than one container, because the results span several — no button. Nothing in the data says where a new row belongs, and deciding by majority would be placement nobody stated.
\n

\n

The question is put to the whole result set rather than to the page on screen, so the destination cannot depend on which page the reader happens to be looking at. The determined container is then checked for acl:Write access, which is why the button appears a moment after the rest of the view header; a forward view also writes the linking triple into the current document, so it needs write access there as well.

\n

A view with ldh:showWhenEmpty set to false is hidden while its query returns no results — the\n demo's property-attached views\n use it so \"Orders from this customer\" only appears on customers that have orders.

\n

<#select-products-view> a ldh:View ;\n    spin:query <#select-products-query> ;\n    ac:mode <https://w3id.org/atomgraph/client#TableMode> ;\n    ldh:showWhenEmpty false .

\n

\n

Faceted search

\n

Views provide faceted search in the toolbar at the top of the view, filtering the result set. The toolbar renders one dropdown pill per facetable property; opening a pill loads that property's values together with their result counts, and checking a value filters the results. Applying or removing a filter restarts paging from the first page.

\n

By default the facets are generic and inferred from the triple patterns of the SPARQL SELECT query used by the view. They can be customized using XSLT.

\n

\n

Parallax navigation

\n \n

Parallax is an unusual navigation approach that suits graph data particularly well. It allows jumping from a result set to a related result set by following an RDF property. The available pivots render as a row of chips directly under the view toolbar, one chip per property linking the result set to the rest of the graph; the row stays hidden while there are no pivots. Parallax navigates in both directions: a chip with a forward arrow follows a property of the results onto its objects, a chip with a backward arrow follows a property pointing at the results onto its subjects. The pivots are discovered by querying the whole result set, so they cover results beyond the current page.

\n

Clicking a chip pivots the view onto the related result set and restarts paging from the first page. The applied steps appear in the toolbar next to the facets as removable chips reading via (forward) or linked by (backward); removing one rewinds the view to that step. Parallax works in\n combination with faceted search which can be used to filter the initial result set.

\n

For example, facets can be used to filter a set of products that belong to a certain category, and then parallax can be used to jump to a set of companies that provide those products, and then further on to\n a set of representatives of those companies.

\n