Meeting Notes 20090227 Phone meeting (Dejing, Gwen, Bob, Paea, & Haishan; 2/27/2009)

From Nemo

Jump to: navigation, search


Phone meeting (Dejing, Gwen, Haishan, Paea, & Bob… Jason, Allen NA)


Discussion of ICBO paper topic, issues

List of Issues:

  1. Design & requirements of a (hypothetical) NEMO ontology database (Paea)
    1. Ontology (either top-down or bottom-up will work in principle)
    2. Data that have been marked up using ontology concepts (e.g., spreadsheets generated from RMF's autolabeling routines, which annotate ERP data using NEMO ontology concepts and assign values for all data attributes that instantiate these concepts)
    3. Gwen [offline]: Can Paea design database initially with just the ontology in hand, PLUS an indication of which ontology concepts should be linked to fields that will be populated with data.
  2. Tradition of separating ontologies, data(bases) (Dejing) - Long history in KE of separating ontologies and databases, and this has led to specific problems. In particular, it is not possible to do automated reasoning using a traditional ontology design, which is why they need to bring in a separate inference engine (“Pellet”?) in NISFTD. The idea behind Paea's and Dejing's ontology database is precisely that it can support this kind of  reasoning over data that have been marked up using an ontology.
  3. Orthogonalization/modularization of ontologies (all) -  
    1. Dejing, Paea note that Gene Ontology (GO) has adopted this (BFO) mentality. Ontology in this case really functions as a controlled vocabulary, but with little direct support for data representation or mark-up. In GO, genes are treated as “data instances” and are annotated with ontology concepts. The annotation itself is then linked to one or more published papers. HOWEVER, this would be a serious mistake for NEMO, since published data are not very reliable sources for valid and robust uses of ERP pattern labels (ontology concepts). [That's one of the problems NEMO is intending to fix!]
    2. Note that orthogonalization is good at concept level (e.g., avoid multiple inheritance when possible)
    3. At the ontology level, it may be helpful to try to achive some orthogonality (e.g., separate OWL ontologies/namespaces for spatial, temporal, functional, and data-related, concepts). challenge then is how to link them when links need to be made….  through rules?
    4. Dejing notes that tradition in Semantic web research is to modularize with the goal of enabling more efficient reasoning. However, we need to weigh this efficiency against other considerations of use and transparency….
/wiki/images/1/17/Fish1.png /wiki/images/e/ea/Fish2.png /wiki/images/f/fa/Fish3.png /wiki/images/f/ff/Fish4.png /wiki/images/4/40/Fish5.png /wiki/images/c/c5/Fish6.png
Personal tools