RE: LOD Constellation

Hi Mike,

> You are correct that we do not have a comprehensive inventory of 
> specific class mappings.  However, we *do* for those that involve 
> UMBEL:
> 
> http://www.umbel.org/ontology/umbel_external_ontologies_linkage.n3
> 
> As for the others shown on the LOD constellation diagram, we have 
> ascertained there *are* class-level mappings but have not yet 
> compiled the specific class-level assertions those non-UMBEL 
> sources make.  That enumeration should be done.
> 

The n3 file you provided is very very exciting, and I can't wait to see the
class-level mappings between all the ontologies used by the current LOD. You
know, in Falcons Object Search, users could navigate a universal class
hierarchy to filter results. But we are facing thousands of ontologies with
overlapped domains, and the universal class hierarchy is with semantic
redundancy, like "conference" and "conference event", although we have
applied some conservative heuristics. Such redundancy is really boring, and
that's why we're seeking ways to get rid of it.

> Class-level mappings, because of their *generalizability* and 
> *power*, need to be carefully done.  We have looked at automatic 
> and semi-automatic methods for these mappings (an important 
> personal and business focus), but in the end such class-level 
> assertions are pivotal to quality and believability.  This 
> current LOD constellation diagram is simply reporting the 
> linkages with no comment on provenance or accuracy.
> 
> My own view is that, while some alignment or mapping algorithms 
> might be helpful for screening or identification purposes, 
> actionable mappings need to be QA/QC'ed by humans with provenance 
> made clear.  Axioms and algorithms can help to identify and rank 
> candidates, but should not be determinative.
> 
> However, saying that, our own UMBEL mappings have not taken that 
> long and once made are easily reused with leverage.  IMO, it is a 
> much less onerous task to do class-level mappings than instance 
> ones.  (While a single class assignment may require more time and 
> thought than an instance one, there are fortunately many fewer 
> structural -- that is, class -- than instance relationships 
> between most datasets.)
> 
> Of further caution is that once one moves beyond specific 
> individual sameAs assertions to those involving entire classes 
> the consequences of getting it wrong are greater.
> 
> But what we are seeing is that a few class connections can bring 
> some really powerful inferencing.  Just getting a few right can 
> be really powerful. . . .

I totally agree with you. Class-level mappings are powerful. If all the
mappings are correct, it will be very helpful. But even if one mapping is
incorrect, the whole system may be destroyed (e.g., <rdfs:Resource,
rdfs:subClassOf, foaf:Person> ). And that's why we don't use any ontology
matching algorithms in Falcons. In many cases, recall is not interesting,
but precision must be 100%, which is difficult for almost all the algorithms
to provide.

We can't stop people from using different ontologies to describe the same
topic. And it seems that in future it will be often the case that multiple
ontologies about the same domain coexist. I hardly dared to hope that all
the ontology developers would explicitly state in their ontologies that
their classes are equivalent to or subclass of some classes in other
ontologies. So we need third-party algorithms/communities to solve the
problem. And your work is an exciting starting point.

Another of my suggestions is that, is it possible to set a wiki-like system
to enable everyone to participate in the matching process? A secondary
effect is that ontology developers may be interested in maintaining the wiki
pages about their own ontologies, just like currently many companies ask
employees to maintain their wikipedia pages ;)

Regards,
Gong

Received on Monday, 6 October 2008 06:41:41 UTC