To say that "ex:hasFather rdfs:subPropertyOf ex:hasParent" is a triple-generating inference (and different from rdfs:subClassOf), is a misunderstanding of RDFS semantics, which are declarative and not imperative (as are all model-theoretic semantics).
Logical implication and materialization of logically implied facts (or RDF triples) are two different things. You can build reasoners that materialize rdfs:subPropertyOf / rdfs:subClasOf triples (forward-chaining) exhaustively or you can build reasoners that can include implied triples upon query, without materialization (backward-chaining), both are different approaches to implementing the same semantics. So, I think you are conflating reasoning semantics with how they are implemented in practice.
It seems problematic for an RDF specification (built on the existing SW foundation) to have a state of behavior where it disregards RDFS semantics and operates only on the asserted graph and not the inferred graph
It's a good point, and one that I'm somewhat back and forth on. One thing I'm discovering is that both rdfs:subClassOf and (especially) rdfs:subPropertyOf carry significant semantic weight that is often assumed but not necessarily closely examined, and that's becoming more evident to me the more I look at SHACL as a structural language.
Ultimately, it comes down to rules and where (and how) they get materialised. A rule generates triples. Those triples have to go somewhere - into a materialisation graph, a source graph, or an external graph (ie., used for some other process outside the scope of the rule). SHACL rules are no different than SPIN or other rule generators. They (and node expressions in SHACL) shift the role of SHACL out of *just* being a validator and into being a generator, and ultimately the question comes down to what is being queried: source + materialised graph (which is what a reasoner does as well) or just into a separate graph that's distinct from the source.
I guess I'm confused about how this is possibly imperative. The only imperative aspect is that you have to choose what invokes the rules in the first place, and that's less a data architecture issue and more a systems architecture one.
To say that "ex:hasFather rdfs:subPropertyOf ex:hasParent" is a triple-generating inference (and different from rdfs:subClassOf), is a misunderstanding of RDFS semantics, which are declarative and not imperative (as are all model-theoretic semantics).
Logical implication and materialization of logically implied facts (or RDF triples) are two different things. You can build reasoners that materialize rdfs:subPropertyOf / rdfs:subClasOf triples (forward-chaining) exhaustively or you can build reasoners that can include implied triples upon query, without materialization (backward-chaining), both are different approaches to implementing the same semantics. So, I think you are conflating reasoning semantics with how they are implemented in practice.
It seems problematic for an RDF specification (built on the existing SW foundation) to have a state of behavior where it disregards RDFS semantics and operates only on the asserted graph and not the inferred graph
Hi Chimezie!
It's a good point, and one that I'm somewhat back and forth on. One thing I'm discovering is that both rdfs:subClassOf and (especially) rdfs:subPropertyOf carry significant semantic weight that is often assumed but not necessarily closely examined, and that's becoming more evident to me the more I look at SHACL as a structural language.
Ultimately, it comes down to rules and where (and how) they get materialised. A rule generates triples. Those triples have to go somewhere - into a materialisation graph, a source graph, or an external graph (ie., used for some other process outside the scope of the rule). SHACL rules are no different than SPIN or other rule generators. They (and node expressions in SHACL) shift the role of SHACL out of *just* being a validator and into being a generator, and ultimately the question comes down to what is being queried: source + materialised graph (which is what a reasoner does as well) or just into a separate graph that's distinct from the source.
I guess I'm confused about how this is possibly imperative. The only imperative aspect is that you have to choose what invokes the rules in the first place, and that's less a data architecture issue and more a systems architecture one.