FAQ

Frequently Asked Questions #

Please also note the current limitations.

How are HTML tags in string values processed? #

SemSpect supports a predefined set of HTML tags in string values that are permitted for rendering within the user interface. These tags include a, b, i, em, and br. Any HTML tags not listed in this set will be automatically excluded from the rendered output.

How can I report bugs, request features, or provide general feedback? #

To report bugs, request features, or to provide general feedback, please open a new issue in our dedicated SemSpect Community GitHub repository.

I can’t find a property used in the data in the exploration menu #

We use a heuristic for the selection of a single property in case multiple equivalent properties or mutually inverse properties exist. More precisely, when properties are equivalent to each other, only one of them is displayed in the exploration menu, namely the one with the smallest IRI according to their lexicographical ordering. The same applies to mutually inverse properties. Note that this might change in the future and is planned to be configurable.

What resources are found in [No class]? #

[No class] includes all IRIs that are used like an individual resource, but for which no class type information can be derived according to the implemented inference fragment other than rdfs:Resource, owl:NamedIndividual, or owl:Thing.

SemSpect seems to freeze during index generation #

If SemSpect freezes (no CPU load) when computing the indices and does not issue an error message or warning, it may have run out of memory. Please abort and try again using:

  • the two-pass generation approach ad described in the index generation configuration, which requires more time but consumes less main memory by generating the compressed dictionary and index one after the other,

  • a larger JVM heap space, which can be specified by -Xmx either as option to JDK_JAVA_OPTIONS or to SEMSPECT_JDK_OPTIONS in case this setting should only apply to SemSpect. All variants work for both provided command line scripts (semspect.* and semspect-spring.*). For example in case of Linux/OSX with export SEMSPECT_JDK_OPTIONS=-Xmx32g.

What happens if entities have the same RDFS label? #

SemSpect selects one RDFS label per entity that is displayed in the UI, namely the lexicographically smallest string. If there exists another entity of the same type (i.e., a class, object property, or data property) with the same chosen RDFS label, SemSpect will display the IRI instead.

Why does the UI show the IRI of an entity although an RDFS label is present? #

It is possible that there exists another entity of the same type (class, object property, data property) that has the same RDFS label assigned. In that case, SemSpect displays the IRI of the respective resources such that they remain distinguishable.

Generated SPARQL Queries in Exploration #

Why do my queries return incomplete or empty results? #

This usually happens when the entailment regime of SemSpect does not match that of the triple store. For example, if the store does not perform subclass or equivalence entailment, queries may miss expected results. In this case, the solution is to enable rewriting (enableSubClassOfSPARQLRewriting) so that query semantics are aligned with your store. More generally, you should ensure that the entailment regime of SemSpect matches the regime of the triple store. Use the available options (disableDomainRangeEntailment, disableSubClassOfEntailment, disableSubPropertyOfEntailment, disableSymmetricPropertyAndInverseOfEntailment) to disable entailments in SemSpect.

Why is the top class sometimes problematic? #

SemSpect uses rdfs:Resource as the top class. Some triple stores instead use owl:Thing as the universal superclass. If your store uses owl:Thing, queries involving the top class may not return expected results. In this case, you may try replacing all instances of rdfs:Resource in the query with owl:Thing.

Why is there no option for property entailment rewriting? #

Property entailments such as rdfs:subPropertyOf, rdfs:domain, rdfs:range, and owl:inverseOf are currently not rewritten. Expanding these would cause queries to grow excessively in size and complexity, making them difficult to manage. Users should rely on the native entailment of the triple store, which means queries will work correctly without rewriting as long as the store supports these entailments. To keep results consistent, configure the entailment regime of SemSpect to match the one of the triple store (using the disable options mentioned above).

What happens with “any property” connections? #

Connections without a specified property are expanded to a SPARQL variable. In practice, the results correctly reflect “any property”. The query binds owl:topObjectProperty as a constant to a variable, which is why the table shows it explicitly.