Frequently Asked Questions
What file formats does Knora store?
Does Knora store XML files?
XML files do not lend themselves to searching and linking. Knora's RDF storage is better suited to its goal of facilitating data reuse.
If your XML files represent text with markup (e.g. TEI/XML), the recommended approach is to allow Knora to store it as Standoff/RDF. This will allow both text and markup to be searched using Gravsearch. Knora can also regenerate, at any time, an XML document that is equivalent to the original one.
If you have XML that simply represents structured data (rather than text documents), we recommend converting it to Knora resources, which are stored as RDF.
Which triplestores can be used with DSP-API?
DSP-API is tested with Apache Jena Fuseki.
Can a project use classes or properties defined in another project's ontology?
DSP-API does not allow this to be done with project-specific ontologies. Each project must be free to change its own ontologies, but this is not possible if they have been used in ontologies or data created by other projects.
However, an ontology can be defined as shared, meaning that it can be used by multiple projects, and that its creators promise not to change it in ways that could affect other ontologies or data that are based on it. See Shared Ontologies for details.
Why doesn't DSP-API use
rdfs:range for consistency checking?
DSP-API's consistency checking uses specific properties, which are called
knora-base ontology, and
knora-api ontologies. These properties express restrictions on the
possible subjects and objects of a property. If a property's subject or object
does not conform to the specified restrictions, DSP-API considers it an error.
the RDF Schema specification says
rdfs:range can be used to "infer additional information"
about the subjects and objects of properties, rather than to enforce restrictions.
This is, in fact, what RDFS reasoners do in practice. For example, consider these
example:hasAuthor rdfs:range example:Person .
data:book1 example:hasAuthor data:oxygen .
To an RDFS reasoner, the first statement means: if something is used as
the object of
example:hasAuthor, we can infer that it's an
The second statement is a mistake; oxygen is not a person. But
an RDFS reasoner would infer that
data:oxygen is actually an
example:Person, since it is used as the object of
example:hasAuthor. Queries looking for persons would then get
data:oxygen in their results, which would be incorrect.
rdfs:range are not suitable for consistency
DSP-API therefore uses its own properties, along with OWL cardinalities, which it interprets according to a "closed world" assumption. DSP-API performs its own consistency checks to enforce these restrictions. DSP-API repositories can also take advantage of triplestore-specific consistency checking mechanisms.
The constraint language SHACL may someday provide a standard, triplestore-independent way to implement consistency checks, if the obstacles to its adoption can be overcome (see Diverging views of SHACL). For further discussion of these issues, see SHACL and OWL Compared.
Can a user-created property be an
No, because in DSP-API, a resource controls its properties. This basic assumption is what allows DSP-API to enforce permissions and transaction integrity. The concept of a transitive property would break this assumption.
Consider a link property
hasLinkToFoo that is defined as an
and is used to link resource
Foo1 to resource
Foo2 are owned by different users, and that
the owner of
Foo2 does not have permission to change
Now suppose that the owner of
Foo2 adds a link from
using the transitive property:
Since the property is transitive, a link from
Foo3 is now
inferred. But this should not be allowed, because the owner of
does not have permission to add a link to
Moreover, even if the owner of
Foo2 did have that permission, the inferred
link would not have a
knora-base:LinkValue (a reification), which every
link must have. The
LinkValue is what stores metadata about the creator
of the link, its creation date, its permissions, and so on
Finally, if an update to a resource could modify another resource, this would violate DSP-API's model of transaction integrity, in which each transaction can modify only one resource (see Application-level Locking). DSP-API would then be unable to ensure that concurrent transactions do not interfere with each other.
Why should I use
0.0.0.0 instead of
localhost when running the DSP stack locally?
When running locally with the default configuration, if you want authorization cookies
to be shared between
sipi, then both
sipi must be accessed
0.0.0.0, or otherwise, the cookie will not be sent to
If no authorization cookie sharing is necessary, then both