- Data Formats
- Knora Ontologies
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.
Knora is tested with Ontotext GraphDB SE. Our goal is to support several triplestores, including open-source options. Integration with Apache Jena Fuseki has been partly implemented, but is not currently supported.
Knora 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.
There will be a standardisation process for shared ontologies (issue #523).
Knora’s consistency checking uses Knora-specific properties, which are called
knora-base:objectClassConstraint in the
knora-base ontology, and
knora-api:objectType in the
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, Knora considers it an error.
In contrast, the RDF Schema specification says that
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 statements:
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 checking.
Knora therefore uses its own properties, along with OWL cardinalities, which it interprets according to a “closed world” assumption. Knora performs its own consistency checks to enforce these restrictions. Knora 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.
No, because in Knora, a resource controls its properties. This basic assumption is what allows Knora 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
owl:TransitiveProperty, 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
Foo1. Now suppose that the owner of
Foo2 adds a link from
Foo3, 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
Foo2 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 Knora link must have. The
LinkValue is what stores metadata about the creator of the link, its creation date, its permissions, and so on (see LinkValue).
Finally, if an update to one resource could modify another resource, this would violate Knora’s model of transaction integrity, in which each transaction can modify only one resource (see Application-level Locking). Knora would then be unable to ensure that concurrent transactions do not interfere with each other.