but we need a common way to 
      describe our work allowing the mediation of viewpoints. As our worldviews 
      differ in scope (what we look at), resolution (detail we are looking at), 
      and structure (categorization of what we are looking at), these mediations 
      will not always be loss-free, but that is part of the nature of the 
      beast.
      It 
      seems like we are starting to come to very similar observations and reach 
      mappable conclusions in different scientific domains.
       
      Andreas
       
       
      
       
      Bravo, Rich – this is the 
      first time I’ve heard anyone in any of these ontology/SUO forums stress so 
      strongly the human-factor aspect of data semantics.   I’ve been 
      trying to argue this point for years but to most CS-trained individuals it 
      just falls on deaf ears.   I even have a nice little catchy name 
      for the theory:  “Data Is Speech”.    As you suggest, 
      there will be multiple ontologies (or whatever you want to call them) to 
      formally represent different views of the word and they will need to be 
      quickly adaptable to changing business requirements .  And the one 
      significant missing and way way underserved ingredient is mapping and 
      translation technology.  
       
      Bill
       
      
       
      Sincerely,
      Rich Cooper
      EnglishLogicKernel.com
      Rich AT EnglishLogicKernel DOT com
       
      Dave McComb wrote:
Ontologies, in my 
      mind, offer a way to help sort, categorize and organize the chaos we've 
      created.  We have to integrate the old with the new as we go forward, 
      but this isn't as hard as it sounds.  SOA has given us the general 
      technological approach, Semantics is adding a layer of rationalization on 
      top.
       
      Nicely stated - I'm still reading Karl Popper's Logic of Scientific 
      Discovery, which is a dramatic reminder of the subjectivity we brush 
      aside so easily.  Remember that the people who entered all that data 
      into the database in the first place were each individuals with their own 
      internal ontologies.  
       
      The first problem in any database, even prior to formalizing “the” 
      ontology or (more effectively, “some” ontologies) is to find ways to 
      ascertain the meaning of data recorded there.  I described that in 
      detail on my web site at:
      www.englishlogickernel.com-Patent-7-209-923-B1.PDF
       
      For example, when a Yes/No answer is mixed with 1/0, 2/1, T/F, 
      True/False, and MIXTURES of the above (yes, T/1/F/0, 2/1/0 and other 
      mixtures are possible since people are not consistent systems). 
       Attempts to force fit the answer into a very precise type of form 
      (T/nil) leads to frustrated users, GUI programming errors, confused 
      analysts and lots of data entry errors because most users don't have a 
      real stake in most systems they deal with.  
       
      For a few lucky enterprises, there may have been "the" enterprise 
      ontology by designers who thought it might be useful.  In my 
      experience, every enterprise system database evolves faster than the IT 
      staff allocated to manage it.  There is too big a loop between the 
      user with her needs and the developers who make changes.  
       
      Meaning is in the eyes of the people who provide the data, and lots of 
      that meaning is subject to human judgment, valuation diversity, and just 
      plain old personal preferences.  Then there is the meaning in the 
      perceptions of data analysts who try to make sense of the user data, or 
      find patterns there, typically not having the original users available at 
      the analyst's moment of investigation.  
       
      But between the data entry person and the analyst, there may be lots of 
      other users reading, perceiving, populating, editing, and otherwise in 
      their own eyes "adding" meaning to the data by changing the original 
      source data cells – all to meet their own individual ontologies.  So 
      the typical enterprise database is full of classes and properties that 
      shouldn't be there (given “the” ontology), but in fact they are. 
       Even worse, the variations are the main source of information in 
      businesses looking for ways to improve profit, service, quality or other 
      metrics.  The changes in data, the variations, contain the most 
      information.  
       
      Education and training of staff to enter data "the right way" is a 
      hopeful tactic, but almost a waste of time, and users mostly still do what 
      they think is good on the spur of the moment, just like the rest of us. 
       People work in our own conceptual ways, we deal with everyday 
      situations in our own lexicon, grammar and thought processes, and 
      "education" applied in that way is more appropriately called 
      "indoctrination".  It tries to “fix” the users’ dynamic flow of 
      structural information instead of adapting to that changing flow by 
      processing a changing ontology with changing projected user ontologies. 
       
       
      So the only conclusion I can reach is that "the" enterprise ontology, 
      if singular, is a dynamic and variable entity that is no more fixed than 
      any other specification to be implemented real soon now.  Forget 
      about selecting ONE, and expect multiple ontologies; the transition 
      sequencing from one to another (the periodic version update) is likely to 
      become more manageable that way.  Expect ontologies to be iterative 
      and plural, not fixed and singular.  
       
      I think every user might some day have her own ontology. 
       Localizations and personalization can be used to adapt "the" 
      ontology to a wider range of individual user needs as much as writing 
      specialized queries in SQL which takes development labor.  
       
      Surely a "semantic" application will influence the user's GUI behaviors 
      in some dynamic way.  So if "the" ontology is dynamic, then "her" 
      ontology must be getting calculated from "the" ontology either very 
      quickly or very incrementally to meet GUI performance requirements. 
       
       
      JMHO,
      -Rich