Add inference rules#35
Open
cthoyt wants to merge 5 commits into
Open
Conversation
matentzn
reviewed
Jun 11, 2026
matentzn
left a comment
matentzn
left a comment
Contributor
There was a problem hiding this comment.
All new rows leave dc:source, skos:example, and rdfs:comment empty. At minimum the abstract rules should cite the chaining rules doc as source (you already do this for MappingInversion).
Should we consider whether there's a structural way to express that links Justifications with specific inference rules?
I have not made up my mind on the naming; this is a first round of feedback but more will come when I have time after my time off.
| semapv:AgentBasedMatching agent-based matching process A matching process in which an autonomous agent plans and executes a multi-step workflow — typically involving tool use, retrieval, intermediate reasoning, and self-evaluation — to determine matches between entities. The agent decides at runtime what information to gather, which techniques to apply, and when to stop. https://doi.org/10.48550/arXiv.2503.21902 An agent is given a pair of candidate entities and autonomously decides to look up their labels, query an external knowledge base, retrieve definitions, compare them with a similarity measure, and revise its judgement before producing a final match decision; the OntoAligner toolkit provides agentic matching of this kind. Distinguished from single-step LLM-based matching by the agent's autonomy over its own process. Distinguished from composite matching, which combines heterogeneous matching techniques under a fixed pipeline, by the agent's runtime control over what to do next. In current practice, agent-based matchers are predominantly driven by large language models, but this class does not commit to a particular agent technology — a specific process may also be classified as semapv:LLMBasedMatching (or any other matching class) where appropriate. agentic matching|agentic ontology matching semapv:Matching | ||
| semapv:Blocking blocking A mapping activity that, given two sets of input entities, produces a reduced set of candidate entity pairs likely to match — favouring recall over precision — to be passed on to a downstream matching process. https://doi.org/10.1007/978-3-642-38721-0 Out of 10^7 possible subject–object pairs, a blocker returns 10^5 candidate pairs by applying inexpensive comparisons such as token overlap, hash buckets, or embedding-space nearest-neighbour search. Blocking is conceptually distinct from matching: a blocker is recall-oriented and typically encodes each entity independently of the others, whereas a matcher is precision-oriented and decides about a specific candidate pair. Many modern pipelines combine an embedding-based blocker with a transformer- or LLM-based matcher. candidate generation|candidate retrieval semapv:MappingActivity | ||
| semapv:EmbeddingBasedBlocking embedding-based blocking A blocking process in which entities are encoded independently as vector embeddings and candidate pairs are produced by nearest-neighbour search or similarity-threshold filtering in the embedding space. https://doi.org/10.48550/arXiv.2310.11244 A sentence-transformer encodes every subject and object label into a vector; an approximate nearest-neighbour index (e.g. FAISS) returns, for each object, the top-k subjects whose embeddings are closest in cosine distance, as the set of candidate pairs to be matched downstream. bi-encoder blocking|embedding-based candidate generation semapv:Blocking | ||
| semapv:InferenceRule inference rule An inference rule for chaining two or more mappings to produce a third mapping |
Contributor
There was a problem hiding this comment.
I would not use the word "chaining" here - that seems duplicative with ChainingRule. Just "deterministically deriving a mapping from a set of existing mappings"?
| semapv:EmbeddingBasedBlocking embedding-based blocking A blocking process in which entities are encoded independently as vector embeddings and candidate pairs are produced by nearest-neighbour search or similarity-threshold filtering in the embedding space. https://doi.org/10.48550/arXiv.2310.11244 A sentence-transformer encodes every subject and object label into a vector; an approximate nearest-neighbour index (e.g. FAISS) returns, for each object, the top-k subjects whose embeddings are closest in cosine distance, as the set of candidate pairs to be matched downstream. bi-encoder blocking|embedding-based candidate generation semapv:Blocking | ||
| semapv:InferenceRule inference rule An inference rule for chaining two or more mappings to produce a third mapping | ||
| semapv:InversionRule inversion rule An inference rule for mapping inversions, under which a mapping <s, p, o> is inverted <o, p', s> if and only if p and p' are inverse predicates, such as skos:broadMatch and skos:narrowMatch. Some predicates such as skos:exactMatch are their own inverses. Mappings produced under this rule should be assigned the justification semapv:MappingInversion. semapv:InferenceRule | ||
| semapv:MutationRule mutation rule An inference rule for mapping inversions, under which a mapping <s, p, o> is mutated <s, p', o>. For example, owl:equivalentTo can always be weakened to skos:exactMatch. In some circumstances, oboInOwl:hasDbXref can be strengthened to skos:exactMatch. Mappings produced under this rule should be assigned the justification semapv:BackgroundKnowledgeBasedMatching. semapv:InferenceRule |
Contributor
There was a problem hiding this comment.
Also there is no owl:equivalentTo, only owl:equivalentClass: https://www.w3.org/TR/owl-ref/#equivalentClass-def
| semapv:InversionRule inversion rule An inference rule for mapping inversions, under which a mapping <s, p, o> is inverted <o, p', s> if and only if p and p' are inverse predicates, such as skos:broadMatch and skos:narrowMatch. Some predicates such as skos:exactMatch are their own inverses. Mappings produced under this rule should be assigned the justification semapv:MappingInversion. semapv:InferenceRule | ||
| semapv:MutationRule mutation rule An inference rule for mapping inversions, under which a mapping <s, p, o> is mutated <s, p', o>. For example, owl:equivalentTo can always be weakened to skos:exactMatch. In some circumstances, oboInOwl:hasDbXref can be strengthened to skos:exactMatch. Mappings produced under this rule should be assigned the justification semapv:BackgroundKnowledgeBasedMatching. semapv:InferenceRule | ||
| semapv:ChainingRule chaining rule An inference rule for mapping chaining, under which two or more mappings are chained to produce a new mapping based on their network structure. For example, a simple chaining rule takes mappings <e1, p1, e2> and <e2, p2, e3> and produces <e1, p3, e3>. Mappings produced under this rule should be assigned the justification semapv:MappingChaining. semapv:InferenceRule | ||
| semapv:TransitivityRule transitivity rule An inference rule over the transitivity of a predicate p such that <e1, p, e2> and <e2, p, e3> infer <e1, p, e3>. A widely used example is when skos:exactMatch is used for p semapv:ChainingRule |
Contributor
There was a problem hiding this comment.
skos:exactMatch is used for p
? sentences ends prematurely
| semapv:EquivalentClassTransitivityRule equivalent class transitivity rule An inference rule over the transitivity of owl:equivalentClass such that <e1, owl:equivalentClass, e2> and <e2, owl:equivalentClass, e3> infer <e1, owl:equivalentClass, e3> semapv:TransitivityRule | ||
| semapv:EquivalentPropertyTransitivityRule equivalent property transitivity rule An inference rule over the transitivity of owl:equivalentProperty such that <e1, owl:equivalentProperty, e2> and <e2, owl:equivalentProperty, e3> infer <e1, owl:equivalentProperty, e3> semapv:TransitivityRule | ||
| semapv:EquivalentIndividualTransitivityRule equivalent individual transitivity rule An inference rule over the transitivity of owl:sameAs such that <e1, owl:sameAs, e2> and <e2, owl:sameAs, e3> infer <e1, owl:sameAs, e3> same as transitivity rule semapv:TransitivityRule | ||
| semapv:SubClassOfTransitivityRule subclass transitivity rule An inference rule over the transitivity of rdfs:subClassOf such that <e1, rdfs:subClassOf , e2> and <e2, rdfs:subClassOf , e3> infer <e1, rdfs:subClassOf , e3> subclass of transitivity rule semapv:TransitivityRule |
Contributor
There was a problem hiding this comment.
various double spaces in this PR, like after rdfs:subClassOf
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
2 participants
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.
This PR attempts to encode some of the inference rules that Nico and I wrote and put in https://mapping-commons.github.io/sssom/dev/chaining-rules/
On a first pass, I want to get an upper level structure right. I added some specifics just for transitivity, to demonstrate how having a hierarchy works. On a second pass, I could add the remaining rules.
Review here: https://github.com/cthoyt/semantic-mapping-vocabulary/blob/09050f53c0fd96d8502db1e11a1d2833f4664dcd/semapv-terms.tsv#L59
However, I am actually more hesitant to put this in SEMAPV now that before because of the transparent identifiers. I have a feeling that we will want to relabel some of these things in the future and don't want to commit to a massive namespace of transparent names