Re: CORRECTION Terminology: Data Source & Domain Ontologies

Satya Sahoo wrote:
> 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.).
"Data Source Ontology" is a simple TBox derived from the SQL Schema 
based on:
Table-->Class
Column->Attribute (one kind of property)
Foreign Key-->Association/Relationship with another Class (another kind 
of property)

Relational Databases on the Semantic Web re. the mapping above is 
basically what NeXT offered with EOF (with current day rudiments in Mac 
OS X Core Data Services). 

The same approach applies to .NET's Entity Frameworks.

My key point here is that the concept of mapping RDBMS schemas to Entity 
Models pre-dates the Semantic Web.
>  
> 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.

Yes.
>  
> 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.
In some cases you can just generate a basic TBox for an RDBMS schema ( 
"Data Source Ontology") and then focus the rest of the mappings to 
effort en route to a  "Domain Ontology" without touching the ABox. Of 
course, in some cases you can map directly to the "Domain Ontology", but 
it shouldn't deemphasize the utility of the "Data Source Ontology". 
Thus, I don't see any mutual exclusivity here, each approach offers 
value, and for continuity re. knowledge development and dispatch re. 
RDB2RDF, the "Data Source Ontology" is a great conduit (since this is 
the common pattern already in play outside the RDF realm).

Kingsley
>  
> Satya Sahoo
> http://knoesis.wright.edu/researchers/satya
>   


-- 


Regards,

Kingsley Idehen	      Weblog: http://www.openlinksw.com/blog/~kidehen
President & CEO 
OpenLink Software     Web: http://www.openlinksw.com

Received on Tuesday, 25 November 2008 03:13:13 UTC