3 files changed, 80 insertions, 25 deletions
diff --git a/docs/datadictionary/index.rst b/docs/datadictionary/index.rst
index 83c6e47b8..a7e78564f 100644
--- a/docs/datadictionary/index.rst
+++ b/docs/datadictionary/index.rst
@@ -9,37 +9,74 @@ Resource Definition
 
 Introduction:
 =============
-A Resource Definition defines a specifc resource that can be resolved using the bellow supported sources.
+A data dictionary models the how a specific resource can be resolved.
 
-A Resource Definition can support multiple sources.
+A resource is a variable/parameter in the context of the service. It can be anything, but it should not be confused with SDC or Openstack resources.
 
-The main goal of Resource Definition is to define generic entity that could be shared accross services.
+A data dictionary can have multiple sources to handle resolution in different ways.
 
+The main goal of data dictionary is to define re-usable entity that could be shared.
 
-Resolution sources:
-===================
+Creation of data dictionaries is a standalone activity, separated from the blueprint design.
 
-   * Input
-   * Default
-   * DB
-   * REST
-   * Capability
 
-Artifacts:
-==========
+As part of modelling a data dictionary entry, the following generic information should be provided:
 
-   * artifact-mapping-resource
-   * artifact-template-velocity
-   * artifact-directed-graph
+|image0|
 
-Node type:
-==========
-	
-   * component-resource-resolution
-   * component-jython-executor
-   * component-netconf-executor
-   * component-restconf-executor
+.. |image0| image:: media/image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
 
-Data type:
-==========
-   * vnf-netconf-device
-\ No newline at end of file
+Bellow are properties that all the resource source have will have
+
+The modeling does allow for data translation between external capability and CDS for both input and output key mapping.
+
+|image1|
+
+.. |image1| image:: media/image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+
+Example:
+========
+
+vf-module-model-customization-uuid and vf-module-label are two data dictionaries. A SQL table, VF_MODULE_MODEL, exist to correlate them.
+
+Here is how input-key-mapping, output-key-mapping and key-dependencies can be used:
+
+vf-module-label data dictionary  
+
+{
+  "name" : "vf-module-label",
+  "tags" : "vf-module-label",
+  "updated-by" : "adetalhouet",
+  "property" : {
+    "description" : "vf-module-label",
+    "type" : "string"
+  },
+  "sources" : {
+    "primary-db" : {
+      "type" : "source-primary-db",
+      "properties" : {
+        "type" : "SQL",
+        "query" : "select sdnctl.VF_MODULE_MODEL.vf_module_label as vf_module_label from sdnctl.VF_MODULE_MODEL where sdnctl.VF_MODULE_MODEL.customization_uuid=:customizationid",
+        "input-key-mapping" : {
+          "customizationid" : "vf-module-model-customization-uuid"
+        },
+        "output-key-mapping" : {
+          "vf-module-label" : "vf_module_label"
+        },
+        "key-dependencies" : [ "vf-module-model-customization-uuid" ]
+      }
+    }
+  }
+}
+
+
+Resource source:
+================
+
+Defines the contract to resolve a resource.
+
+A resource source is modeled, following http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.0/csprd01/TOSCA-Simple-Profile-YAML-v1.0-csprd01.html#DEFN_ENTITY_NODE_TYPE, and derives from the https://wiki.onap.org/display/DW/Modeling+Concepts#ModelingConcepts-NodeResourceSource
+\ No newline at end of file
diff --git a/docs/index.rst b/docs/index.rst
index 8db565a37..477c251da 100644
--- a/docs/index.rst
+++ b/docs/index.rst
@@ -13,6 +13,24 @@ The system is designed to be self service, which means that users, not just prog
 Self service is a completely new way of delivering services.  It removes the dependence on code releases and the delays they cause and puts the control of services into the hands of the service providers.  They can change a model and its parameters and create a new service without writing a single line of code.  
 This makes SERVICE PROVIDER(S) more responsive to its customers and able to deliver products that more closely match the needs of its customers.
 
+Modeling Concept:
+=================
+In Dublin release, the CDS community has contributed a framework to automate the resolution of resources for instantiation and any config provisioning operation, such as day0, day1 or day2 configuration.
+
+The content of the CBA Package is driven from a catalog of reusable data dictionary, component and workflow, delivering a reusable and simplified self service experience.
+
+TOSCA based JSON formatted model following standard: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/csd01/TOSCA-Simple-Profile-YAML-v1.2-csd01.html
+
+Most of the TOSCA modeled entity presented in the bellow documentation can be found here: https://github.com/onap/ccsdk-cds/tree/master/components/model-catalog/definition-type/starter-type
+
+Tosca Model Reference: 
+
+|image0|
+
+.. |image0| image:: media/image0.jpg
+   :width: 7.88889in 
+   :height: 4.43750in
+
 Design tools:
 =============
 .. toctree::
diff --git a/docs/media/image0.jpg b/docs/media/image0.jpg
new file mode 100644
index 000000000..dce3cee25
--- /dev/null
+++ b/docs/media/image0.jpg