TracNav menu
-
RDS/WIP project
- RDS/WIP Introduction
-
RDS/WIP World View
- Models, Data & Meta-Data
- Paths to Interoperability
- Automated Mapping
- Thought and Language
- Coarse to Fine
- Fine to Coarse
- Template Methodologies
- Choice of System
- Conclusions
- RDS/WIP Sample Queries
- RDS/WIP Staging Diagrams
- RDS/WIP 1.0 Plan
- RDS/WIP 1.0 Testing
- RDS/WIP 1.0 Process
- RDS/WIP 1.0 Inventory
- RDS/WIP 2.0 Plan
- RDS/WIP ID Generator
- RDS/WIP Domain Proposal
- RDS/WIP Requirements Table
- RDS/WIP Use Case: Discrete Editing
- RDS/WIP Use Case: CSV Upload
- RDS/WIP 1.0 General Use Cases
- RDS/WIP 2.0 General Use Cases
- RDS/WIP ISO 15926 Template Definitions
- RDS/WIP OWL/RDF Definition
- RDS/WIP OWL/RDF Project Plan
- RDS/WIP Forums
-
External
- RDS/WIP Use Case: Bulk Upload
POSC-Caesar FIATECH IDS-ADI Projects
Intelligent Data Sets Accelerating Deployment of ISO15926
Realizing Open Information Interoperability
RDS/WIP World View: Paths to Interoperability
The RDS/WIP has been conceived to support many different approaches to interopability. The need for this is clear: the source of information (human thought and language) uses generalization at many different levels for the same information, largely depending on the discipline and the need for precision.
Approaches
There are several approaches to interoperability - these are outlined here, making analogy to human languages:
1. Point to Point: translate directly from any language to every other language as needed. This approach is costly and error prone for everyone.
2. Lingua Franca: collectively identify a language as usefully common and translate only to and from it. The burden on a lingua franca in terms of solving engineering problems is that it must have the expressive power to represent information from many different sources.
3. Mandated Language: force everyone to speak one language natively. That means push definitions out into every software application in the domain and force software vendors to adapt to its structures and way of thinking.
Support
The RDS/WIP must provide support for all of these approaches. In all cases, it provides a place to publish reference data for the language and mappings to and from other languages.
Mapping Languages
Note however that the mappings themselves must be written in some sort of language, and in many cases, it is the expressive power of this language that determines how precise and fidelity-retaining a mapping can be.
Yet, a mapping language can be (necessarily) reduced to specification just as well as any other language, and so, a mapping language itself must also be able to be recorded in the RDS/WIP, just as its rules must be.
Automated Mapping
Providing any two sets of reference data can be reduced to the same common set of primitive relations, and cardinality constraints do not apply in an inconsistent way in the original forms, it should be possible to automatically derive direct mappings from one set to the other.
Summary
The RDS/WIP needs to be neutral to many different types of interoperability and mapping language: capable of storing reference data in a highly generic manner and yet retaining the ability to make this information consumable by both automatons and humans.
