--- license: Apache-2.0 name: fipa-00086-ontology-service description: Framework for coordinating meaning across autonomous agents that use different conceptual models, vocabularies, and knowledge representations. Treats ontologies as first-class negotiable resources rather than hardcoded implementation details. category: Research & Academic tags: - fipa - ontology - agents - knowledge-representation - standards --- # SKILL: FIPA Ontology Service — Semantic Coordination for Multi-Agent Systems ## Decision Points ### Mismatch Type → Coordination Strategy ``` Agent A & B have semantic mismatch: ├─ Syntactic mismatch (different formats/protocols)? │ └─ NOT an ontology problem → use protocol adapters/formatters │ ├─ Same ontology by reference? │ └─ SUCCESS → direct communication, no translation needed │ ├─ Different ontologies, assess relationship: │ ├─ Equivalent conceptualizations, different vocabularies? │ │ └─ Create bidirectional term mapping → strong translatability │ │ │ ├─ One ontology subsumes the other? │ │ ├─ Task requires specialized concepts → use richer ontology │ │ └─ Task works with general concepts → use simpler ontology │ │ │ ├─ Partial overlap with acceptable information loss? │ │ ├─ Task tolerates approximation → implement lossy translation │ │ └─ Task requires precision → negotiate shared ontology or mediator │ │ │ └─ No meaningful translation possible? │ ├─ Find mediating ontology both can translate to │ ├─ Renegotiate task to use compatible concepts │ └─ ESCALATE: coordination impossible at ontology level ``` See `references/translation-hierarchy-as-coordination-strategy.md` for the six formal relationship levels (Identical → Equivalent → Extension → Strongly-Translatable → Weakly-Translatable → Approximately-Translatable) and their operational implications as coordination constraints. ### Explicit vs Implicit Ontology Choice ``` System requirements analysis: Will unknown agents join at runtime? ├─ YES → EXPLICIT ontologies required │ └─ Need discovery/negotiation infrastructure │ └─ NO → Analyze further: │ ├─ Performance critical (real-time, embedded)? │ └─ IMPLICIT → hard-code shared conceptualization │ ├─ Requirements likely to evolve? │ └─ EXPLICIT → enable runtime adaptation │ └─ Stable, closed system? └─ IMPLICIT → optimize for execution speed ``` ### Integration Approach Selection ``` Integrating existing heterogeneous systems: Proposed approach is "find ontology intersection"? ├─ YES → RED FLAG: Bottom-up integration │ ├─ Syntactic overlap ≠ semantic overlap │ ├─ Risk of silent semantic failures │ └─ ALTERNATIVE: Top-down foundation approach │ └─ NO → Assess current approach: │ ├─ Starting with shared conceptual primitives? │ └─ GOOD → verify intended models align │ ├─ Mapping to existing standard ontology? │ └─ GOOD → validate translation completeness │ └─ Building custom mediating ontology? └─ VERIFY: covers both systems' essential concepts ``` See `references/bottom-up-integration-fallacy.md` for why intersection-based integration fails even when vocabularies appear to overlap. ## Failure Modes ### 1. Rubber Stamp Translation **Symptoms**: Systems exchange messages successfully, but agents take incompatible actions based on "translated" content **Detection Rule**: If agents claim successful communication but exhibit contradictory behaviors, check for semantic misalignment despite syntactic compatibility **Root Cause**: Assumed same vocabulary means same conceptualization **Fix**: Verify intended models, not just formal models; implement semantic validation checks ### 2. Intersection Illusion **Symptoms**: Integration project finds "common concepts" between ontologies but coordination fails mysteriously during testing **Detection Rule**: If ontology intersection contains terms with identical names but agents interpret them differently, this is intersection illusion **Root Cause**: Bottom-up integration assuming syntactic overlap guarantees semantic overlap **Fix**: Switch to top-down approach; establish shared conceptual foundation first ### 3. Perfect Translation Trap **Symptoms**: Integration project stalls because "perfect" translation between ontologies is impossible to achieve **Detection Rule**: If project blocks on achieving lossless bidirectional translation when task only requires approximate coordination **Root Cause**: Over-engineering translation requirements beyond task needs **Fix**: Match translation quality to task requirements using hierarchy (identical → equivalent → strongly translatable → weakly translatable → approximate) ### 4. Silent Semantic Drift **Symptoms**: System appears to work initially but produces increasingly incorrect results over time **Detection Rule**: If coordination quality degrades without syntax errors, check for conceptualization divergence **Root Cause**: Implicit ontologies evolving independently without coordination **Fix**: Make ontologies explicit; implement semantic version control and change notification ### 5. Ontology Service Neglect **Symptoms**: Each agent implements its own translation logic, creating N² complexity and inconsistent translations **Detection Rule**: If translation code is duplicated across agents and produces different results for same inputs **Root Cause**: Treating ontology coordination as per-agent concern rather than system infrastructure **Fix**: Implement centralized Ontology Agent service; standardize on OKBC interlingua for meta-knowledge operations (see `references/ontology-agent-as-coordination-infrastructure.md`) ## Worked Examples ### Example 1: Weather Data Integration **Scenario**: Emergency response system needs weather data from two sources: MeteoService (European, Celsius, wind in km/h) and WeatherAPI (US, Fahrenheit, wind in mph). **Symptom**: Both services provide "temperature" and "wind_speed" but emergency system makes wrong evacuation decisions. **Diagnosis Process**: 1. Check syntactic compatibility ✓ (both use JSON) 2. Check ontology relationship: Different vocabularies, same conceptualization (weather measurements) 3. Assess translation requirement: Emergency system needs "hot enough to cause fire risk" (approximate translation sufficient) **Decision Navigation**: - Mismatch type: Different ontologies, partial overlap with acceptable loss - Task tolerates approximation: YES (fire risk threshold has safety margins) - Strategy: Implement lossy translation with explicit bounds **Solution**: Create translation service with conversion functions and explicit error bounds (±2°C, ±5km/h). Emergency system uses "hot enough for fire risk" threshold that accounts for translation uncertainty. **Expert vs Novice**: - Novice would try to achieve perfect translation or assume same field names mean same semantics - Expert recognizes approximate translation suffices for task and implements explicit error bounds ### Example 2: Multi-Organization Agent Coordination **Scenario**: Healthcare agents from Hospital-A (using HL7 FHIR) and Research-Lab (custom medical ontology) need to coordinate patient data for clinical trial. **Symptom**: Agents exchange messages but Research-Lab misinterprets "patient status" leading to wrong treatment group assignments. **Diagnosis Process**: 1. Both claim FHIR compatibility but Research-Lab extends concepts differently 2. Check conceptualization alignment: Different interpretations of "patient status" (Hospital: administrative, Research: clinical) 3. Translation hierarchy assessment: Weakly translatable (Hospital→Research works, reverse loses information) **Decision Navigation**: - Mismatch type: Extension relationship with semantic drift - Information loss acceptable: NO (clinical trial requires precision) - Strategy: Negotiate shared subset or use mediating ontology **Solution**: Deploy Ontology Agent with mediating vocabulary covering both systems' essential concepts. Both agents translate to/from mediator rather than direct translation. **Trade-offs Discussed**: - Performance cost of mediated translation vs. risk of semantic errors - Complexity of three-way ontology maintenance vs. benefits of precision - Option to constrain Hospital system to Research concepts vs. developing comprehensive mediator ## Quality Gates - [ ] Ontology relationships formally verified (not assumed based on syntax similarity) - [ ] Translation completeness validated for task-essential concepts - [ ] Semantic failure detection mechanisms implemented (not just syntactic error handling) - [ ] Error bounds established for approximate translations with explicit uncertainty propagation - [ ] Intended model alignment confirmed through test cases, not just formal model compatibility - [ ] Runtime ontology negotiation protocols specified if system supports dynamic agent joining - [ ] Escalation paths defined for untranslatable semantic mismatches - [ ] Performance impact of explicit ontologies measured against coordination benefits - [ ] Conceptualization vs ontology vs knowledge base layers explicitly distinguished in design - [ ] Silent semantic failure prevention measures in place (validation, bounds checking, compatibility verification) ## NOT-FOR Boundaries **Do NOT use this skill for**: - **Syntactic data format conversion** → Use data mapping/ETL tools instead - **Database schema integration** → Use database integration patterns instead - **API versioning and compatibility** → Use API evolution strategies instead - **Performance optimization of knowledge queries** → Use database optimization techniques instead - **Natural language processing and understanding** → Use NLP/NLU frameworks instead - **Closed systems with stable, shared conceptual models** → Use direct integration patterns instead - **Real-time systems where translation overhead is prohibitive** → Use pre-compiled shared ontologies instead **When to delegate**: - For syntactic transformations: Use `data-transformation-pipelines` skill - For performance-critical knowledge operations: Use `knowledge-base-optimization` skill - For natural language semantic understanding: Use `semantic-nlp-processing` skill - For API design and evolution: Use `api-design-patterns` skill This skill focuses specifically on **coordination between autonomous agents with different conceptual models**. It is not a general-purpose semantic technology or data integration solution. ## Bundled Assets ### Diagrams `diagrams/INDEX.md` — visual decision tree, coordination protocol sequence, and three-layer ontological model. ### Reference Deep-Dives `references/INDEX.md` — detailed explorations of the translation hierarchy, bottom-up integration fallacy, OKBC interlingua, Ontology Agent architecture, and all five failure modes.