Re: CORRECTION Terminology: Data Source & Domain Ontologies

In the spirit of moving towards RDB2RDF lexicon, as I understand mapping of RDB to RDF can be viewed from two perspectives (using DL terms):
1. RDF data (ABox) generated without the creating or using an existing model/ontology schema (TBox) - The mapping logic is simply captured in code or as expressions (often XPath etc.).

2. RDF data (ABox) + a model/ontology (TBox - often in RDFS/OWL) - In this case, I believe the "Data Source ontology" is a bootstrapping step that exploits the mappings rules from Tim Berners Lee (1998),"Relational Databases on the Semantic Web",  "Table -> Class" and "Column -> Property" with additional refinements (for FK etc.). 
 
For real world applications, as we see in biomedical domain or ordnance survey, incorporating domain semantics is essential, preferably in form an explicit "Domain ontology", for the RDF instance to be of any practical use. A "Domain ontology" may either be created "Top-down" by domain experts from scratch - such as the biomedical ontologies listed at the National Center for Biomedical Ontologies (NCBO) - Open Biomedical Ontologies (OBO), or "Bottom-up" where "Data Source ontologies" are used as initial input and then enhanced further by domain experts.
 
But, once a "Domain ontology" has been created, I don't see the need for "Data Source ontology", since in my view "Domain ontology" will be "superset" of "Data Source ontology" and applications can directly interface with the RDB or create a "RDF dump" (often called ontology population) - using the mapping logic  in "Domain ontology". If the "Data Source ontology" satisfies the requirements of an application then also we have a single ontology - the "Data Source ontology" (= "Domain ontology"). I am not sure I see the need/benefit for multiple-levels of ontologies and bring in mapping issues between them, which in my view is a redundant exercise.
 
Satya Sahoo
http://knoesis.wright.edu/researchers/satya