W3C home > Mailing lists > Public > public-lod@w3.org > November 2010

Re: RDB to RDF & ontology terms reuse

From: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
Date: Thu, 11 Nov 2010 16:33:57 -0500
Cc: public-lod@w3.org
Message-Id: <46437BEF-425B-451C-BB29-6201B9970EA0@openlinksw.com>
To: Christian Rivas <chris.rivas.lod@gmail.com>

*** On Nov 5, 2010, at 7:54 PM, Christian Rivas <chris.rivas.lod@gmail.com> wrote:
>> > you are absolutely right but what happen if I need to reuse
>> > a ontology term that belong to a different Domain
>> > as I exemplify before?
>> >
>> > Should I map Actor with foaf:Person and vcard:VCard and
>> > dbpedia:Actor classes?

** On Wed, Nov 10, 2010 at 12:06 AM, Ted Thibodeau Jr <tthibodeau@openlinksw.com> wrote:
>> Sure! There are no rules anywhere that say you can or should only use one ontology -- and in fact this is why there's the whole xmlns rigmarole.
>> If you do have one ontology that does everything you need, great -- that can lower confusion for people and minimize server requests when dereferencing those terms. But if you don't? Cherry-pick the terms that make the most sense from however many ontologies you need.
>> RDF was made for sparse data -- and it can handle everything you've laid out here.

* On Nov 9, 2010, at 09:37 PM, Christian Rivas wrote:
> Thanks, for your considerations.
> But If I map the class Actor with foaf:Person, vcard:VCard and dbpedia:Actor classes (certainly handle by RDF),
> as following
> <http://www.example.com#actor_1> <rdf:type> <dbpedia:Actor> .
> <http://www.example.com#actor_1> <rdf:type> <foaf:Person> .
> <http://www.example.com#actor_1> <rdf:type> <vcard:VCard> .
> An actor could be a foaf:Person but an vcard:VCard, what about consistency and inference?

Consistency and inference are indeed things to be considered, but
they come into play at a later point, it seems to me.

You would not want to say that an Actor, a Person, was also a VCard.  
I was not considering the actual rdf:types you were suggesting in 
your earlier question, because it seemed that you were more concerned 
about whether you could or should mix classes from several ontologies 
(i.e., foaf:x with dbpedia:y and vcard:z) in a single description.

But, what if you *did* say that an Actor was a VCard?

First, you get (or create) a data set, a named graph.

*Then,* you evaluate that data -- is it internally consistent?  
Does it match up well with other, trusted sources?

If not -- then corrections are needed, to one source or another,
and perhaps you assign different weights of trust -- the source
that only says a dbpedia:Actor is a foaf:Person gets more trust,
is treated as better provenance, than the source that says that
same dbpedia:Actor (or indeed, *any* foaf:Person) is a vcard:VCard.

The vcard:VCard class is disjoint from the other two.  Any source 
that says an entity is a member of two disjoint classes cannot be 
(fully) trusted until that is changed.

Keeping data in Named Graphs makes it easier to drop the untrustable 
pieces from the data you query against -- or to exclude some graphs
(which say People are CCards) from queries where that matters, but
keep them when the *good* data within those same graphs are useful
and correct, like the parts that say --

   { Actor:Fred :role Shakespeare:Romeo_Montague ; 
                :role Lucas:Anakin_Skywalker 

-- and the like).

Be seeing you,


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
OpenLink Blogs              http://www.openlinksw.com/weblogs/virtuoso/
    Universal Data Access and Virtual Database Technology Providers
Received on Thursday, 11 November 2010 21:34:28 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:29:51 UTC