The MOMIS FAQ

 $Id: faq.txt,v 1.111 2004/01/21 11:20:46 corni Exp $

• this file should be written in English
• this file must be written in accordin to the Faq format (see below) and line must be less than 80 characters width.
  
• You are encouraged to use this file to write significant documentation about the technical developement of the Momis prototype.
  

   ---- nome categoria

   -- nome sotto categoria

   q.

   a.

 testo preformattato.

   parseFaq

   parseFaq faq.txt > faq.html

 0note.txt               files 0note.txt describes directorys content
 build.properties (5k)   a "make" related file
 build.xml (28k)         the main "make" file
 setVars.sh (275b)       for tests, to initialize the CLASSPATH
 ./CVS [2]               data for the "CVS - Concurrent Versions System"   
 ./bin [1]
   byaccj_1.8_j0.92_modificato.tgz (96k)  sources for the yacc used in MOMIS
   compileJavaCC.sh (146b)                a compilation Script
   cvsUpdate.sh (104b)
   ./bin/win32 [2]
     byacc.exe (100k)
 ./classes [1]           momis compiled code
 ./conf [1]              default configurations and config examples
   corbaExample_full_m2.conf (1k)
   momis.conf (1k)
   siDesigner.conf (1k)
   Torque.properties (4k) Torque (jdbc) configuration for accessing WordNet
   ./conf/declarationsIDL [2]     Corba (IDL) MOMIS declarations
   ./conf/declarationsWSDL [2]    WebServices (WSDL) MOMIS declarations
   ./conf/samplesIdl [2]          Corba configuration examples
   ./conf/samplesWrapperCore [2]  Wrappers configuration examples
   ./conf/samplesWsdl [2]         WebServices configuration examples
   ./conf/schema [2]              Wordnet relational schema in XML
 ./doc [1]               Momis documentation direcgtory
   0note.txt (80b)
   faq.txt (88k)         This faq file
   parseFaq (16k)        A script to convert the faq.txt to Html
   ./doc/api [2]         MOMIS apis generated by "ant doc"
   ./doc/guides [2]      Other various documents in faq format
     multiWordnet.txt (7k)
     webServices.txt (30k)
 ./images [1]            Images files used in Gui programs (SiDesigner)
 ./lib [1]               Libraries used by MOMIS
 ./samples [1]           Variuos integration samples (may be out-of-date)
   stato.xml (48k)       reference example (this should be never outOfDate)
 ./src [1]               MOMIS source code directory
   odli3.y (108k)        the ODL_i3 language parser for byacc
   OntologyManagerClient_parser.jj (9k) a Wordnet client language for JavaCC
   oql.y (49k)           the OQL_i3 language parser for byacc (not used)
   ./src/it [2]          the MOMIS Package root dir
   ./src/sql [2]         Torque generated SQL for WordNet
 ./templates [1]         Torque templates
 ./trash [1]             Useless temporary files
 ./var [1]               Autogenerated files (that varies over the time)
                         convention on file name prefix in the var dir:
                          run      require a user interaction
                          start    starts a serve daemon
                          build    script used in compilation

 cd /export/home/progetti.comuni/Momis/prototypeNew
 source 0setVars
 var/runSiDesigner.sh

• ant init: use this command joust after the CVS check out to initialize the whole momis.
  This will perform the following operations
  • script generation in the directory $dmt/vars
  • generates the ODLi3 parser java code form the Yacc form
  • builds the corba stub and skeleton from the IDL files
  • builds the SQL and Java code for the Object Relational Mapping implemented by Torque
  • compiles the whole source code
• ant doc:
  generates the javadoc documentation in the dir

     $dmt/doc/api
  

• ant clean:
  cleans all the previously generated classes
• ant scripts:
  generates every scripts to start SiDesigner and related modules in the dir

     $dmt/var
  

• ant project:
  generates the interfaces to connect to momis wordnet database
• ant -projecthelp shows all the ant possible parameters
• ant [compile]:
  whith no further parameters, compiles all the project

• joust after one update it is good to recompile the whole momis code, here are the commands:
  

     cd $dmt
     ant init
  

• check out

     cvs co momis
  

• update

     cd $dmt
     cvs upd -P -d  2> /dev/null | sort | awk '{printf("cvs ci -m \"%s-\" %s\n", $1, $2); }' > updatedfiles.txt
  

  otherwise use the commands

     cd $dmt
     cvs upd -P -d  | sort | less
  

• add: add a file in the repository

     cvs add filename
  

• remove: remove a file from the repository

     rm filename
     cvs rm filename
  

• commit:
  make permanent the local modifications in the repository.
  Modifications are:
  
  • files added are really added to the repository
  • files removed are really removed from the repository
  • files modified are really modified in the last version in the repository.
    
  Run it:
  

     cvs ci fileName
  

  for a whole directory (and sub directories):
  

     cvs ci directoryName
     cvs ci .
  

• To tag the current Momis version

     cvs tag momis-0-3-final .
  

• used in the "c:/bin" directory extracts the given tagged version of Momis

     cvs checkout -r momis-0-3-final momis
  

 $dmt/bin/cvsUpdate.sh

 $dmt/updatedfiles.txt

 cvs ci -m "?-" vmtemplates/schemaXml_localClasses.vm_orig
 cvs ci -m "?-" ws.wsdd
 cvs ci -m "M-" src/it/unimo/dbgroup/momis/SIDesigner/SIM/MetodiSim.java
 cvs ci -m "M-" src/it/unimo/dbgroup/momis/SIDesigner/SIM/SIM.java

 "?-"  the file exists on you Computer but does not exists
       in the CVS repository
 "M-"  the file exists in the repository and you modified it on
       your computer

 U FILE
  The file was brought up to date with respect to the repository.
  This is done for any file that exists in the repository but not in
  your source, and for files that you haven't changed but are not
  the most recent versions available in the repository.
 P FILE
  Like `U', but the CVS server sends a patch instead of an entire
  file.  These two things accomplish the same thing.
 A FILE
  The file has been added to your private copy of the sources, and
  will be added to the source repository when you run `commit' on
  the file.  This is a reminder to you that the file needs to be
  committed.
 R FILE
  The file has been removed from your private copy of the sources,
  and will be removed from the source repository when you run
  `commit' on the file.  This is a reminder to you that the file
  needs to be committed.
 M FILE
  The file is modified in  your  working  directory.
  `M' can indicate one of two states for a file you're working on:
  either there were no modifications to the same file in the
  repository, so that your file remains as you last saw it; or there
  were modifications in the repository as well as in your copy, but
  they were merged successfully, without conflict, in your working
  directory.
  CVS will print some messages if it merges your work, and a backup
  copy of your working file (as it looked before you ran `update')
  will be made.  The exact name of that file is printed while
  `update' runs.
 C FILE
  A conflict was detected while trying to merge your changes to FILE
  with changes from the source repository.  FILE (the copy in your
  working directory) is now the result of attempting to merge the
  two revisions; an unmodified copy of your file is also in your
  working directory, with the name `.#FILE.REVISION' where REVISION
  is the revision that your modified file started from.  Resolve the
  conflict as described in *Note Conflicts example::.  (Note that
  some systems automatically purge files that begin with `.#' if
  they have not been accessed for a few days.  If you intend to keep
  a copy of your original file, it is a very good idea to rename
  it.)  Under VMS, the file name starts with `__' rather than `.#'.
 ? FILE
  FILE is in your working directory, but does not correspond to
  anything in the source repository, and is not in the list of files
  for CVS to ignore (see the description of the `-I' option, and
  *note cvsignore::).

• a CVS client that supports SSH (I use the cvs distributed in cygwin),
• byacc che generi codice java
• una versione dell'ambiente di sviluppo composto da tdk, jsdk1.4, ant per compilare i sorgenti.
  

• Occorre settare due variabili di sistema usate da CVS (consiglio di mettere questi comandi nel file di startup della shell):
  

      # CVS
      export CVSROOT=:ext:username@sparc20.ing.unimo.it:/export/home/cvs/repository
      export CVS_RSH=ssh
  

• andare nella dir in cui si vuole installare l'ambiente di sviluppo.
  Per le macchine windows e' sempre

      c:/bin
  

  Eseguire il comando per il checkout (download) dei sorgenti

      cvs co momis
  

• terminato il checkout occorre eseguire la prima compilazione.
  Andare nella dir

      momis
  

  ed eseguire il comando

      ant init
  

   ant doc

 conf/schema/id-table-schema.xml
 conf/schema/momiswn-schema.xml

 <!DOCTYPE database SYSTEM "file://c:/bin/momis/schema/database.dtd">

 setenv JAVA_HOME /usr/local/j2sdk1.4.0
 setenv PATH "$JAVA_HOME/bin:$PATH"
 ant scripts; chmod +x var/*.sh
 ant init           # will produce several compilation errors
 cp $JAVA_HOME/jre/lib/rt.jar  lib
 ant

 conf/samplesWrapperCore/

• to run a wrapper Dummy open and take a look to the file

     conf/samplesWrapperCore/samplesWrapperDummyFromFile/stato.conf
  

  and run the rapper inside the command line client:
  

     var/runWrapperClient.bat \
      conf/samplesWrapperCore/samplesWrapperDummyFromFile/stato.conf
  

  the only command allowed will be

     \dx
  

• to run a jdbc wrapper from the client open and take a look to the file

     conf/samplesWrapperCore/samplesWrapperJdbc/mySql.conf
  

  edit parameters such as

     driver to load
     uri where to connect
     username
     password
  

  according to the jdbc source you want connect to.
  Then run the rapper inside the command line client:
  

     var/runWrapperClient.bat \
      conf/samplesWrapperCore/samplesWrapperJdbc/mySql.conf
  

  This is an example useful to test JDBC wrapper connections or new wrapper implementation (if any).
  

• Create a System DSN ODBC data source according to the kind of data source you have (Access, Excel, for example).
  
• Set all the required parameters for your sources (username, pwd, if any).
  
• Now you can run SiDesigner (var/runSidesigner.bat for win system).
  
• Set the Global Schema name.
  
• Set the name for the new source you want to wrap.
  
• Select the JDBC Wrapper from the list:

     it.unimo.dbgroup.momis.communication.core.jdbc.WrapperJdbcCore
  

• Set the following parameters:
  

          
       WrapperJdbcCore.DriverClassName=sun.jdbc.odbc.JdbcOdbcDriver
       WrapperJdbcCore.Url=jdbc:odbc:dataSourceNameDefined
       WrapperJdbcCore.User=userNameDefined
       WrapperJdbcCore.Password=pwdDefined
       WrapperJdbcCore.debug=true
  

• Select "new source" to wrap your source.
  

• Copy these JDBC driver files for SQLServer (mbase.jar, mssqlserver.jar, msutil.jar) in the dir "momis\lib" of your local version.
  The specified files can be found on sparc in this dir:
  

     progetti.comuni\progetti\SEWASIE\OntologyBuilder\DriverJDBC_for_MSSQLServer
  

• Now it is necessary to run "ant scripts" from your develop dir to update the classpath.
  
• Now you can run SiDesigner (var/runSidesigner.bat for win system).
  
• Set the Global Schema name.
  
• Set the name for the new source you want to wrap.
  
• Select the JDBC Wrapper from the list:

     it.unimo.dbgroup.momis.communication.core.jdbc.WrapperJdbcCore
  

• Set the following parameters:
  

          
       WrapperJdbcCore.DriverClassName=com.microsoft.jdbc.sqlserver.SQLServerDriver
       WrapperJdbcCore.Url=jdbc:microsoft:sqlserver://ComputerAddress:1433;DatabaseName=SQLServerDataBaseName;User=UtenteSQLServer;Password=PWDSQLServer
       WrapperJdbcCore.User=SQLServerUser
       WrapperJdbcCore.Password=PwdSQLServer
       WrapperJdbcCore.debug=true
  

• Select "new source" to wrap your source.
  

• obtain the last sources from the CVS repository
• compile everything

     ant init
  

• run the orb

     var/startOrb.bat
  

• crate a configuration file, for an oracle example see

      conf/samplesIdl/wrapperJdbcOracle.conf
  

  that is a well commented example.
  #### IMPORTANT NOTE ####.
  To use the oracle jdbc driver you need the jar file NOT distributed in the MOMIS CVS code.
  
  • To add a JDBC driver in MOMIS, simply copy the jar file in the directory

          the/Momis/Root/Dir/lib
    

    for example

         cp /somewhere/oracle_classes12.jar lib/
    

    and rebuild the .bat scripts using the command

         ant scripts
    

  • If you use a different DBMS please change the

         WrapperJdbcCore.DriverClassName
         WrapperJdbcCore.Url
         WrapperJdbcCore.User
         WrapperJdbcCore.Password
    

    parameters according to your needs.
    
• run the CORBA demon that will run the wrapper type:
  use the command

     var/startWrapperCorba.bat conf/samplesIdl/wrapperJdbcOracle.conf
  

  that's all!
  
• run a wrapper client.
  It is important to test the wrapper.
  We provide a comman line tool to do this for ANY wrapper.
  To work the WrapperClient needs a configuration file where are described which Wrapper load and the parameters for the wrapper itself.
  An example of configuration file for connecting to the previous corba wrapper is (READ IT!)

     conf/wrapperJdbcOracle_client.conf
  

  To run the client type

     var/runWrapperClient.bat conf/samplesIdl/wrapperJdbcOracle_client.conf
  

  How use the WrapperClient:
  
  • type \h to get a short help.
    For example use the command

         \dx
    

    to get the schema description in xml, or

         select  something from someTable;
    

    to test the quering capabilities.
    For example, if the jdbc db contains the Ditta table, try

         select * from ditta
    

• install an environment with a working tomcat
• install a working axis package
• copy the directory content

     $dmt/classes
  

  into the axis dir

     ....webapps/axis/WEB-INF/classes
  

• configure the velocity macro enviroment in axis
  • copy the library

         velocity*.jar
    

    into

         ....webapps/axis/WEB-INF/lib
    

  • copy (or link) the directory

         $dmt/vmtemplates
    

    into the tomcat execution directory or tomcat, usually

         .../tomcat/bin
    

• make sure the "connection" (e.g. jdbc drivers) are in the axis directory

     ....webapps/axis/WEB-INF/lib
  

 var/runAxisAdminClient.bat conf/samplesWsdl/dummy/wrapper.wsdd

• translator ODLi3->OLCD:
  

     /export/home/progetti.comuni/prototipo/bin/odl_trasl schemaName
  

• SLIM works using both JDBC wordnet connection and the files
• The SLIM interface is integrated with the wordnet editor ingterface to allow the designer to quickly extend wordnet
• In the future will be possible to export the new (extended) synset and relation used in the schema annotation in the XML describing the source.
  

• install the MySql server.
  Note for Linux users of MySql 4.0: for security reason, the skip-networking options is active. Please, change the /etc/mysql/my.cnf file commenting out the option like this:
  

     #skip-networking
  

  This way you will be able to connect to the database.
  
• put the mysql/bin dir is in the path
• modify the $dmt/build.properties line as follow

     database = mysql
  

• compile the sql code using

     ant project
  

• modify the $dmt/conf/Torque.proporties e $dmt/conf/siDesigner.conf lines as follow:
  

     torque.database.default.driver=org.gjt.mm.mysql.Driver
     torque.database.default.url=jdbc:mysql://localhost:3306/momiswn
     torque.database.default.username=momiswn
     torque.database.default.password=momis
     torque.database.MOMIS.driver=org.gjt.mm.mysql.Driver
     torque.database.MOMIS.url=jdbc:mysql://localhost:3306/momiswn
     torque.database.MOMIS.username=momiswn
     torque.database.MOMIS.password=momis
  

• be sure the mysql daemon is running
• create the database:
  

     mysqladmin create momiswn
  

• create the user:
  connect to the mysql system database

     mysql mysql
  

  and execute the following instructions (copy and paste them)

     INSERT INTO user ( Host, User ) VALUES ( 'localhost', 'momiswn' );
     #
     UPDATE user SET 
       Select_priv     = 'Y',
       Insert_priv     = 'Y',
       Update_priv     = 'Y',
       Delete_priv     = 'Y',
       Create_priv     = 'N',
       Drop_priv       = 'N',
       Reload_priv     = 'N',
       Shutdown_priv   = 'N',
       Process_priv    = 'N',
       File_priv       = 'N',
       Grant_priv      = 'N',
       References_priv = 'N',
       Index_priv      = 'N',
       Alter_priv      = 'N'
     WHERE user='momiswn';
     #
     UPDATE user SET Password=PASSWORD('momis') WHERE user='momiswn';
     #
     INSERT INTO db ( 
        Host,
        Db,
        User,
        Select_priv,
        Insert_priv, 
        Update_priv,
        Delete_priv,
        Create_priv,
        Drop_priv,
        Grant_priv,
        References_priv,
        Index_priv,
        Alter_priv
     ) VALUES (
        'localhost',
        'momiswn',
        'momiswn',
        'Y',
        'Y',
        'Y',
        'Y',
        'Y',
        'Y',
        'Y',
        'Y',
        'Y',
        'Y'
     );
     #
     #
     FLUSH PRIVILEGES;
  

• create the db schema:
  

     cd $dmt/src/sql
     mysql momiswn < momiswn-schema.sql
  

• create a user (described above)
• save locally the dump of the momiswn database. A dump can be created by accessing the sparc20 with the command

     ssh <username>@dbgroup.unimo.it 
  

  and then running:
  

     mysqldump -u momiswn -p --opt momiswn > momiswn.dump
  

• restore the dump with the following command:
  

     mysql -u root momiswn < momiswn.dump
  

 for windows:     c:\wn16
 for unix:        /usr/local/wordnet1.6/

 var/runSiDesigner.bat   (or var/runSiDesigner.sh)

 -DWNHOME=../wn

 java -DWNHOME=../wn it.unimo.dbgroup.momis.SIDesigner.SI_Designer ...

• qui-[to change]

 c:/wn16

  java -DWNHOME=theFullPathToWordnet it.unimo.dbgroup.momis.SIDe...

 theFullPathToWordnet

 select LENGTH(DESCRIPTION)
   from WN_RELATIONSHIP_TYPE
 order by LENGTH(DESCRIPTION) desc;

 $dmt/conf/declarationsWSDL/

 $dms/wsdl

   @echo off
   rem
   rem  starts siDesigner GUI tool  with PreChooser 
   rem
   set PATH=%PATH%;.\\lib\\windows
   set CLASSPATH=...findThisUsing: . setvars; echo $CLASSPATH
   rem echo %CLASSPATH%
   rem echo .
   java it.unimo.dbgroup.momis.SIDesigner.PreChooser %1

 javaws.cfg.logToFile=true
 javaws.cfg.logFileName=pathLogFileName/logFileName

 and must begin with unterscore.
 Example
  private HashMap _relTargetMap = new HashMap();

 -- tag    -- since version
 @author       1.0
 {@docRoot}    1.3
 @deprecated   1.0
 @exception    1.0
 {@inheritDoc} 1.4
 {@link}       1.2
 {@linkplain}  1.4
 @param        1.0
 @return       1.0
 @see          1.0
 @serial       1.2
 @serialData   1.2
 @serialField  1.2
 @since        1.1
 @throws       1.2
 {@value}      1.4
 @version      1.0

 j2sdkDir/doc/docs/tooldocs/windows/javadoc.html

• use the "Criteria" object to build database queries to be as independent as possible from the db.
  
• Write such database queries in the Peer objects
• If possible do non use Peer object static methods outside the ..om (object model) package.
  

 M-x compile

 ant -emacs -f c:/bin/momis/build.xml

  orbd  e  servertool

• wrappers are designed to be as modular as possible, at least for the Java developers.
  Basically a wrapper is something that allows a (java) client to access to a source so a Wrapper can be described with a simple (Java) interface

      it.unimo.dbgroup.momis.communication.Wrapper
  

  with the following methods:
  

      public String getDescription() throws WrapperException;
      public String getDescriptionXml() throws WrapperException;
      public String getSourceName() throws WrapperException;
      public String getType () throws WrapperException;
      public WrapperRS runQuery (String oql) throws WrapperException;
      public void close() throws WrapperException;
  

  most of them are intuitive, for more information look at the source code.
  The method runQuery makes exception since returns an object of type

      it.unimo.dbgroup.momis.communication.WrapperRS
  

  that is a Wrapper Result Set and defines the methods:
  

      void    close() throws WrapperException;
      long    getColumnByName(String column) throws WrapperException;
      long    getColumnCount() throws WrapperException;
      String  getColumnName(int column) throws WrapperException;
      char    getChar(int column) throws WrapperException;
      double  getDouble(int column) throws WrapperException;
      float   getFloat(int column) throws WrapperException;
      long    getLong(int column) throws WrapperException;
      String  getString(int column) throws WrapperException;
      String  getRSAsString() throws WrapperException ;
      boolean next() throws WrapperException;  
  

  Names are intuitive too.
  Here is implemented the concept of "cursor", so there are method to "close" the cursor, move to the "next" record or get the current record information (getString, getFloat, etc.) or access to the record metadata information (getColumnByName, getColumnCount).
  

• the interfaces Wrapper and WrapperRS are all we need to access a source INDEPENDENTLY from the type of source.
  The only thing the client need to know is:
  
  • the interfaces Wrapper and WrapperRS
  • the class that implements the wrapper
  • the parameters to let the wrapper working
  The idea is to make the Client as much INDEPENDENT as possible from the used wrapper, so we tried to standardize also the way to pass specific parameters.
  This is through the interface

     it.unimo.dbgroup.momis.communication.WrapperCore
  

  that extends the interface Wrapper adding the methods

      public void   initialize(Map parameters) throws Exception;
      public String getParamersAsPropertiesTemplate();
  

  All wrappers implementing the WrapperCore interface have the same initialization interface!
  Parameters are passed through a java.util.Map object that must contain a set of couple (key, value) where the key is a String, the name of the parameter and value is the value of the parameter specific for the instance initialization.
  Every Wrapper implementation must be initialized passing a set of specific parameters.
  String parameters in a Map can be represented in the "Properties" form. java.util.Properties is a core java tool class used to store/retrieve application configuration parameters.
  A couple (key, value) can be represented in a plain text file (or string) writing a couple per line

     key=value
  

  like the following example:
  

      #
      # Time out in seconds
      timeOutGracePeriod=28800
      timeOutCheckPeriod=3600
  

  lines starting with # are ignored. Are simply comments.
  See next section for more examples.
  

• These are few examples of wrapper the Momis Client (such as SI-Designer) will instance to access data sources.
  
  • the Dummy wrapper:
    This is not a real wrapper.
    The only thing this wrapper can do is read a schema description from a given xml file and pass it to the client when the getDescriptionXml() is invoked. The class to be instanced is

         it.unimo.dbgroup.momis.communication.core.dummy.WrapperDummyFromFile
    

    This wrapper requires the following parameter

         WrapperDummyFromFile.sourceDescriptionFileName=samples/file.xml
    

  • the Jdbc wrapper:
    This is the wrapper for accessing JDBC data source.
    Opens a JDBC Connection using standard JDBC features.
    The wrapper simply translates requests from the Wrapper interface into JDBC throuth the open connection.
    The class to be instanced is

         it.unimo.dbgroup.momis.communication.core.jdbc.WrapperJdbcCore
    

    This wrapper requires the following parameter

         WrapperJdbcCore.DriverClassName=oracle.jdbc.driver.OracleDriver
         WrapperJdbcCore.Url=jdbc:oracle:thin:user/pwd@artemi...
         WrapperJdbcCore.User=user
         WrapperJdbcCore.Password=pwd
         WrapperJdbcCore.debug=true
    

  • the corba client wrapper This is the wrapper for accessing standard CORBA data source that implements the idl interface

         conf/declarationsIDL/CorbaWrapper.idl
    

    The CorbaWrapper.idl defines the same methods of the Java Wrapper interface but is for the CORBA standard.
    Opens a CORBA connection with a remote CORBA server.
    The wrapper simply translates requests from the Wrapper interface into CORBA requests sent to the given CORBA server.
    The class to be instanced is

         it.unimo.dbgroup.momis.communication.client.corba.CorbaWrapperClient
    

    This wrapper requires the following parameter

         # Where runs the "orb-naming server"
         namingServerName=localhost
         # At which port responds the "orb-naming server"
         namingServerPort=1050
         # Name to use to register "this" corba wrapper
         wrapper_serverName=oracleSource
    

  • the Web Services client wrapper This is the wrapper for accessing standard WebServices data source that implements the wsdl interfaces:
    

         conf/declarationsWSDL/WSDLWrapper.wsdl
         conf/declarationsWSDL/WSDLWrapperRS.wsdl
    

    The WSDLWrapper.wsdl defines the same methods of the Java Wrapper interface while WSDLWrapperRS describes the methods for the ResultSet object compliant with the WebService standard.
    Both such wsdl interfaces are "invisible" to the user.
    The wrapper simply translates requests from the Wrapper interface into WS requests sent to the given WS server.
    The class to be instanced is

         sam.wrapperClassName.5=it.unimo.dbgroup.momis.communication.client.wsdl.WSDLWrapperClient
    

    This wrapper requires the following parameter

         # endpoing of the wrapper web service to be connected
         endpointURL=localhost
    

• The idea is to implement servers that translates source data requests from a standard comunication protocol (such as CORBA, WebServices, or other) implementing such servers that translates the communication protocol requests into the Wrapper interface requests.
  Now we can publish in a standard communication protocol any "Source specific wrappers" making any possible combination.
  examples
  • the corba server/client communication wrapper and the idl interface for external interfacement (client for input, server for output).
    The CORBA communications wrapper server defines CORBA object server that implements the idl interface

         declarationsIDL/CorbaWrapper.idl
    

    The server accepts requests through the CORBA protocol and translate them into Wrapper interface requests.
    To be as fexible possible also this server uses parameters, one of required parameters is the name of the Source specific wrappers to use.
    Here are the required parameters

         # Where runs the "orb-naming server"
         namingServerName=localhost
         # At which port responds the "orb-naming server"
         namingServerPort=1050
         # Name to use to register "this" corba wrapper
         wrapper_serverName=oracleSource
         # These parameters are for Query pre-emption
         # a query object is killed after a time(out) of inactivity
         timeOutGracePeriod=28800
         timeOutCheckPeriod=3600
         # the Source specific wrappers to use
         wrapper_coreClass=it.unimo.dbgroup.momis.communication.core.jdbc.WrapperJdbcCore
    

    Usually in the configuration file there are the parameter for the "Source specific wrappers to use" initialization.
    In this case

         WrapperJdbcCore.DriverClassName=oracle.jdbc.driver.OracleDriver
         WrapperJdbcCore.Url=jdbc:oracle:thin:user/pwd@artemi...
         WrapperJdbcCore.User=user
         WrapperJdbcCore.Password=pwd
         WrapperJdbcCore.debug=true
    

  • the WebServices server/client communication wrapper and the WSDL interface for external interfacement (client for input, server for output) This is not implemented yet..
    
  NOTA
  • The communications wrapper server used with the corresponding communications wrapper client simply works as communication bridge between any Source specific wrappers and a remote client since "source" data are taken from the source specific core wrapper through the interface Wrapper used by the "communications wrapper server" and are provided to the client again through the interface Wrapper by the communications wrapper client.
    

• From the Java developement poin of view we can see a Wrapper as an object that implements the

      it.unimo.dbgroup.momis.communication.Wrapper
  

  interface.
  As first step You should read the well commented source code of such interface.
  Such interface is used by Client to access a data source.
  Actually real Wrappers must be initialized specifing parameters for accessing the data source (usually a username, password or host name).
  For this reason it exists the interface

      it.unimo.dbgroup.momis.communication.WrapperCore
  

  that inherits from the Wrapper interface and adds two method specific for wrapper initialization.
  Note that a Wrapper is really composed by two parts:
  the one supports the Wrapper interface and is the object representing the source.
  The second part implements the

      it.unimo.dbgroup.momis.communication.WrapperRS
  

  (that means Wrapper Result Set) and is the code that manages the queries to the Source.

• A wrapper is basically able to perform 2 tasks
  • 1. the source introspection.
    This describes the source "schema" in a MOMIS way, using both ODLi3 or an XML description.
    Nowaday (January 2003) the XML is better because is able to carry more information like the schema annotation or support attribute names with spaces or other strange characters.
  • 2. the source quering (WrapperRs).
    The wrapper (by the interface WrapperRS) enables a client to access data through a Result Set, that data resulting from a query are accessible as cursor on a table.
    Operation allowed are to get the numeber of selected columns, get value of a given column and move the cursor on the next row of the table.
    

• at first look at some examples.
  To start look at the

     it.unimo.dbgroup.momis.communication.core.dummy.WrapperDummyFromFile
  

  that is not a real wrapper, the only thing this wrapper can do is read a schema from a file and pass such description to the client.
  Next look at the

     it.unimo.dbgroup.momis.communication.core.jdbc.WrapperJdbcCore_metaData
  

  where are solved both the source introspection and the source quering problems.
  
• An exremely simple wrapper:
  here are describe the main wrapper code and code implemented to run queries
  • The WrapperDummyFromFile wrapper.
    This implements the interface WrapperCore.
    As you can see from the code most of method does nothin, returns null value or returns hard coded values (e.g. the getSourceName() method ever returns "dummySource").
    
• A real wrapper:
  here are describe the main wrapper code and code implemented to run queries
  • The WrapperJdbcCore wrapper.
    A WrapperJdbcCore simply opens a JDBC connection on the source and use such connection to get Schema Description or run queries (SQL) on the source.
    The connection is opened during the initialization() expecting the parameters

           WrapperJdbcCore.DriverClassName=oracle.jdbc.driver.OracleDriver
           WrapperJdbcCore.Url=jdbc:oracle:thin:user/passwd@artemide.ing....
           WrapperJdbcCore.User=user
           WrapperJdbcCore.Password=pwd
    

    - The source schema introspection:
    

          WrapperJdbcCore retrieves metadata from the JDBC connection
          create a new odli3.Schema object
          and fills it with odli3.Interfaces (the Tables) object.
          Every odli3.Interface object is then "filled" with
          odli3.SimpleAttribute object that are the fields of the
          corresponding table.
          Since for schema exists both the method to get the 
          xml and ODLi3 representation of the in memory odli3.Schema
          object,
          this is the recommended way to do get a source description.
          This allows the programmer to write a single code that
          loads well known data classes (the method getSchema())
          and the two methods getDescription and getDescriptionXML
          are really small (less than 20 lines).
    

  • The WrapperRSJdbcCore class.
    This implements the interface WrapperRS.
    The first thing to do is to see the source code.
    The constructor simply retrieve ask the connection to the jdbcWrapper, create a new Statement and runs the given query as SQL query on the JDBC source.
    The main source of informatio object of the WrapperRSJdbcCore is now the ResultSet resulting from the SQL query.
    Getting data is a trivial mapping of the WraperRS interface methods to such resultset methods.
    For example, see the method

         public String getString(int column) throws WrapperException
    

    that simply calls the getString ResultSet method

         rv = _rs.getString(column);
    

• invocation example

     var/runClientAnnotationOntology.bat conf/siDesigner.conf
     var/runClientAnnotationOntology.bat conf/siDesigner.conf < in.txt
  

  see the syntax examples in the directory

     samples/clientAnnotationOntology
  

• technical notes:
  Since the Mapping Table task is next, I had to test and get practice with Java Parser Generators from grammar (such as yacc) that are not byacc.
  So I choose to make the ontology interface a script interpreter with variables and a few other concepts.
  The grammar was written from scratch using

     JavaCC  https://javacc.dev.net/
  

  - note on JavaCC.
  

      This is now an official Sun project.
      As of June 2003, JavaCC is open source.
      The source code can be found at java.net.
  

  - compilation with javaCC.
  

      From emacs You can use
       bash c:/bin/momis/bin/compileJavaCC.sh
  

• Examples:
  
  • managing variables and expressions

         echo -e 'a=c.test("aa");print a;exit;' | var/runClientAnnotationOntology.bat conf/Torque.properties
         echo -e 'a=o.getLemma("home", scName);print a.getLemma(); vars;exit;' | var/runClientAnnotationOntology.bat conf/Torque.properties
         a=o.getLemma("home");
    

 it.unimo.dbgroup.momis.odli3.mappingTable

• MappingElementDefault:
  there is a default mapping that is, the global attribute has a constant value.
  
• MappingElementComposedAnd extends MappingElementComposed:
  implements the "and" mapping.
  the attribute is mapped, on the same local interface, in a set of local attributes.
  In case of string the AND can have the mening of "string concatenation".
  
• MappingElementComposedUnion extends MappingElementComposed:
  implements the "union" mapping.
  the attribute is mapped, on the same local interface, in a set of local attributes.
  

 it.unimo.dbgroup.momis.SIDesigner.joinMap.JoinMapPanel

 private Vector makeJoinMap(java.lang.String gcName){
    Vector rv = new Vector(0);
    Vector locClasses=getLocCl(gcName);
    int cont = 0;
    LocalClass[] sc1=null;
    sc1=new LocalClass[locClasses.size()];
    LocalClass[] sc2=null;
    sc2=new LocalClass[locClasses.size()];  
    String out="";
    for( int i=0; i<locClasses.size(); i++){
       sc1[i] = (LocalClass)locClasses.get(i);
       for( int j=cont; j<locClasses.size(); j++){
          sc2[j] = (LocalClass)locClasses.get(j);
          if (sc1[i]==sc2[j]) continue;
          SourceClass s1=new SourceClass(sc1[i].source,sc1[i].name);
          SourceClass s2=new SourceClass(sc2[j].source,sc2[j].name);
          JoinMap jm;
          jm=new JoinMap(s1,s2);
          System.out.println(jm.firstElement.name
                             +" "+jm.secondElement.name);
          rv.add(jm);
       }                                                
       cont++;
    }
    return rv;
 }

 WHY, WHY USE at least TWO CLASSES FOR THE SAME INFORMATION?

 getSourceClass(fullName)

 -- odli3 class ---+-- xml name-------------------
 StructType
 UnionType
 EnumType
 InterfaceType      <TypeInterface name="Person" />
 AnyType            <TypeAny />
 BooleanType        <TypeBoolean />
 CharType           <TypeChar />
 DateType           <TypeDate />
 TimestampType      <TypeTimestamp />
 FloatingType       <TypeFloating />
 DoubleType         <TypeDouble />
 IntegerType        <TypeInteger />
 OctetType          <TypeOctet />
 RangeType          <TypeRange min="inf" max="333" />
 StringType         <TypeString length="20" />
 - template types -
 ArraySequence      <TypeArraySequence>...</TypeArraySequence>
 BagType            <TypeBag><TypeInteger /></TypeBag>
 ListType           <TypeList><TypeInteger /></TypeList>
 SetType            <TypeSet><TypeInteger /><TypeSet>

• Domenico, Daniele Miselli, Alain, Roberta, Luca Ghetti, Alberto Corni, Francesco Guerra

• documento di riferimento SEWASIE:
  esiste un documento su sparc20 (elis2004)
  • le sole query che siamo tenuti ad implementare sono QUERY CONGIUNTIVE.
    
  • ipotesi:
    
    • traduciamo UN UNICO PREDICATO ALLA VOLTA anche se questa non e' la scelta ottima.
      
• punto sul QM
  • interrogazioni:
    
    • e' una forma congiuntiva fatta su una singola classe globale.
      
  • tutto il parsing e il trattamento delle query viene fatta all'interno del QM di Luca Ghetti.
    
  • OdlI3 si prende carico di effettuare la riscrittura degli atomic statements.
    Il linguaggio usato e' OQLi3.
    Non si prevede la riscrittura de statements specifici per il tipo di sorgente. Questo e' demandato al Wrapper.
    Esempio:
    
    • il Like.
      Oql usa il "%" come wildchar, mentre alcuni dbms usano l'"*".
      La traduzione del "%" in "*" dev'essere fatto dal wrapper e non dal QM.
      
    • interrogazioni di sorgenti XML.
      Ora NON e' stato ancora affrontato, ma occorrera' scrivere wrapper che trasformano le query OQL in (per esempio) XML-Query.
      
  • discussione degli esempi dall'articolo di

          Chen-Chuan K.Chang e  Garcia Molina  
    

    - si usano regole di traduzione

          si possono optare 2 strade
          - traduzione per ogni tipo di "tipo di dato"
          - traduzione ad hoc per ogni singolo attributo globali
    

  • passaggio delle informazioni da QueryManager (Luca) alle classi che si preoccupano del GlobalToLocal mapping.
    Un oggetto:
    

         constructor:
          Localizer(Statement globalAttributesStatement, Source sorgente)
         methods:
          getLocalizedTree()
          boolean getFull()
    

    Gli statements sono quelli del package

         it.unimo.dbgroup.momis.odli3.functions.statements
    

    Le variabili de AlberoConGlobalAttributes devono essere scritte nel package

         it.unimo.dbgroup.momis.odli3.functions.queryManagerInterface
    

    devono usare la classe

         StatementVariableGet_QMGlobal extends Statement
    

    che contiene:
    
    • GlobalAttribute globalAttribute
    • Map locaAttributesNames

• Sonia, Maurizio, Francesco, Alain, Alberto

• momis non funzionava alla demo a Karls Suhe
• Anna Tavernari ha avuto problemi a importare sorgenti Excel
• il "main", alla fine degli attributeName non e' chiaro.
  La prima istanza NON deve avere come estensione il nome dell'intBody.
  
• il sw NON e' stabile.
  
• Sandro Bernardino, si dovrebbe verificare che OdbTool funziona sotto Win2000.
  
• Il gruppo di sviluppo dovrebbe preparare un test script e procedure sull'interfaccia grafica.
  
• Maurizio dovrebbe preparare titoli di tesi Nod e Vod.
  

• Analisi della struttura esistente tra XML, immagine UML, codice
• Analisi della nuova struttura delle MappingTable
  • Spiegazione detagliata delle IntBody
  • Assunzione nel caso relazionare una Interface contiene solo una IntBody. Questo e' garantito dal SiDesigner e garantisce il vincolo di avere un nome unico di un campo in una tabella.
    
  • Analisi del MappingElement e analisi delle funzioni da applicare agli attributi locali e globali (da concludere)
• Analisi della JoinMap valutazione delle funzioni (da fare)
• Analisi della struttura di rappresentazione delle funzioni (da estesa per passare le funzioni a wrapper)
• Analisi sulla scelta di implementazione funzionale, con la versione attualmente proposta si eliminerebbero le ottimizzazioni semantiche attualmente in funzione sul QM per cui si e' pensata una strada per risolvere il problema e continuare ad implementare questo modello funzionale.
  
  • Def: funzioni interpretabili da altri sorgenti:
    data una funzione f : A --> B questa e' eseguibile su di un sorgente remoto se e solo se nel sorgente remoto vi e' definita la stessa funzione f : A1 --> B1 e se A1 contiene oppure e' uguale
  Nota: la funzione identita' e' sempre un sottoinsieme di questa.
  
• Da sviluppare tecnicamente per implementare questo tipo di funzioni occorre definire un meccanismo di mappatura delle funzioni per poterle passare ai wrapper. Nota: e' importante che il QM sappia quali condizioni della clausola where vengono eseguite sui wrapper. Da fare un meccanismo di generazione della sintassi della funzione.
  

• ritengo l'esercizio attualmente inutile, penso che chi ha definito la struttura OQL abbia fatto un buon lavoro ed attualmente quella parte di codice e' stato utilizzato, stabilizzato, esteso, inoltre ritengo importante procedere il pił rapidamente possibile con l'implementazione delle "funzioni" secondo l'analisi di cui sopra, questo permetterebbe di ottenere un QM con le stesse funzioni di ottimizzazioni attualmente presenti. Riscrivere OQL comporterebbe una frattura del progetto nel momento in cui si sta cercando di allineare i vari componenti, inoltre questo sposterebbe i tempi di realizzazione del progetto, penso che in questa fase sia importante concentrarsi sull'aspetto funzionale delle MappingTable.
  

• general
  • attribute e' scritto in odli3 con una doppia "t" ("atribute" e' dovrebbe essere sbagliato)
• Join Map:
  Non e' compliant con il nuovo approccio.
  Nel nuovo approccio il Join viene fatto localmente.
  L'interfaccia alle JoinMap e' data dalle classi stesse:
  

     GlobalJoinAttribute
     GlobalJoinAttributeDefinition
  

• Funzioni:
  
  • perche' le funzioni le hai chiamate

         TreeRoot
    

    Io ho il concetto di Statement, una cosa "eseguibile"
• Manca un'informazione:
  chi deve implementare quale interface
• Interface List
  • Oql_GlobalSchema.java:
    
  • Oql_GlobalClass.java:
    Come gestisci l'ereditarieta'?
    Gli attributi ereditati, ti interessano?
    
  • Oql_GlobalAttribute.java:
    cosa significa il metodo

         boolean isFunction()
    

  • Oql_LocalAttribute.java:
    
  • Oql_LocalClass.java:
    
  • Oql_TreeRoot.java:
    cosa significa il metodo

         boolean isLocal()
    

    perche' l'esecuzione l'hai chiamata

         exegue
    

    anziche' "execute" o "exec"?
    Nota:
    Le MappingFunction sono "precompilate", distinguo tra le fasi
    • di parsing e checking della funzione (compileTime)
    • e la fase di esecuzione (runRime)
    i controlli sono eseguiti a compileTime esiste il concetto di stack (sia a runtime che a compiletime) e il tutto e' posizionale (rispetto allo stack) per evitare Lookup all'interno di hashmap che ritarderebbero l'esecuzione della funzione.
    Ho una proposta su come risolvere gli attributi globali a partire dagli attributi locali materializzati su una tabella JDBC, dobbiamo parlarne
  • JoinMap:
    Vecchio concetto. Ora odli3 NON ragiona piu' cosi'.
    
    • Oql_JoinMap.java
    • Oql_JoinMapRelation.java

• Partecipanti

     Bergamaschi, Beneventano, Vincini, Guerra, Corni,
     Fergnani, Miselli, Gelati,
     Luca Ghetti
  

• Sewasie o Momis?
  Sewasie richiede l'interazione con Roma per cui occorre usare il motore di Lenzerini per riscrivere le query da Global a Local.
  Momis invece NON dispone del motore di Roma quindi dovrebbe essere sviluppato in Modena.
  Scelta:
  

     MOMIS, roma/sewasie e' meno importante
  

• Gestione delle IsA e ForeignKeys per le classi Globali.
  
• La decisione e' Svincolarsi da SQLServer.
  Serve uno strumento che permetta di implementare il FullOuterJoin e in futuro gli algoritmi relativi alle JoinTable (in via di studio).
  Opzioni:
  
  • Liberia dei Tedeschi (??)
  • (solo Alberto sostiene) Hypersonic
• Funzioni associative...
  Se ne e' parlato ma non saprei dov'e' che le funzioni devono essere associative.
  
• IMPORTANTE: occorre fare chiarezza nelle teoria sulle JoinMap.
  

• schema x roma
  • descritto in xml l'esempio di Kostantin
  • occorre fare la versione x roma
• Come fare il Join in mancanza di JoinMap:
  si usa comunque il natural outer join e quindi si ottiene il prodotto cartesiano di tutte le tuple.
  

• 1 the mapping from local attributes to the global attribute
• 2 the "reverse mapping" from the global attribute to the local attributes

• The mapping is natural to be expressed with a function that returns a single value for the global attribute and and has as parameteres alla local attributes the global attributes maps on.
  
• The reverse mapping is not trivial.
  The problem is to map the where clause of a global query into the more restrictive possible query on the local sources.
  The "reverse mapping" or "query rewriting" depends at least by the localInterface and the kind of operator the statement is based on (equals statemente: nome = "corni", gt statement: eta > 21, like statement, nome likes "Co%Al%").
  

• In case of identity (one global attributes maps on only one local attribute per local interface) is quite simple. It is enough to sobstitute the name of the "global attribute" with the name of the local one. It is not necessary modify anything else.
  
• In case of not identity we must define a mapping template that states how produce the local where clause for each local interface and operator.
  

  .
  source    | university        |   department  |  |   GLOBAL |
  ----------+-------------------+---------------+  +----------+
  interface | person            |   student     |  |   person |
  ----------+--------+----------+---------------+  +----------+
  attribute | name   |lastName  |   studentName |  |   name   |
  ----------+--------+----------+---------------+  +----------+
            |        |          |               |  |          |
            |        |          |               |  |          |
            |Alberto |Corni     | Corni Alberto |  |  -----   |
            |        |          |               |  |          |
  .

  GLOBAL.person.name = 
     f(university.person.name
       , university.person.lastName
       , department.student.studentName
      ) {
        name = department.student.studentName;
        if (name == null) {
          if (university.person.lastName != null) {
            name = university.person.lastName;
            if (university.person.name != null) {
              name = name + " " + university.person.name;
            }
          } else {
            name = university.person.name;
          }
        }
        return(name);
      }

 department.student.studentName

 select * from person where name = "Alberto Corni"

 name = "Alberto Corni"

 [select ... where ... ] student.studentName = "Alberto Corni"

 {
  s = 'person.name + " " + person.lastName = "$GLOBAL.person.name'
  return s;
 }

 {
  # perl like regular expression statement
  (name,separator,lastName) = 
    split($GLOBAL.person.name, "(.*[ \t\n]*.*)");
  s = 'person.name = "$name" and person.lastName = "$lastName"
       or person.name = "$lastName" and person.lastName = "$name"';
  return s;
 }

 "Francesco De Gregori"
 "Carlo Alberto Conti"

 # Francesco De Gregori
 person.name = "Francesco" and person.lastName = "De Gregori"
 or person.name = "Francesco De" and person.lastName = "Gregori"
 # De Francesco Gregori
 or person.name = "De" and person.lastName = "Francesco Gregori"
 or person.name = "De Francesco" and person.lastName = "Gregori"
 # De Gregori Francesco 
 ...
 # Francesco Gregori De
 ...

• fare andare il demone CORBA per si-designer
• E' inutile memorizzare lo schema di partenza per ogni oggetto odl-i3.
  Questo rende molto meno flessibile le operazioni di scambio/copia di informazioni tra schemi.
  E' meglio tenere traccia del "parent container" per i tipi piu' importanti:
  

      - Interfaces
      - Modules
      - StructType
      - UnionType
      - TypeDef
      - Rule
      ...
  

• E' inutile memorizzare il producer per ogni oggetto dell'odl-i3.
  Memorizzo il producer solo per lo schema.
  
• sistemare i xxxxTypeToSolve
• sistemare i tipi UNION che non discriminano le info in fase di parsing.
  Effettivamente e' piuttosto complessa la gestione delle union.
  Scelgo di rimandare la gestione a piu' avanti.
  
• sistemata la gestione degli errori
• gestione del parent container sui tipi:
  

      - Costant
      - DefinedType
      - StructType
      - EnumType
      - UnionType
      - Interface
      - Module
      - Rule
      - ThesRelation
  

• risolvere le EXTRules
• Attenzione
  • le foreign keys vanno risolte DOPO aver "risolto" gli attributi di tutte le interfaces.
    
  • Nella rappresentazione toOdl gli attribuiti di una interface non vanno presi dalla map "attributes" ma vanno stampati partendo dalle IntBodies.
    
• sistemare le Interfaces
  • sistemare controlli
    • creazione hashmap di vector degli attributi per nome
    • coerenza delle chiavi
    • coerenza delle foreign keys
    • consistenza degli attributi
  • Sistemare IntBody come TypeContainer
• implementazione di parte delle funzionalita' toOdl
• [19-09-2002 Al] preparare esempio per roma Sistemare il TimeOutManager
• [Sept 2002] Query Manager
  • Studiare come descrivere le Join map.
    Carartteristiche volute:
    
    • semplicita' di espressione
    • estendibilita' con nuovi algoritmi di join.
      example: outer join, equal join, axproximate join, semantic join

 sistemare la compilazione sulla sun
 [Dic 2002]

  - non importa correttamente il validated

  - remove  the method
     WrapperRS.getColumnType(int columnNumber)
    we assume that who performs a query
    can get all information through the getDescription (schema)
    method.
  - use the DatabaseMetaData object to get column description.
    Was created the object
     it.unimo.dbgroup.momis.communication.core.jdbc.WrapperJdbcCore_metaData

   oracle_classes12.jar
  per 2 motivi:
  - 1 non e' freeware, i diritti sono della Oracle
  - 2 occupa tanto spazio sul repository.

• WordNet Editor
  • aggiungere i commenti agli oggetti nei packages

          om, wnEditor
    

  • mWNbase:
    Spostare il main in una classe di wnEditor.
    Main parametrico per il caricamento del database e la creazione del reverse index.
    
  • Editor
    • panel Lemma (lemmi relativi ad un synset).
      

             Insert a new synonym:
      

      mettere il campo di testo a destra del bottone
  • add/view relations ad un synset:
    aggiungere un bottone che porta
  • Search gloss:
    
    • i lemmi devono essere caricati dal renderer.
      Ogni riga deve essere associato ad un oggetto synset

         (la classe GlossEntry deve essere abbandonata)
    

    - sostiuire il ";" con lo spazio e

          per ora non usare il "\" come escape char
    

  • sort di un Vector:
    

         Comparator c = WnRelationshipPeer.getComparatorOn_type();
         Object a[] = wnRelationships.toArray();
         Arrays.sort(a, c);
         rv = a;
    

  • query

         select s.gloss, s1.gloss, r.wn_relationship_type_id
           from wn_relationship r, wn_synset s, wn_synset s1
          where s.gloss like '%2-wheeled motor vehicle%'
            and s.wn_synset_id = r.wn_source_synset_id
            and s1.wn_synset_id = r.wn_target_synset_id
    

  • gestione del "WnSynset selectedWnSynset":
    il pannello "lemma" e la parte sx delle relazioni dovranno "pescare" i dati da tale oggetto.
    
• porting de
  • wrappers
  • modulo slim (Interfaccia a Wordnet)

     - gestione:
       - intoduzione della "provenienza" del dato.
         un tipo definitio by typedef sa dove e' stato definito
         (interface o module).
       - primo passo 
           le strutture vengono caricate in memoria
           senza controlli (e senza assegnare il campo provenienza).
         secondo passo 
           sistemare i campi "provenienza" e 
  

• [] other
• Note sul parser odli3.
  

     [Maggio 2000] Revisione del parser e strutture ODL_i3
                   by Alberto Corni.
  

  - ATTUALE gestione dei tipi

      - tipi condivisi da tutte le sorgenti di uno schema
  

  - IDEALE gestione dei tipi.
  

      Vorrei che i tipi fossero gestiti "ricosivamente" tenendo
      conto dei moduli, in questo modo:
       - una sorgente e' un modulo
         - per ogni modulo mantenere:
           -- informazioni:
           - la lista dei moduli
         - lista delle interface
         - lista dei tipi definiti
           -- metodi:
         - getType(String name)    trova un tipo dato un identificatore
         - Per ogni INTERFACE
           -- informazioni:
         - modulo in cui e' contenuta
           - lista degli attributi
         - lista delle relazioni
         - lista dei tipi definiti nell'interface
  

  - MODIFICHE:
  

      - Gestione dei tipi tramite "TypeContainer"
      - Trascurata la gestione dei "templateTypes"
        in quanto si tratta di tipi come gli altri.
      - Introdotta una fase di post-processing per la risoluzione
        de:
          - DefinedType
          - StructType
          - EnumType
          - UnionType
        Questi tipi sono referenziati in ODL-i3 da identificatori.
        Per fare cio' ho introdotto una serie di nuovi tipi:
          - DefinedTypeToSolve
          - StructTypeToSolve
          - EnumTypeToSolve
          - UnionTypeToSolve
        che ereditano da SimpleType.  Di fatto sono dei tipi
        temporaneamante non risolti che prevedono tutte le funzioni dei
        tipi risolti contengono anche un puntatore al tipo "risolto" e
        tutte i metodi invocati su questi oggetti vengono ridiretti al
        tipo "risolto".  Per risolvere i nomi in ogni TypeContainer tengo
        la lista dei tipi da risolvere che risolvero' solo alla fine del
        parsing.
  

• type (odli3.Type) handling and wrapper:
  
  • types exported by wrappers must map on the odli3 types this already works
  Ha senso esportare solo questi tipi?
  

     /* 
      * ResutSet TYPE.
      */
     /* Unsupported Type */
     const long TYPE_Unsupported  = -1; 
     /* Long Type */
     const long TYPE_Long   = 1;
     /* Char Type */
     const long TYPE_Char   = 2;
     /* Double Type */
     const long TYPE_Double = 3;
     /* Float Type */
     const long TYPE_Float  = 4;
     /* String Type */
     const long TYPE_String = 5;
  

• implementazione funzioni toOlcd
  • traduzione degli attributes filtrando i nomi lunghi (utilizzare la classe TranslationMap)
  • traduzione delle rules

• Creazione dell'oggetto SLIM:
  Quando SLIM viene istanziato viene chiamata la funzione

     initComponenets()
  

  All'interno di questa funzione vengono creati gli oggetti SlimTree e ThesaurusTable.
  
• Creazione dell'oggetto SlimTree:
  (Qui iniziano i primi problemini...) Le funzioni che vengono chiamate all'interno del costruttore di SlimTree sono (in ordine):
  
  • loadCacheAndProxy():
    carica i file di cache pensati da Malvezzi (che quindi funzionano solamente con la versione vecchia e non estensibile di SLIM)
  • creaAlbero():
    crea l'oggetto JTree che visualizza l'albero, ma non ne istanzia il modello (solamente il renderer)
  • setDataFromSchema():
    (funzione da rivedere) Questa funzione legge l'oggetto Schema e crea il modello dell'albero JTree. Per ogni interfaccia ed attributo viene creato un oggetto SlimNode e passato al costruttore di un oggetto DefaultMutableTreeNode ed aggiunto all'albero (tramite SlimNode.getAdditionalInfo() vengono recuperati i sensi dell'annotazione salvati sull'XML).
    Dopo aver fatto cio', come ultima cosa, viene chiamata la funzione di SlimTree

         preLoadSignificati()
    

    Tale funzione chiama, per ogni SlimNode creato nell'albero, la funzione di SlimNode setMeanings(). Quindi vengono subito caricati in memoria tutti i significati di tutti i nodi.
    
• L'Oggetto SlimNode
  • Crezione (Constructors):
    la creazione di un nuovo oggetto SlimNode e' possibile in due modi differenti:
    
    • partendo da un nuovo nodo vuoto (caso in cui una sorgente viene importata in MOMIS per la primav olta)
    • oppure copiando i settagli (namePath, formaBase ed il vettore Sensi) da uno SlimNode creato a partire dal parser XML (se si carica uno stato salvato)
    ATTENZIONE!!!: Se il nuovo nodo SlimNode viene creato a partire dalle informazioni salvate in uno stato XML le operazioni che vengono fatte sono le seguenti (chiamo SN1 il nodo da creare e SN2 il nodo creato dal parser a partire dall'XML):
    
    • SN1.namePath = SN2.namePath
    • SN1.formaBase = SN2.formaBase
    • Se il vettore dei sensi annotati (un vettore di int) non e' vuoto viene chiamata la funzione di SlimNode setMeanings().
      
    Per gli SlimNode la cui annotazione e' stata quindi salvata sull'XML i significati vengono caricati 2 volte tramite la funzione setMeanings() chiamata nel costruttore di SlimNode e da SlimTree nella funzione preLoadSignificati().
    
  • Funzione addSenso():
    (comportamento discutibile) la funzione addSenso di SlimNode viene chiamata ogni volta che si aggiunge un senso (tramite l'annotazione o quando lo SlimNode viene creato a partire dal parser XML).
    Tale funzione non si limita a controllare se il senso e' gia contenuto nei vettori di SlimNode ed ad aggiungerlo, ma chiama la funzione

         trovaParenti()
    

    (ebbene si'...) di SlimTree.
    La funzione trovaParenti() cerca i 'fratelli' e le 'sorelle' del synset selezionato (Malvezzi li ha chiamati cosi', io non ho colpe...).
    I fratelli di un synset sono quelli che hanno almeno tre lemmi collegati uguali (di cui uno e' quello della formaBase dello SlimNode di partenza).
    Le sorelle di un synset sono quelle che hanno almeno un lemma in comune (la forma base dello SlimNode di partenza) e lo stesso ipernimo.
    Al fine della annotazione i significati parenti vengono considerati uguali. Infatti se si aggiunge un senso ad un SlimNode si cercano anche i suoi parenti e vengono aggiunti al vettore dei significati selezionati anch'essi. (Non so se questa sia una funzione utile o meno, ma sicuramente rallenta un bel po' il caricamento dei significati di SLIM).
    
• CONSIDERAZIONI
  • E' effettivamente necessario cercare i parenti di un senso selezionato e considerarli equivalenti??
  • La struttura di SlimNode potrebbe essere semplificata (una grossa semplificazione potrebbe essere permettere solamente la selezione di un senso per volta durante l'annotazione). Una semplificazione enorme sarebbe portare il significato dell'annotazione sulle interfacce ed attributi ODLi3.
    
  • SlimNode andrebbe per lo meno commentato, ci sono diverse funzioni e variabili che, nonostante io ci abbia lavorato diverse volte, fatico tuttora a comprendere.
    
  • Mi sto convincendo sempre di piu' che sarebbe meglio (direi piu' performante) non caricare tutti i significati all'inizio e tutte le volte che si accede al pannello di SLIM (poiche' ricordiamo che anche l'update() di SLIM implica la ricarica dei significati...). Inoltre per creare il thesaurus, fine ultimo di slim, importano solamente i significati selezionati, non tutti quelli possibili (la performance della creazione del thesaurus dovrebbe rimanere praticamente invariata).
    
  • Controllando mi sono accorto che, in caso siano stati selezionati piu' sensi per uno stesso slimNode, l'algoritmo di creazione del thesaurus dovrebbe utilizzarli tutti, almeno cosi' mi pare.
    Il come, non si sa.
    

• New GlobalClasses.
  These extends the "local classes" In such a way whe inherits the concepts of
  • inheritance among classes
  • foreign keys
  To convert old schema.xml files for the new format, use the following converter:
  
• how to convert a old xml momis file into the new xml format. Use the command:
  

     var/runParser.bat -inXmlOld -outXml oldFileName.xml 
  

  The "new" file is on the standard Output, so do this:
  

     var/runParser.bat -inXmlOld -outXml oldFileName.xml > newFileName.xml
  

  If you are in trouble try this:
  

     var/runParser.bat -debug -inXmlOld -outXml oldFileName.xml 
  

• note on the xml schema
  • renamed

         GlobalVirtualView   in   GlobalView
    

• bugFix: <Jonathan Gelati MSN> Ciao.
  Ho riscontato il seguente problema: quando tiro su un result set di una query e lo trasformo in xml, ne caso di valore null di un attributo, viene riportato nel xml il valore dell'attriubto precedente. Potresti verificare se e' cosi' anche da te?
  
  • The DataSet tool package now supports the Null value!
    
• in SimpleAttribute.
  Verify if are useful the fields

      _fixArraySize - yes. It is managed also in the xml representation
      unknownType
  

• il metodo "control" nella classe odli3.TemplateType non recupera il tipo del tipo della "collection" partendo dal nome.
  questo implica che:
  

     I tipi set, list, bag sono tipi di dati 
     riconosiuti da MOMIS ma trattati in maniera non soddisfacente
  

  This "control" problem should not apply to the xml parser from version 0.4.
  

• Ontology abstraction.
  
  • new XML format:
    Con Daniele stiamo cambiando il modo di descrivere le annotazioni.
    Il nouvo formalismo e' il seguente:
    

           <Interface
              name="CS_Person"
              persistent="false"
              >
              <Extent name="CS_Persons" />
              <Key name="PrimaryKey" >
                <KeyAttribute name="first_name" />
                <KeyAttribute name="last_name" />
              </Key>
                   <Annotation>
                    <AnnotationValue
                      lemmaValue="person"
                      lemmaSyntacticCategory="1"
                      lemmaSenseNumber="1"
                      />
                   </Annotation>
                 ....
    

    purtroppo NON e' compatibile con il passato

              <InterfaceAdditionalInfo>
                <SlimNode formaBase="location" >
                  <SlimNodeSense number="-2" />
                  <SlimNodeSense number="1" />
                </SlimNode>
    

    Sto per fare il commit su cvs della nuova versione che usa il nuovo formalismo.
    Per poter usare i vecchi esempi esiste lo strumento di conversione esempio:
    

         var/runParser.bat -inXmlV0.4.0 -outXml samples/stato.xml
    

    genera su stdout il nuovo formalismo per il file

         samples/stato.xml
    

• design a modular, extensible sw package for managing annotation with respect of wordnet.
  

• will replace the
  • wordNetManager package
  • and MWordNetManager class
• allows to access WordNet (by now Read-Only)
• allows several way to access wordnet.
  At present
  • using the wn file distribution
  • using the Momis jdbc/Torque relational version of Wn
• manage cache of data for performance improvement

• the package is

     annotationOntology
  

  contains
  • all code that implements the Momis interface to the ontology.
    The internal Momis code will use such objects to access to WordNet.
    
  • contains the superclass that gives the basic methods to access to the Ontology data.
    Moreover contains sub-packages that override such class implementing the real code for accessing to the ontology (eg. through files or database).
    

• Mapping tables.
  
• Use of the Si-designer through the JavaWebStart (Sandro Bernardini)

• new SLIM (Daniele)
  • rewrite SlimNode
  • modify few part of the slimTree
  • add the needed methods to the OntologyManager
    • OntologyManager
    • corresponding OntologyManagerCache
    • the Inteface OntologyManagerImplementation
    • all corresponding OntologyManagerImplementation
• odli3 (Alberto)
  • modify Attributes and Interfaces in such a way them implements the Interface

          OntologyAnnotableElement
    

  • modify parser to accept annotation by:
    

         lemmaName
         syntacticCategory
         senseNumber
    

• altro
  • Write a command line tool to access momiswn.
    
  • togliere il parametro torqueConfFileName dal costruttore di WordNetEditorPanel
  • Aggiungere nell'annotazione la SyntactiC Category
  • WordNet files:
    modify the parameter

         java -DWNHOME=theFullPathToWordnet it.unimo.dbgroup.momis.SIDe...
    

    and put the parameter

         wordNetFilesPath=theFullPathToWordnet
    

    in
  • Ontolotgy abstraction
    • create the package

             it.unimo.dbgroup.momis.ontology
      

    • in the package

             it.unimo.dbgroup.momis.ontology
      

      create

             interface       OntAnnotableElement
             abstract class  OntManager
             package         data
      

    • in the package

             it.unimo.dbgroup.momis.ontology.data
      

      create:
      

             class OntSynset
             class OntExtender
             class OntRelatinship
             class OntRelatinshipType
             class OntLemma
             class OntLemmaSynset
      

    • the class

             OntAnnotableElement
      

      must have following methods grouped by
    • the class

             OntManager
      

      must have following methods grouped by

             public void cacheReset();
             public OntLemmaSysnet getOntLemmaSysnet(String lemmaValue
                                                     , int SyntacticCategory
                                                     , int lemmaSenseNumber);
             public OntSysnet getOntSynset(OntLemmaSysnet ontLemmaSysnet);
             public OntLemma  getOntLemma(OntLemmaSysnet ontLemmaSysnet);
             public OntLemma  getOntLemma(String lemma
                                          , int SyntacticCategory);
      

• Mapping tables.
  
  • classes have been re-designed, so the XML is no more compliant (so we changed the version)
  • the parser for the functions of localToGlobal mapping and globalToLocal rewriting templates
• vedere "IBM Enterprise Information Integration Software":
  see the document

     200311_ibmIntegration.txt
  

• odli3 classes, changes in dottedName dump and interpretation: Since the Attributes can be part of semistrucurated interfaces/sources we need a way to distinguish the IntBody the Attribute belongs to.
  We choosed this way, an attribute's dotted notation will be represented as:
  

     sourceName.interfaceName.attributeName.interfaceBodyName
  

  By default, the name of the main interfaceBodyName should be

     main
  

  Interested method will be

     Attribute.getDottedName()
     Schema.getObject()
  
  

• implement the Join Map
  • Implement the classes

         GlobalJoinAttribute
         GlobalJoinAttributeDefinition
    

    and XML serialization/parser.
    The parser for the function (that is expressed as a String) will be the same of the MappingFunction.
    It changes the way the Variables are initialized since are added to the stack (both runtime and compileTime) only the attributes of the single LocalInterface.
    
• Various
  • rename the method:
    

          Interface.getAttributesIncludingParentsAttributes
    

    to

          Interface.getAttributeVectorsIncludingParents?
    

• QM implementation
  • introduction of column type in the WrapperRS implementation.
    

         public String getColumnType(int column) throws WrapperException;
    

    The type is represented as a STRING that is the XML representation of the type obtained by the following method:
    

         odli3Type.getXmlType()
    

    - change all core wrapper to produce the given strings
    • change CORBA and WebService wrapper transporters to handle such new method
    • write a method that, given such string instanciate the right odli3 Type class.
      This will be

             Type.getTypeFromXmlString(String typeXml)
      

    • it could be nice to create a package

             $dms/odli3/tools/typeConversion/odli3_jdbc
      

      for conversion among wrappers and jdbc.
      But this takes time and I have not it.

• Wordnet
  • clean the code from the old SLIM implementation
  • make it multilingual
  • import the Wordnet2.0 into the TorqueDB
• Wrappers:
  
  • implements attribute name identified by the IntBody name
• The annotationOntology Package Guide
• Design and implement the new "Tunim" module.
  
• Schema Viewer (Daniele Miselli) (see details below)
• Develop the theory on the Join Maps and Write the join map editor module JOMA.
  
• Discuss the OLDi3 objects handling.
  

 Type
   TypeToSolve
   ValueType
     ConstrType (structured types)
       EnumType
       StructType
       UnionType
     SimpleType
       BaseType
         AnyType
         BooleanType
         CharType
         DateType
         FloatingType
         IntegerType
         OctetType
         RangeType
         StringType
       DefinedType (new type defined by the odli3 "type" operator NOT SUPP.)
       TemplateType  (collection types)
         ArraySequence
         BagType
         ListType
         SetType

• New Join table
• Query manager (see details below)
• Source handling (odli3.Source):
  resolve these flexibility problems
  • Allow a user to completely remove a source!
    
  • Allow a user to reload a source schema.
    Changes on the new schema must be handled!
    

• interfaccia SI-Designer:
  
  • sistemare la GUI Source Acquisition Module in modo che la combo box sia ridimensionabile.
    
  .
  Resource:
  
  • Lo priority task. Alberto 1 day or someone that knows Java graphical interfaces.
    

• Wrappers - verify if implement the RMI connection.
  Nowaday the communication is working over CORBA and WebServices that are non-java standars (it is better!).
  
• verificare se sistemare la gestione delle "struct" ora non accetta (e credo che vada bene cosi') definizioni del tipo:
  

     attribute abc struct str1 {
        int campo1;
        int campo2;
       };
     attribute def struct str1;
  

  Si potrebbe esetenderla alla "c" ma credo che non sia utile un avanzato supporto per le struct che servono a rappresentare informazioni meglio rappresentabili come Interfaces.
  
• verificare se fare il Tuning della funzione toOdl (non funziona in tutti i casi)
• parser odli3: gestione delle espressioni/costanti Per ora credo che non vi sia bisogno di risolvere le espressioni...
  (array, liste, etc sono convertite in olcd come

     set e non sono riconosciute dal query manager.
  

  ) Quindi tutte le costanti che appaiono nelle espressioni sono considerate VALIDE con valore 0.
  
• verificare se sistemare i tipi UNION che non discriminano le info in fase di parsing.
  Effettivamente e' piuttosto complessa la gestione delle union.
  Scelgo di rimandare la gestione a piu' avanti se necessaria.
  
• Wrappers: tuning of WrapperJdbcCore_metaData_oracle:
  establish rules to filter source table from system tables.
  .
  Resource:
  
  • Someone with Oracle knowledge.
    The momis knowledge is preferred but non necessary since the code to write is really trivial.
    
  • Extimated time: depends on the oracle knowledge, may vary from 1 day (the time to write the rules) to several days (the time to discover the right rules).
    

• if in a LOCAL SOURCE we have a source declaration like this:
  

     <Interface name="Professor" > ... </interface>
     <Interface name="Test" > 
       ...
       <Attribute name="prof" >
         <AttributeType> <TypeInterface name="Professor" /></AttributeType>
       </Attribute>
       ...
     </interface>
  

  How can we access the fields of the professor referenced by the "Test" field?
  The problem is that nowadays the wrappers does not supports the object reference (supports only simple plain ANSI-sql queries)!
  That is that such OO construct is not supported at all.
  
• if in a GLOBAL VIRTUAL VIEW we have a source declaration like this:
  

     <GlobalInterface name="Professor" > ... </interface>
     <GlobalInterface name="Test" > 
       ...
       <GlobalAttribute name="prof" >
         <AttributeType> <TypeInterface name="Professor" /></AttributeType>
       </Attribute>
       ...
     </interface>
  

  How can we access the fields of the professor referenced by the "Test" field?
  At run time we could design our QueryManger to link to the Professor view. We sould only define the behavior of the link!
  I expect that the field

      test.prof
  

  really carries the object identifier of the related Professor row or at least, carries the value of the key that identifies such a row.
  

• Interfaccia Grafica (SourceVisualizationTool)
  • Where to put the Visualization information <InterfaceAdditionalInfo>

          <SlimNode formaBase="research_staff" >
            <SlimNodeSenso numero="1" />
          </SlimNode>
          <SourceVisualizationTool posx="133" posy="144" widht="" height=""/>
    

    </InterfaceAdditionalInfo>
  • Momis additional Info _momisObjectAdditionalInfo

           .putAdditionalInfo(SlimTree.SLIMKEY_NodeTag, _slimNode);
    

  • Per fare testing:
    
    • creati un package

             it.unimo.dbgroup.momis.SIDesigner.SourceVisualizationTool
      

      e la classe

             SourceVisualizationTool
      

      che e' il "panel" che visualizza esclusivamente gli oggetti grafici senza il "tree" sulla sinistra.
      Il "pannello" di SiDesigner si chiamera'

             SourceVisualizationToolPanel
      

    • Come esempio guarda Artemis it.unimo.dbgroup.momis.SIDesigner.ARTEMIS

 - Il tool esistente si trova in 
    /export/home/progetti.comuni/prototipo/java
   per provarlo:
    appletviewer tmp_vf_file.html
   mi raccomando NON usarlo!

• Study and implement techniques for lemma disambinguation from the context.
  
• Extension reconciliation
  • portabilita' dell'annotazione, lo stesso nuovo significato annotato su due client diversi dovra', per quanto possibile, essere riconosciuto come "lo stesso significato" dal server che confronta le annotazioni (gestione con indici di similarita' e soglia delle annotazioni).
    
  We need:
  
  • define (in the previous points) an xml data format to carry the extension knowledge
  • Export of the new (extended) synset and relation used in the schema annotation in the XML describing the source.
    
  • study algorithms and techniques to map meanings from at least two different extensions.
    
• Wordnet:
  
  • Support for multi wordnet instance (one for language) and (like in euroWordnet) relation among Synsets and Lemmas in the various languages
• Multi Wordnet
  • Study
  • Try to load a database with only the italian terms
  • in the future, extend the db to support multiple languages at the same time

• I do not want to estimate it

• uso del naming dei packages (it.unimo....)
• uso di CVS
• (technical) come fare il parser OQL.
  Il parser deve porer eseguire sia l'analisi sintattica che semantica della query.
• (technical/teory) discutere come scrivre interfaccie sw e data structure da adottare per la fase di ottimizzazione.
  Sono d'accordo, una cosa che volevo proporti e' di considerare separate le esigenze tra SiDesiner e QM, dato il GS il QM puo' trasformare la struttura del GS per generarsene uno ottimizzato per le sue esigenze; questa operazione verrebbe eseguita allo startup del QM in modo che a runtime l'operazione sia attiva.
  
• Altra cosa su cui mi piacerebbe omogeneizzare le cose e' sulla gestione dei Logs.
  
• sostituire il DBMS con un motore di Join (XLL) proprietario.
  Per ora, valutare Hypersonic.
  
• (technical) documentazione
• occorre fare l'integrazione con i sorgenti di MOMIS.
  E' l'occasione per
  • verificare cosa e' stato fatto e come e' stato fatto
  • pianificare il da farsi
• come procedere:
  
  • secondo me (Alberto) occorre spendere (credo, circa) 5gg uomo per spulciare il codice di Luca Ghetti e integrarlo nel codice "ufficiale" di Momis.
    
  • Potrebbe essere l'occasione per coinvolgere altre persone nello sviluppo del prototipo con l'obbiettivo principale di un trasferimento (sharing) di Know How.
    I candidati sono (oltre ad Alberto):
    
    • Miselli:
      e' da valutare il modo in cui programma.
      Di fatto gia' conosce e ha modificato i sorgenti di Momis relativi al modulo Slim. Significa che gia' conosce il 60% delle cose da sapere sul prototipo.
      
    • Francesco, se lo ritiene opportuno:
      conosce gia' l'architettura e le problematiche del prototipo oltre al fatto che ne e' il responsabile per la parte di "intgrazione".
      
    • Sandro:
      
• Il ruolo di Luca Ghetti.
  Nel periodo di integrazione Luca Ghetti NON dovra' fare modifiche al codice.
  Dovra' invece essere a disposizione per eventuali chiarimenti (ce ne sara' da parlare).
  Alla fine dell'integrazione/analisi potremo assegnare i "task" in modo piu' chiaro e definito.
  
• Sviluppo futuri.
  Durante l'analisi/integrazione si verifichera' come implementare (modalita' e tempi) le seguenti funzionalita'.
  
  • realizzazione del parser oql
    • toria: individuare la sintassi da usare per le query oql
    • pratica: implementazione
  • realizzazione del nuovo algoritmo di full disjunction (kostantin).
    
  • uso delle librerie di indicizzazione (chiedere a Federica) in modo da sganciarsi dal database.
    
  • propongo (Alberto) di realizzare un'architettura "open" in modo che si possano usare piu' "moduli alternativi" per fare la "fusione" delle query.
    Tra questi
    • l'attuale, fatto da Luca Ghetti basato su Ms SqlServer
    • quello basato sulle librerie "Federica"
    • eventualmente un modulo basato su HyppersonicSQL (Alberto)

• I do not want estimate it

• una JoinTable con i metodi

     public  void setMapping(Interface interfaceLeft
                            , Interface interfaceRight
                            , JoinMap joinMap
                            )
     public JoinMap getMapping(Interface interfaceLeft
                               , Interface interfaceRight
                               ) {
  

• una JoinMap con i metodi

     (costruttore)
     public JoinMap(Attribute attributeLeft, Attribute attributeRight) {
     public  void addMappingAttributeEqual(Attribute attributeLeft
                                          , Attribute attributeRight){
     public  void getStringRepresentation(Attribute attributeLeft
                                          , Attribute attributeRight){
  

• metodi di "trasformazione sulla" struttura dati:
  

     JoinMap:
      String getStringRepresentation()
  

  che, ritorna qualcosa del tipo:
  

     sorgente.interface1.attrNome1 = sorgente.interface2.attrNome1
  

  oppure

     ( sorgente1.interface1.attrNome1 = sorgente2.interface1.attrNome1
       and
       sorgente1.interface2.attrNome1 = sorgente2.interface2.attrNome1
     )
  

• Un parser, che dalla rappresentazione stringa produca l'albero
• PARTENDO DALLA FUNZIONE

     getStringRepresentation 
  

  SI PUO' CREARE QUALCOSA DI ANALOGO CHE PRODUCE L'SQL PER IL JOIN DEL QUERY MANAGER!!!
  

 implements JoinMapTreeNode