Skip to content

Triple annotation

An annotation field writes its value as an RDF 1.2 statement about the last triple of a path. Mark a text-based field of the bundle as an annotation field, then choose it on the path.

Mark the field

On the bundle, open Manage fields and create or edit one of these fields:

  • Text (plain), Text (plain, long)
  • Text (formatted), Text (formatted, long)
  • Number (integer, decimal, float)
  • List (text, integer, float)

Text (formatted, long, with summary) is not offered, because the summary has no place in the triple.

Under Triple annotation, check Annotation field and choose two steps, as for a path:

  • Class of the statement: the class of the reifier. The list offers the classes of the store that holds the bundle's pathbuilder.
  • Datatype property: the property that carries the value. The list offers the datatype properties the reasoner allows for that class. Without JavaScript, Show datatype properties fills the list for the chosen class.

The field keeps its own widget, formatter and settings. A list field stores its key and shows its label, also in the tooltip on the annotated value. A module can supply the list with allowed_values_function; the labels then follow the interface language.

The settings belong to the field storage, so a field shared by several bundles has one class and one property. A field that a pathbuilder maps to a path cannot be an annotation field, and the pathbuilder does not offer an annotation field as the field of a path.

Choose it on the path

Open the path that ends in the triple you want to annotate. Under Triple annotation, the list contains only the annotation fields of the bundle of the path's group: a value is written about the triples of the entity it belongs to. A field listed before that is not on that bundle is shown as such and has to be unchecked. When the list is empty, bundle links to that bundle's field settings.

  • A group has no such list.
  • The path needs a datatype property.
  • One value is written on every value of that path in the same entity, so the annotated field should have a single value.
  • The store must accept RDF 1.2 triple terms. Otherwise the path form refuses the selection and saving an annotation writes nothing.

WissKI writes the explicit reifier, which can also be deleted:

<reifier> <http://www.w3.org/1999/02/22-rdf-syntax-ns#reifies> <<( ?subject ?predicate ?object )>> ;
  a <class-of-the-statement> ;
  <datatype-property> ?value .

The reifier is a named IRI in the adapter's data graph, minted like the IRI of a new individual. A triple has one reifier per class: annotation fields with the same class add their values to it, a field with another class gets its own. A reifier is deleted with its last value. Reifiers of other classes on the same triple are left alone.

?value is a literal with the entity's language tag, like the values of the path fields. An untagged value belongs to every language: it is read in the current language and removed when that value is deleted or changed.

The annotated value shows a * whose tooltip names the annotation field, for example Reading: Approximate. The same words are repeated for screen readers. The annotation field itself is shown by its own formatter.

The triples tab of a URI lists the same annotation when that URI is the subject, predicate or object of the annotated triple, in a table Annotations. An intermediate concept therefore shows the annotation on that concept's triples page. Each row is a triple of the reifier, its class (rdf:type) included. The subject column shows the annotated triple, shortened; clicking it opens the reifier, subject, predicate and object as links to their triples pages. The reifier's own triples page lists its rdf:reifies triple among the outgoing triples, with the annotated triple shown the same way. A URI with no annotation keeps the incoming and outgoing tables only.

Deleting or replacing the annotated value removes the annotation, including when the triple's subject is an intermediate concept. Deleting the entity removes the reifiers of all its triples. Replacing the value writes the annotation onto the new triple.

An entity-query or view filter on the annotation value is not part of this. A path with no annotation field keeps the previous read, write and delete. A path stored before this option existed is treated as one of those paths.