Robust module based data management
- 1. Robust Module-based Data Management ABSTRACT The current trend for building an ontology-based data management system (DMS) is to capitalize on efforts made to design a preexisting well-established DMS (a reference system). The method amounts to extracting from the reference DMS a piece of schema relevant to the new application needs – a module –, possibly personalizing it with extra-constraints w.r.t. the application under construction, and then managing a dataset using the resulting schema. In this project, we extend the existing definitions of modules and we introduce novel properties of robustness that provide means for checking easily that a robust module-based DMS evolves safely w.r.t. both the schema and the data of the reference DMS. We carry out our investigations in the setting of description logics which underlie modern ontology languages, like RDFS, OWL, and OWL2 from W3C. Notably, we focus on the DL-liteA dialect of the DL- lite family, which encompasses the foundations of the QL profile of OWL2 (i.e., DL-liteR): the W3C recommendation for efficiently managing large datasets. Existing System The current trend for building an ontology-based data management system (DMS) is to capitalize on efforts made to design a preexisting well-established DMS (a reference system). GLOBALSOFT TECHNOLOGIES IEEE PROJECTS & SOFTWARE DEVELOPMENTS IEEE FINAL YEAR PROJECTS|IEEE ENGINEERING PROJECTS|IEEE STUDENTS PROJECTS|IEEE BULK PROJECTS|BE/BTECH/ME/MTECH/MS/MCA PROJECTS|CSE/IT/ECE/EEE PROJECTS CELL: +91 98495 39085, +91 99662 35788, +91 98495 57908, +91 97014 40401 Visit: www.finalyearprojects.org Mail to:ieeefinalsemprojects@gmail.com
- 2. The method amounts to extracting from the reference DMS a piece of schema relevant to the new application needs – a module –, possibly personalizing it with extra-constraints w.r.t. the application under construction, and then managing a dataset using the resulting schema.. Problems on existing system: 1.This is Method Not Maintain Easy. Proposed System Here, we extend the existing definitions of modules and we introduce novel properties of robustness that provide means for checking easily that a robust module-based DMS evolves safely w.r.t. both the schema and the data of the reference DMS. We carry out our investigations in the setting of description logics which underlie modern ontology languages, like RDFS, OWL, and OWL2 from W3C. Notably, we focus on the DL-liteA dialect of the DL-lite family, which encompasses the foundations of the QL profile of OWL2 (i.e., DL-liteR): the W3C recommendation for efficiently managing large datasets. Advantages: 1. This is very useful to maintain Data. 2. Search and retrieve the data is very Easy.
- 3. Implementation Implementation is the stage of the project when the theoretical design is turned out into a working system. Thus it can be considered to be the most critical stage in achieving a successful new system and in giving the user, confidence that the new system will work and be effective. The implementation stage involves careful planning, investigation of the existing system and it’s constraints on implementation, designing of methods to achieve changeover and evaluation of changeover methods. Main Modules:- Main Modules:- 1. User Module: In this module, Users are having authentication and security to access the detail which is presented in the ontology system. Before accessing or searching the details user should have the account in that otherwise they should register first. . 2. Global Answer Illustration: Suppose now that our DMS can answer conjunctive queries (a.k.a. select-project-join queries), e.g., Q(x):- JournPaper(x) ^ hasAuthor(x; "AH") asking for the journal papers written by Alon Y. Halevy. In some situation, it is interesting to provide answers from our DMS
- 4. together with the reference one, called global answers, typically when our own DMS provides no or too few answers. To do so, we extend the notion of module to robustness to query answering, so that global query answering can be performed on demand. We ensure that the module captures the knowledge in the reference schema that is required to answer any query built upon the relations of interest. Then, at global query answering time, this knowledge is used to identify the relevant data for a given query within the distributed dataset consisting of the dataset of the module-based DMS plus that of the reference DMS. 3. Reducing Data Storage Illustration: Computing edit distance exactly is a costly operation. Sev- eral techniques have been proposed for identifying candidate strings within a small edit distance from a query string fast. All of them are based on q-grams and a q-gram counting argument. For a string s, its q-grams are produced by sliding a window of length q over the characters of s. To deal with the special case at the beginning and the end of s, that have fewer than q characters, one may introduce special characters, such as “#” and “$”, which are not in S. This helps conceptually extend s by prefixing it with q - 1 occurrences of “#” and suffixing it with q - 1 occurrences of “$”. Hence, each q-gram for the string s has exactly q characters. 4. Module-Based Data Management: The main idea underlying the notion of module of a Tbox is to capture some constraints of the Tbox, including all the (implied) constraints built upon a given signature, denoted the signature of interest. Our definition of module extends and encompasses the existing definitions. In contrast with we do not impose modules of a Tbox to be subsets of it. For a module to capture some constraints of the Tbox, it is indeed sufficient to impose that it is logically entailed by the Tbox. In contrast with , we do not impose the signature of modules to be restricted to the signature of interest. In fact, as we have shown through the illustrative
- 5. example, the robustness properties may enforce the signature of modules to contain additional relations that are not relations of interest but that are logically related to them. . . Configuration:- H/W System Configuration:- Processor - Pentium –III Speed - 1.1 Ghz RAM - 256 MB(min) Hard Disk - 20 GB Floppy Drive - 1.44 MB Key Board - Standard Windows Keyboard Mouse - Two or Three Button Mouse Monitor - SVGA S/W System Configuration:- Operating System :Windows95/98/2000/XP Application Server : Tomcat5.0/6.X Front End : HTML, Java, Jsp Scripts : JavaScript. Server side Script : Java Server Pages.
- 6. Database : Mysql 5.0 Database Connectivity : JDBC.