Model

Ontologies

Ontologies are sets of domain concepts. The domain can span both documents (information resources) and abstract/physical things (non-information resources).

Ontologies can import other ontologies, both user-defined and system ones provided by LinkedDataHub. The imports are retrieved during application initialization, and the ontology becomes a transitive union, i.e. is merged with its imports and imports of the imports etc.

Main ontology properties:

Imports
Ontology to be imported
Version
Unique version of this ontology

All concepts managed in the model and explained below (classes, constructors etc.) belong to exactly one ontology. The membership is specified using the rdfs:isDefinedBy property.

System ontologies

AtomGraph Platform (APL) is the default domain ontology used by LinkedDataHub.

Domain ontologies
Ontology Title Prefix Imports
https://w3id.org/atomgraph/linkeddatahub/domain# AtomGraph Platform apl: dh:
https://www.w3.org/ns/ldt/document-hierarchy/domain# Document hierarchy dh:
https://www.w3.org/ns/ldt/core/domain# Core c:

Classes

Classes are simply RDFS classes. Usually the application dataset contains class instances.

Main class properties such as constructor and constraint are explained in the sub-sections below. Additional properties are:

Constructor
Query that constructs new class instance
Constraints
Command or command template that validates class instance
Path template
Template of the URI that will be generated for a new instance of this class by means of skolemization. It reuses the JAX-RS URI template syntax but extends it in several ways.
If the template starts with a leading /, it is treated as absolute path (relative to the base URI), otherwise as path segment (relative to the request absolute path, e.g. to the URI of the container under which the instance resource is stored).
Template variables are set automatically from resource property values. A simple path syntax to navigate between connected resources and their properties: resources are separated by . and only the local names of properties are used.
For example, consider that you are creating an instance of :Person class under https://linkeddatahub.com/people/, and you want the instance URI to be generated from its foaf:familyName value (lets suppose it is "Berners-Lee"). In that case you should define a path segment template {familyName}/, and the instance URI will be skolemized as https://linkeddatahub.com/people/Berners-Lee/.
If, on the other hand, you want the instance to use the title of the document it is topic of, then you should define the segment template as {isPrimaryTopicOf.title}.
Fragment template
Similarly to the segment template, this template defines the fragment part of URI for new instances of this class. It is useful for distinguishing information resources (documents) from non-information resources which have hash URIs.
Continuing the example from above, fragment template this defined on the :Person class would generate https://linkeddatahub.com/people/Berners-Lee/#this as instance URI.

Constructors

Constructors are SPARQL CONSTRUCT queries that serve as templates for class instances. They specify the properties (both mandatory and optional) that the instance is supposed to have, as well as expected datatypes of their values. Constructors are used in create/edit modes. A class can have multiple constructors.

For example, one of the constructors of the nsdd:Container and nsdd:Item classes:

PREFIX rdf:     <http://www.w3.org/1999/02/22-rdf-syntax-ns#>
PREFIX xsd:     <http://www.w3.org/2001/XMLSchema#>
PREFIX sioc:    <http://rdfs.org/sioc/ns#>
PREFIX dct:     <http://purl.org/dc/terms/>

CONSTRUCT {
  ?this sioc:content "<div xmlns=\"http://www.w3.org/1999/xhtml\"></div>"^^rdf:XMLLiteral .
}
WHERE {}

An instance of these classes by default have a content property with XML literal.

LinkedDataHub reuses SPIN constructors for the implementation, but adds a special syntax convention using blank nodes to indicate the expected resource type ([ a ex:Person ]) or literal datatype ([ a xsd:string ]).

Note that classes inherit constructors from superclasses in runtime. Subclasses do not have to redefine constructor properties already found in superclass constructors, only additional properties.

Constraints

Constraints are SPARQL queries or command templates that validate submitted RDF data during document creation and editing. Constraints are enforced for instances of sitemap classes on which they are defined and are used to check class instances for violations (missing mandatory properties, malformed values etc.). For example, an instance of nsdd:Item without dct:title will fail validation because titles are mandatory for LinkedDataHub documents.

LinkedDataHub reuses SPIN constraints. Classes inherit constraints from superclasses.

Restrictions

Model ontologies can use OWL property restrictions to define relationships between model classes and between classes and containers. LinkedDataHub's XSLT stylesheets use them when rendering the user interface. The skolemizer also uses them when skolemizing blank nodes in the request body.

ObjectAllValuesFrom restrictions define which thing and document instances should be constructed and edited together (using the property which is the value of restriction's OnProperty to link them with each other). foaf:primaryTopic/foaf:isPrimaryTopicOf can be used to pair documents with abstract/physical things.

ObjectHasValue restrictions define which document instances should be stored in which container (using sioc:has_container property).

Properties

LinkedDataHub allows definition of new properties.