MAGIK 3 Objectives

This document describes the objectives and (un)implemented tasks (tickets) of the new version of MAGIK tool.

Creation Date: 2013/05/15.

Last Modified: ~~LASTMOD~~.

• MAGIK - initial test version.
• MAGIK_WEB/ - a version presented in November 2012 at CIKM.
• MAGIK_WEB_AFTER_CIKM/ - a version developed after November 2012 at CIKM. Novelties:
  • Users
  • Hibernate
  • …
• MAGIK_WEB_VLDB/ - a version prepared for the query approximation version of MAGIK
  • no users (guest is a default user)
  • analytic page
  • several query checked at once for completeness

• Keeps track about running sessions
• Keeps track about opened database connections

• Generates specializations of max size k
• Generates generalization

• Integrate completeness statements suggestions and query approximation
  • Reasoning can be done with one query at time?

• MAGIK 3 connects to database: jdbc:postgresql://magik-demo.inf.unibz.it:5432/magik3 (user and pass are as before)
• Information about schemas and users are kept in the schema named: meta_information

<fc #FF0000>If we use hibernate then we should save schema objects only!</fc> <fc #FF0000>Extend schema class with type,dburl,dbusername,dbpassword</fc> (hibernate tutorial: http://www.tutorialspoint.com/hibernate/hibernate_overview.htm)

• Schema table contains information about virtual and remote database schemas
  • schema(schemaname,username,type,dburl,dbusername,dbpassword)
  • Here type in {local,remote}
  • Primary key is schema[schemaname,username,type]. It means that there cannot exists two schemas with the same name and type

(provided that for a moment we assume a single user in the system guest.

• Create one table for each FK, FDC, TC, and Query.
  • tcstatement(username, schemaname, type, relation, headterms, condition).
    • Primary key: tcstatement[username, schemaname, type, relation].
  • query(username, schemaname, type, queryname, atoms, outputvars, description, sql, semantics, countexists).
    • Primary key: tcstatement[username, schemaname, type, queryname].
  • foreignkey(username, schemaname, type, sourcerelation, targetrelation, virtual, enforced).
    • Primary key: tcstatement[username, schemaname, type, sourcerelation, targetrelation].
  • finitedomain(username, schemaname, type, relation, argposition, values).
    • Primary key: finitedomain[username, schemaname, type, relation, argposition].
• Virtual schemas: User is allowed to create new virtual schema and they are stored in schema table
  • Important: In virtual mode user is allowed to alter FKs and FDCs. So FK are listed and they are enforced!
  • As before we cannot query the database
    • There is no comparisons of query answers in analytic window for generalizations and specializations
• Remote schemas: User is allowed to create new connection to a remote schema and it should posses enough rights to read schema and meta information.
  • Important: In remote mode user is not allowed to alter FKs and FDCs, but you should be able to read it from the Postgres Database. <fc #FF0000>NEW</fc>: For reading FDC we should read only ENUM datatypes in Postgres.
  • Should we do a check if a remote schema has altered? <fc #0000FF>(think later)</fc>

• For now disable user login (allowing possibility for introducing users later).
• We have user table

• Constants in TC-statements should be represented with using single-quotes, e.g., pupil('John', '1', 'b')
  • i.e. instead of convention that constant term starts with a lower-case letter it should be constant term are between single quotes
  • that aslo means that constants can start with upper-case. Therefore, when generating the DLV encoding constants needs to encoded under double-quotes.
  • Estimate if this is worth persuading.

• Representing TC-statements in a datalog form instead of the current format (ask Werner?).
  • For example, pupil_a(Name,Level,Code) ← pupil_i(Name,Level,Code) , learns_i(Name,'French').