Prez Manifest Model | Prez Manifest

A Prez Manifest is an RDF file that describes and links to a set of resources that can be loaded into an RDF database for Prez to provide access to.

This page defines the Prez Manifest specification and links to relevant tools.

The model
Manifest Resource Roles Vocabulary
Examples
Tools

Model

Overview

See Annex A: Diagram Breakdown below for a part-by-part explanation of this diagram.

Rules

An instance of the Manifest class, prez:Manifest, MUST have 1 or more Resource Descriptors, prof:ResourceDescriptor instances, indicated by the prof:hasResource predicate. The Manifest instance can be identified by an IRI or a Blank Node.
Each Resource Descriptor MUST have at least one prof:hasArtifact predicate indicating either an RDF literal resource (a string) containing the location of the artifact or a Blank Node containing the location of the artifacts indicated by the schema:contentLocation predicate and the main artifact IRI within that content location indicated by schema:mainEntity.
- See the Main Entity details below
Where content location is indicated, it MUST be a file path or path pattern relative to the manifest or a URL.
Each Resource Descriptor MUST also have exactly one prof:hasRole predicate indicating a Concept from the Manifest Resource Roles Vocabulary.
Each Resource Descriptor MAY have a schema:name and/or a schema:description predicate indicating literal resources naming and describing it.
A Resource, or an Artifact, MAY indicate that it (if an Artifact) or the Artifacts within it (if a Resource) conform to any number of defined Standards or Profiles of Standards, using the predicate dcterms:conformsTo.
- Validators can be indicated either by using "well known" validator IRIs or by directly indicating the validator RDF file
  - current "well known" are listed below and can be indicated using an IRI like this:
  - dcterms:conformsTo <WELL-KNONW-VALIDATOR-IRI> ;
  - other validators, such as my-local-validator.ttl or http://online-validator.com/val.ttl should be indicated using a literal, like this:
  - dcterms:conformsTo "path/from/manifest/root/to/my-local-validator.ttl" ;
- See the Known Validators list below
A Resource, or an Artifact, MAY indicate that it (if an Artifact) or the Artifacts within it (if a Resource) is of a specific class, using the predicate schema:additionalType
- See the Known Classes list below
A Resource, or an Artifact, MAY indicate that it should not be ignored by synchronisation tooling by setting a predicate prez:sync to false
- See the Indicating no action section below
An Artifact may have "versioning information" about it indicated by use of a number of known versioning predicates
- see the Artifact Versioning section below

Known Validators

The following validators can be referred to by IRI, as described above:

Validator	IRI	Scope
GeoSPARQL	`<http://www.opengis.net/def/geosparql/validator>`	Spatial Objects
IDN Catalogue Profile	`<https://data.idnau.org/pid/cp/validator>`	Catalogued resources containing Indigenous metadata
VocPub	`<https://linked.data.gov.au/def/vocpub>`	Vocabularies

Known Classes

Some classes of resource are commonly catalogued and, when they are, their class does not need to be indicated within a Manifest. These classes are:

dcat:Resource
dcat:Dataset
dcat:Catalog
owl:Ontology
schema:CreativeWork
schema:Dataset
schema:DataCatalog
skos:ConceptScheme

If an Artifact, or all the Artifacts within a Resource, are not one of these types, then they can be indicated as being so by use of schema:additionalType like this:

[]
    a prez:Manifest ;
    prof:hasResource
        # ...
        [
            prof:hasArtifact "resources/*.ttl" ;
            prof:hasRole mrr:ResourceData ;
            schema:additionalType <{A-CLASS-IRI}> ;
        ] ,
        # ...
.

This will allow the Manifest to communicate the class of the object software should be looking for within the resource.

If, for some reason, a resource is neither of one of the Known Classes nore it its class able to be indicated with schema:additionalType, the specific IRI of the resource can be indicated using schema:mainEntity. This may be needed in situations where an RDF file containing a resource also contains multiple other instance of the same class.

[]
    a prez:Manifest ;
    prof:hasResource
        # ...
        [
            prof:hasArtifact "resources/file1.ttl" ;
            prof:hasRole mrr:ResourceData ;
            schema:mainEntity <{RESOURCE-IRI}> ;
        ] ,
        # ...
.

Indicating no action

If a Manifest wishes to list a resource but indicate it not for automatic handling by manifest tooling - perhaps it's too large to synchronise with an RDF DB - then the predicate prez:sync with the value false should be set.

Here is an example of a Manifest indicating 4 spatial datasets, one of which is too large to sync:

[]
    a prez:Manifest ;
    prof:hasResource
        [
            prof:hasArtifact "resources/*.ttl" ;  # datset1.ttl, dataset2.ttl & dataset3.ttl
            prof:hasRole mrr:ResourceData ;
        ] ,
        [
            prof:hasArtifact "resources/large/dataset4.ttl" ;
            prof:hasRole mrr:ResourceData ;
            prez:sync false ;
        ] ;
.

Artifact versioning

An Artifact's version may be indicated by use of any or all of the following predicates:

owl:versionIRI
schema:version or owl:versionInfo
schema:dateModified or dcterms:modified

If this is done, then tools, such as prezmanifest that load and sync Manifest-described data, can obtain versioning information from a Manifest file, rather than by inspecting Artifacts' contents.

Validation

The validator - a file containing rules - for Manifests is given in Annex B: Manifest Validator below.

A manifest and all its content can also be validated using the prezmanifest tool's validate function which both validates a Manifest file using the validator below and also any content for which a conformance claim is given.

See the Tools section below for info on the prezmanifest tool.

Additionally, any stand-alon SHACL validator can also be used to validate a Manifest. Again, see the tools section below.

Examples

Valid

A simple, valid, Manifest.

--8<-- "docs/assets/manifest.ttl"

Invalid - no role

The second Resource Descriptor does not indicate a role as it is commented out.

--8<-- "docs/assets/manifest-invalid-01.ttl"

Invalid - bad location

The third resource specifies an invalid location, the non-existent web address of https://github.com/RDFLib/prez/blob/main/prez/reference_data/profiles/ogc_records_profile.ttlx which has had an extra 'x' added at the end.

--8<-- "docs/assets/manifest-invalid-03.ttl"

`mainEntity` use

A snippet of a Manifest - just one value for hasResource - showing use of mainEntity and contentLocation instead of just a literal file path.

    [
        prof:hasArtifact
            [
                schema:contentLocation "vocabs/image-test.ttl" ;
                schema:mainEntity <https://example.com/demo-vocabs/image-test> ;
            ] ,
            "vocabs/language-test.ttl" ;
        prof:hasRole mrr:ResourceData ;
        schema:description "skos:ConceptScheme objects in RDF (Turtle) files in the vocabs/ folder" ;
        schema:name "Resource Data"
    ] ,

conformance claim - single

A single artifact claiming conformance to the VocPub Profile of SKOS.

    prof:hasArtifact
        [
            schema:contentLocation "vocabs/image-test.ttl" ;
            schema:mainEntity <https://example.com/demo-vocabs/image-test> ;
            dcterms:conformsTo <https://linked.data.gov.au/def/vocpub> ;
        ] ,

conformance claim - all

A single Resource in a Manifest claiming conformance to the VocPub Profile of SKOS for all artifacts (there are 3 given).

    [
        prof:hasArtifact
            [
                schema:contentLocation "vocabs/image-test.ttl" ;
                schema:mainEntity <https://example.com/demo-vocabs/image-test> ;
            ] ,
            "vocabs/language-test.ttl" ;
            "vocabs/other-vocab.ttl" ;
        prof:hasRole mrr:ResourceData ;
        # ...
        dcterms:conformsTo <https://linked.data.gov.au/def/vocpub> ;
    ] ,

conformance claim - supplied validator

To indicate a validator stored in a local file, my-local-validator.ttl:

    [
        prof:hasArtifact
            [
                schema:contentLocation "vocabs/image-test.ttl" ;
                schema:mainEntity <https://example.com/demo-vocabs/image-test> ;
            ] ,
            "vocabs/language-test.ttl" ;
            "vocabs/other-vocab.ttl" ;
        prof:hasRole mrr:ResourceData ;
        # ...
        dcterms:conformsTo "path/to/my-local-validator.ttl" ;
    ] ,

additionalType

Where a

Tools

prezmanifest - GitHub, PyPI

The prezmanifest command line tool and Python package, available on GitHub and on PyPI, provides a number of functions to work with Prez Manifests. The functions provided are:

validate - validate a Manifest file and contents
label - check Manifest contents for unlabelled elements
document - create certain forms of documentation
load - load a Manifest's content into a file or DB
sync - synchronise a Manifest's contents with a DB

See the package's repository for installation and use details.

SHACL validation

The preferred way to perform validation of a Prez Manifest file is to use the prezmanifest tool's validate function, as listed above. Hoever, you can also perform validation of a manifest - the manifest file only, not the content it refers to, using any one of a number of SHACL validators.

See these notes for a listing of general-purpose SHACL validation tools: