{{{
#!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 seeks to show what differentiates 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".

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 ==
 
 * Translations: Language to Language Integration
 * Lingua Franca: Common Language for Integration
 * Universal Language: Single Language for All Purposes
 (@todo discussion to add)

== 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

== Two Approaches to Templates ==

The distinction I wanted to make is that from my point of view,
templates as a term in 15926 need to include at least two extremes,
and everything in else between them.

I see these two extremes as being templates produced with a top-down
process, where you start essentially with the template and then
figure out what it really means by breaking it down into smaller and
smaller relationships; and then templates produced with a bottom-up
process, where you start with binary relationships and work your way
up, generating coarser and coarser templates.

Very simplistically, when you take a linguistic approach to
defining templates, you are using a top-down approach; when
you take a usage approach to defining templates (eg. from
existing spreadsheets, datasheets), you are also using a
top-down approach; but when you use a formal logical approach
to defining templates, you are using a bottom-up approach.

It is my *belief* that linguistic templates and usage templates
are the fastest to develop, but with the caveat that when working
in a collaborative, distributed effort to produce them, they are
unlikely to "fit" well with eachother, instead, resulting in
little "cultures" of related, relatively well-fitting templates
that do not address the needs of disciplines or environments
that they were not generated from - ie. poor fit to other "cultures".

It is also my *belief* that bottom-up approaches to templates
are slower to develop and more costly to map to, but they result
in models that retain a higher level of precision across
disciplines and they can be produced as a cohesive set in a
distributed, collaborative effort (because you have to build
from smaller, existing, published blocks).  You can still get
cultures forming, but at least they will have at their root
a common basis.

== 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.

}}}

----