Export says which family a rule belongs to, and an axiom rule its kind and declaring predicate - #910
Merged
Merged
Conversation
…d and declaring predicate A derivation's generating rule reached the export as a prov:Activity with only an rdfs:label, so a reader parsed the label to learn whether an axiom or a business rule produced a conclusion, and for inverse and sub_property could not recover which predicate the axiom was declared on without re-deriving the engine's convention from the exported owl:inverseOf / rdfs:subPropertyOf. Every rule resource is now typed utopia:AxiomRule or utopia:BusinessRule. An axiom rule carries utopia:axiomKind (the closed enum) and utopia:declaredOn, the IRI of the predicate the declaration sits on, read from rules.predicate_id in the same derived_page query. The label stays. Business-rule conditions and expressions are not exported: a business rule is edited in place, so its IRI cannot vouch for the definition an older conclusion was drawn under; that waits for rule versioning. Recorded as a dated revision of 0020; the MCP guide says the same. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Signed-off-by: Wayland Yang <wayland0916@gmail.com>
This was referenced Sep 24, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The first cut decided in #902.
A derivation's generating rule reached the export as a
prov:Activitywith only anrdfs:label, so a reader parsed the label to learn whether an axiom or a business rule produced a conclusion, and forinverseandsub_propertycould not recover which predicate the axiom was declared on without re-deriving the engine's convention from the exportedowl:inverseOf/rdfs:subPropertyOf.utopia:AxiomRuleorutopia:BusinessRule.utopia:axiomKind(transitive,symmetric,inverse,sub_property) andutopia:declaredOn, the IRI of the predicate the declaration sits on, which forinverseandsub_propertydiffers from the conclusion'srdf:predicate.derived_pagereadsrules.predicate_idin the same query; a predicate outside the base's vocabulary is simply not emitted, asrdf:predicatealready behaves.…:rule:{id}cannot vouch for the definition an older conclusion was drawn under. That waits for rule versioning.Recorded as a dated revision of 0020 (index row updated);
web/src/docs/mcp.mdsays the same. The two serializer tests assert the family type on both families, the kind and the declaring predicate on the axiom one, and their absence on the business one. rdf and export tests and clippy pass locally.Refs #902.
🤖 Generated with Claude Code