{{{
#!comment
NB! Make sure that you follow the guidelines: http://trac.posccaesar.org/wiki/IdsAdiEditing
}}}

[[TracNav(TracNav/RdsWip)]]
[[Image(wiki:IdsAdiBranding:Logo-128x128.gif)]]
= POSC-Caesar FIATECH IDS-ADI Projects =
== Intelligent Data Sets Accelerating Deployment of ISO15926 ==
== ''Realizing Open Information Interoperability'' ==

----

= RDS/WIP World View =

IDS-ADI envision the RDS/WIP as a collaborative space for development and publication of multiple reference data libraries and the mappings between them.

This page is an informal treatment in an essay style that seeks to show what differentiates these libraries, the methodologies that produce them, approaches to mapping and the means by which all of these together address interoperability.

== Model and Data ==

Probably the most important underpinning of the RDS/WIP as a concept is that [wiki:RdsWipWorldView/ModelMetaData the model is meta-data, and meta-data is data].

It is a short and simple step from this to establish that if you must transmit models, meta-data and related data, then it is simplest to utilise a system that allows you to treat all of that information in the same way, so that you can operate on meta-data and models just as though they were data.

To this end, we chose RDF and its supporting technologies (triplestores, OWL, SPARQL and URIs) as core elements of the RDS/WIP.

== Relations, Classes and Members ==

Since RDF views all information as binary relationships, it becomes necessary to cast information into that mold in order to incorporate it into the RDS/WIP.

(@todo introduce notion of "system" to describe models built on the same foundation)

(@todo link to description of, differences between this and OO, ER etc.)

== Templates ==

While it is possible to just put raw RDF into the RDS/WIP, its useful (and in fact easier), to leverage previous work in adapting other systems
to RDF.  Moreover, providing some common structure makes transformation between systems far easier.

While RDF provides three core concepts: binary relations, classes, and membership in classes, the most common missing pattern that we see in other systems is n-ary relations.  

In the RDS/WIP we borrow the term "template" from ISO 15926 to describe an n-ary relation and its related definitional rules and meta-data.

== Arriving at Definitions ==

To make a set of definitions work well together, it is necessary
for them to have been produced via some cohesive process.  We
call these processes "methodologies".

[wiki:RdsWipWorldView/TemplateMethodologies] Different methodologies can
be used to create sets of definitions in the same model.  Sometimes, these sets of definitions will overlap, but for the most part they will be substantively different.

== Paths to Interoperability ==

There are at least three different [wiki:RdsWipWorldView/PathsToInteroperability paths to interoperability], and the choice of which path is largely determined by the maturity of information handling in the particular contexts in which a language is used.

The RDS/WIP can be used to support any path to interoperability that requires the publishing of reference data - but the path chosen has important ramifications for the kind of system it is necessary to adopt.

== Choice of System ==

The RDS/WIP is intended to be able to hold reference data for many
systems, so in order to contribute to the RDS/WIP, the submitter must
[wiki:RdsWipWorldView/ChoiceOfSystem choose a system] (or systems) to contribute to.  The most important part of this choice is the methodology,
because it is the methodology that leads to a particular standardization path.

----

(@note embedded comments contain notes)

{{{
#!comment

== Three Approaches to Interoperability ==

There are also at least three common approaches to interoperability:

1. Force everyone to speak your language natively.  That
  means push ISO 15926 definitions out into every software
  application that counts in your domain and force software

  developers to adapt to its structures and way of thinking.

2. Translate from your language to every other language that
  you need to.  Costly for everyone and a problem that I
  think ISO 15926 was conceived to redress by the former
  or the latter options.

3. Collectively identify a language as usefully common and
  translate only to and from it.  And again, ISO 15926 has
  a role to play here as that common language.

What I think is important though, is that for the latter
the *cost* of translating peer to peer or peer to common,
by investing in definitional machinery that can then be
used to create a cheap, strong translation engine.

If we take the top-down approach and run it to its
conclusion right down at the FOL level on existing
templates, and

In one case, you force everyone to speak your language.

99% of the definitions that will be imported into the WIP from
existing sources will have been arrived at through top-down
approaches, and 99% of those again will have no longhands to
start with.  I think the WIP should be a place people can put
things, and then collaboratively develop the longhands for them.

But we will very likely find that they are not logically consistent,
at least in a first order logic sense.  We need to accomodate that
reality.

}}}

----