The cognitive dissonance caused by the class hierarchy in the ontology and the concept hierarchy in the vocabulary

[ghost]

The FIBO ontology contains entities structured using the rdfs:subClassOf predicate. This is a transitive predicate. The FIBO vocabulary contains concepts structured using the skos:broader predicate which is an intransitive predicate. The FIBO vocabulary is generated from the ontology. The mapping is reflected in the use of the rdfs:isDefinedBy predicate mapping concepts to entities. Due to the difference in transitivity, this is a lossy mapping. This creates a problem for the user who seeks to use the FIBO vocabulary in conjunction with their own domain-specific vocabulary. Reference data vendors would be an example of such users. As it stands, the generated FIBO vocabulary implicitly makes skos:broader a transitive predicate depriving the vocabulary user of an intransitive extension point thereby forcing them to make an ontological commitment to the entirety of the FIBO ontology.

This could be fixed by generating the vocabulary with skos:broaderTransitive in addition to skos:broader which would leave the design decision on coupling to the end user.

[dallemang]

I want to understand the issue here. RDFS doesn't have a non-transitive version of subClassOf; this is a gap in coverage of RDFS, which we can't fix in FIBO. By convention, when someone in RDFS says A subClassOf B, they mean that this is a 'primitive' use of subClassOf (that is, not the transitive one). Sadly, they just can't say this formally in RDFS; it lacks the vocabulary. I say "by convention" meaning that, typically, if someone were to say A subClassOf B and also B subClassOf C, they wouldn't also say A subClassOf C, even though it is (provably) true; in fact, it is exactly because it is provable that they don't say it; it literally "goes without saying". In FIBO, we have codified this principle as a modeling practice; if we can infer something from what we have already said, we don't say it again (this is a variant of DRY programming https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).

SKOS gives us a bit of extra expressivity (which is one of the things I love about SKOS; it uses OWL quite effectively to describe how its properties are related to one another); it lets us be explicit about whether we mean the non-transitive use of broader or the transitive one. This allows someone who is, say, browsing a model, to use skos:broader, and someone who is, say, searching it to use skos:broaderTransitive; the model gives them the property they need.

I am confused by your comment "FIBO vocabulary implicitly makes skos:broader a transitive predicate". It seems to me that the current transformation exactly and precisely does not do that. The current transformation turns explicit(not inferred) subClassOf relations into skos:broader. So in the example above,

A subClassOf B . B subClassOf C .

FIBO-V will contain

A skos:broader B . B skos:broader C.

If skos:broader were transitive, then you would expect to see

• A skos:broader C

This is what would happen, if the transformation were to run RDFS logic on FIBO before doing the transformation, effectively pushing the transitivity of rdfs:subClassOf into skos:broader. The transformation explicitly does not do that, since skos:broader isn't transitive.

The "fix" you suggest, in the example above, would suggest adding

A skos:broader B . B skos:broader C. A skos:broaderTransitive B . B skos:broaderTransitive C .

This would violate DRY; since

skos:broader rdfs:subPropertyOf skos:broaderTransitive .

the last two triples are already entailed by the model; the DRY policy says that we shouldn't explicitly express things that are already entailed by what we have expressed. This policy applies here as well.

I understand your desire to leave the decision decision on whether to use a transitive property or not the end user; this is exactly the motivation for the SKOS model to use the non-transitive/transitive design pattern, and the end user (indeed, any end user of any SKOS model) already has this power. In the inferred model, using just simple RDFS inferencing (no fancy OWL inferencing needed), there is already a not-transitive tree (A broader B . B broader C), as well as the elaborate transitive tree (A broaderTransitive B. B broaderTransitive C. A broderTransitive C .); users who need transitivity (e.g., search applications) use broaderTransitive; users who don't (e.g., browsing applications) use broader. This has nothing to do with FIBO; you can already do this with any SKOS model, any time.

[rivettp]

@dallemang would it not be a more faithful preservation of FIBO semantics to not use skos:borader at all but generate ONLY:
A skos:broaderTransitive B . B skos:broaderTransitive C .
since it's FIBO that is the master.
This would make the SKOS less flexible but surely the point is to reflect, as far as possible, the FIBO semantics. And it would not, I believe, be lossy in this aspect as @kptyson complains. Or redundant as per your concern.
Kevin, I'd be interested to discuss privately your (very genuine) concern about reference data vendors and pulling in too much of FIBO. Though I personally don't see SKOS being a solution in that space, I'm always willing to be converted.

[VladimirAlexiev]

Having the direct/step/non-transitive property is useful in many situations, eg to display a tree of classes/concepts.
From what @kptyson posted, it seems to me he'd also be unhappy if you obliterate the distinction between skos:broader and skos:broaderTransitive in FIBOV.

So rather than take away from FIBOV, consider adding to FIBO. You can do that with sesame:directSubClassOf (where sesame: <http://www.openrdf.org/schema/sesame#>).

[dallemang]

@VladimirAlexiev is correct; while @rivettp is correct that it would be more faithful to FIBO to use broaderTransitive, we would lose the ability to talk about the direct step and the transitive step both in the same model. SKOS has the ability to express explicitly what FIBO can only express by convention. The better solution would be to fix FIBO.

I have never heard of sesame:directSubClassOf before, and sadly, that resource isn't available via follow-your-nose. Can you point me to some documentation about it, @VladimirAlexiev? I'm a bit concerned about using it, when I can't review it by follow-your-nose.

[rivettp]

No @VladimirAlexiev sesame:directSubClassOf is not something you'd add to FIBO ontologies, but it's a psesudo-predicate you'd use in SPARQL when querying FIBO https://stackoverflow.com/questions/23699246/how-to-query-for-all-direct-subclasses-in-sparql

[dallemang]

That explains why it doesn't respond to follow-your-nose! Thanks for tracking that down, @rivettp .

[ghost]

I’ve been using FIBO with OWL2 RL inferencing so that I have all of the triples I might need. This allows me to use transitive SKOS properties for visual/large scale navigation and the non-transitive properties for detailed work.

@dallemang explained the source of my cognitive difficulties with his explanation of the convention governing the use of rdfs:subClassOf. If it is not being used as a transitive property then my issue is resolved. But I would be of immense utility to me if these conventions could be formally codified in a manner that could be implemented by open source and COTS the reasoning tools. Could this be done in SHACL?

[VladimirAlexiev]

directSubClassOf (and its two friends directType and directSubPropertyOf) are described at

• https://rdf4j.org/javadoc/3.1.0/org/eclipse/rdf4j/model/vocabulary/SESAME.html
• http://archive.rdf4j.org/javadoc/sesame-4.1.0/org/openrdf/sail/inferencer/fc/DirectTypeHierarchyInferencer.html
• https://graphdb.ontotext.com/documentation/standard/query-behaviour.html

eclipse-rdf4j/rdf4j#2460 is a task by @jeenbroekstra to move them to an rdf4j namespace.

@rivettp what you describe is correct if you use FIBO in rdf4j or GraphDB. But I am not aware of other repos or Jena having similar "direct" predicates. (I'll raise an issue at SPARQL 1.2).

So I wonder whether there would be any harm if FIBO emitted this:

A rdfs:subClassOf B; sesame:directSubClassOf B

@jeenbroekstra, will this cause duplication of directSubClassOf triples or other adverse effects?

[VladimirAlexiev]

Jena has https://jena.apache.org/documentation/javadoc/jena/org/apache/jena/vocabulary/ReasonerVocabulary.html#directSubClassOf
"public static final Property directSubClassOf
The property that represents the direct/minimal version of the subClassOf relationship".
... And more in that vein.
I don't yet know what is the prop URL to use.

So this calls for standardizing: it would be wrong for FIBO to emit such direct properties explicitly.

[rivettp]

It's only a pseudo-predicate for use in SPARQL and would never appear in an ontology. FIBO would not "emit" such properties, but use the pseudo-predicate in the SPARQL for hygiene tests.

[abrokenjester]

@jeenbroekstra, will this cause duplication of directSubClassOf triples or other adverse effects?

Asserting them in the ontology will not have any direct negative effects. In fact the DirectTypeInferencer in RDF4J currently works by asserting these triples into the store itself. The only difference is that the inferencer marks them as inferred statements, and if you assert them yourself, they will become explicit. But asserting them yourself, even in combination with use of the direct type inferencer, will not cause any duplication unless perhaps you assert as part of a named graph.