Re: Role of the Ontology and Expressivity - to discuss on telcon

On Apr 27, 2010, at 09:42 AM, Juan Sequeda wrote:
> On Tue, Apr 27, 2010 at 7:36 AM, Eric Prud'hommeaux <eric@w3.org> wrote:
> * Juan Sequeda <juanfederico@gmail.com> [2010-04-26 20:27-0400]
> > This week I commented on the role of the ontology [1] where we should
> > consider that we are mapping to the following:
> >
> >    - existing domain ontology (FOAF, SIOC, etc)
> >    - a putative ontology (automatically generating the ontology from the
> >    schema/DDL)
> >    - a federated ontology: combining different ontologies
> >
> >
> > Eric initially manifested the need to talk about the expressivity [2]. If I
> > understand correctly the issue of the expressivity is being presented as
> > "DIRECT - Recapulating Relational Structure" [3] and TRANSFORM -
> > Non-isomorphic transformation [4].
> >
> > I'm honestly a bit confused with both of these requirements, but this is my
> > take on them. Eric, please correct me if I'm wrong:
> >
> > DIRECT: What I understand is that you could essentially automatically
> > generate RDF triples (a graph) from the relational data. The top image shows
> > a graph of relational data and the bottom image shows how the previous graph
> > can be exposed as RDF (a graph) and it is equivalent (isomorphic) to the
> > relational data graph.
> >
> > TRANSFORM: In this section you have taken the previous relational data graph
> > and put it into the graph structure of two different ontologies. You show
>                                                       ^^^^^^^^^^
> > that if you compare the relational data graph with the two graph structures
> > of the two different ontologies, then the graphs are different
>                       ^^^^^^^^^^
> > (non-isomorphic).
> 
> I believe that you understand the expressivity points DIRECT and
> TRANSFORM, but I don't believe we can use the word "ontology" to
> describe graph shape. For example, an attribute diabetes_history
> could be represented in the SNOMED ontology as
>  # likely isomorphic to relational graph.
>  _:p sn:160303001 true .       # family history of diabetes
> or as
>  # likely non-isomorphic, but better model.
>  _:p sn:57177007 _:h .         # family history
>  _:h sn:24609004 sn:73211009 . # with finding of diabetes.
> As a sense of scale, the most popular medical ontology, SNOMED,
> has around 370k analogous representation choices (pre-coordinated
> terms).
> 
> Pre-existing ontologies also demand term synthesis. A ball bearing
> database with hardening treatment T5 would likely be expressed in a
> pre-existing RDF graph as a URI in an ontology of eutectic hardening.
> 
> In this, pre-existing ontologies are a motivation for a set of
> expressivities.

I think the expressivity you're seeking is tied to *reasoning*, not
tied to exposing RDB data as RDF data.

Bringing RDB into RDF requires only that the schema of that RDB be
mapped to a "direct" or "putative" ontology -- which *is* the correct
term.  This ontology serves only to unambiguously identify a single
cell (table, column, row) within that schema.

I suggest that then mapping that RDF into a "domain" ontology (e.g., 
SNOMED) is a separate concern -- which may be addressed in a couple 
of ways --

1. replication with transformation
2. mapping ontologies

The first means that you decide *once* how SNOMED corresponds to
a given RDB schema -- and if that correspondence changes, you have
to somehow discard all the triples that resulted from the original 
conversion and then re-convert the RDB data.

The second means that you decide how you think SNOMED corresponds
to your putative ontology, and create a "mapping" ontology --
which does little more than declare broaderClass, narrowerClass,
equivalentClass, sameAs, and such.  If you realize later that one
of your mappings is wrong, you change this ontology -- everything
else remains as it is.

Note that #2 does not mandate either forward- or backward-chaining.
You *can* work from #2 and replicate & transform, if you find that
works better for your deployment scenario.  You *can* use reasoning
engines to work entirely dynamically, if that works better for you.

Note that #1 *does* mandate forward-chaining.  You *cannot* use 
a reasoning engine to revise the putative-to-domain mapping once 
replication & transformation has been done.

For this simple reason, I strongly advise that we *not* combine
putative-to-domain ontology mapping into the rdb2rdf scenario --
because it makes a decision which we haven't been chartered for,
and which I believe we are perilously close to deciding in the
worst possible way.

Be seeing you,

Ted


--
A: Yes.                      http://www.guckes.net/faq/attribution.html
| Q: Are you sure?
| | A: Because it reverses the logical flow of conversation.
| | | Q: Why is top posting frowned upon?

Ted Thibodeau, Jr.           //               voice +1-781-273-0900 x32
Evangelism & Support         //        mailto:tthibodeau@openlinksw.com
                             //              http://twitter.com/TallTed
OpenLink Software, Inc.      //              http://www.openlinksw.com/
        10 Burlington Mall Road, Suite 265, Burlington MA 01803
                                 http://www.openlinksw.com/weblogs/uda/
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
                               http://www.openlinksw.com/blog/~kidehen/
    Universal Data Access and Virtual Database Technology Providers

Received on Tuesday, 27 April 2010 14:41:59 UTC