METHOD, SYSTEM AND COMPUTER PROGRAM FOR STORING INFORMATION WITH A DESCRIPTION LOGIC FILE SYSTEM

Technical Field

The present invention relates to the information technology field. Particularly, the present invention relates to the storing of information in data processing systems.

Background

A data processing system (such as a computer) is commonly used to store a huge amount of information. Typically, the information is arranged in files - each one consisting of a block of information stored on a mass memory of the computer, which block of information may be individually accessed by a user thereof.

The files are organized in a file system, which is controlled by an operating system of the computer. Substantially all the file systems known in the art have a hierarchical structure. Particularly, the files are included in containers (generally referred to as folders or directories) ; the folders are then linked in a tree, starting from a root folder defining a (physical or logical) device of the computer.

The file system facilitates the logical management of the files on the computer. Indeed, first of all a name of each file provides some sort of information about its characteristics. Moreover, all the files in a same folder are likely to share common characteristics defining a corresponding category - in some way identified by a name of the folder; different levels of categories for the files may also be defined by the hierarchy of the folders. For example, it is possible to have a folder for all the customers, with further folders depending thereon for specific customers, each one including all the files relating to a corresponding customer (with each file that stores a specific communication with the customer) .

However, in this way the characteristics of the files may only be defined in a completely informal manner (according to the names of the files and the folders); therefore, in general this information cannot be leveraged by software applications. Moreover, the organization of the files in the folders (once a specific hierarchy has been selected) is quite rigid and difficult to change. Particularly, each file belongs to a single folder. It is also possible to create a link to the same file into other folders; however, this only allows adding further characteristics to the file (according to the names of the other folders) , but it breaks the concept of uniqueness of the files and makes the organization of the files very difficult to manage. In any case, the folders do not allow expressing relations among the files (apart from the basic ones defined by their inclusion in the folders) .

A different approach is disclosed in US-B-7, 149, 729 (the entire disclosure of which is herein incorporated by reference) . This document exploits metadata associated with the files (intended to describe them) for facilitating their access. For this purpose, virtual folders are provided for exposing different views of the files, which are based on their metadata instead of the actual organization of the files in the (physical) folders. More specifically, the metadata of all the files are stored in a database; each virtual folder is defined by a filtering criterion, which is used to query the database so as to retrieve the files matching the filtering criterion (defining a corresponding category of files) . The files in the virtual folders may be manipulated with standard commands (such as copy, move, delete, and the like) , which are implemented by acting on the relevant metadata accordingly. For example, when a file is appended to a virtual folder its metadata is updated automatically. Conversely, when a file is to be deleted the user can select its physical cancellation from the mass memory or only its logical removal from the virtual folder (simply involving the update of the corresponding metadata) .

However, the solution described above is not completely satisfactory. Particularly, the files can be filtered (in the virtual folders) only according to explicit characteristics that have been expressly defined in the metadata. Moreover, it is not possible to enforce any logical consistency of the characteristics of the files in the different virtual folders. For example, nothing prevents specifying in the metadata of a file storing a rock song that its author is (correctly) a rock band but its gender is (wrongly) classical music; in this case, the file would be erroneously included in a virtual folder of the classical music (as a result of a query based on the corresponding filtering criterion) .

Summary

In its general terms, the present proposal is based on the idea of applying an ontology to the file system. Particularly, different aspects of the invention provide a solution as set out in the independent claims. Advantageous embodiments of the invention are set out in the dependent claims . More specifically, an aspect of the invention proposes a method for storing information in a data processing system. The method starts with the step of providing a knowledge base for a file system manager (which is adapted to organize a plurality of real files on a mass memory of the data processing system) ; the knowledge base defines a collection of knowledge that includes a set of concepts, a set of relations among the concepts, and a set of relations of inclusion that describe each real file as an instance of at least one concept (according to a predefined ontology) . A command is submitted to the file system manager for accessing a set of selected instances (for example, through a graphical representation of corresponding virtual folders and files) . The method continues by identifying a set of selected real files, which are described by the selected instances (according to the knowledge) . The selected real files are then accessed on the mass memory.

Preferably, the real files are accessed also according to further knowledge, which is inferred from the knowledge by applying predefined logical inference rules. Moreover, it is also possible to submit a further command for manipulating selected instances (involving a corresponding update to the knowledge) .

For example, when the selected instances are added to a target concept a relation of inclusion of each selected instance in the target concept is asserted.

A weak deletion of the selected instances from a further target concept is also supported (only involving the removal of each corresponding relation) .

The further command may also involve the change of selected real files (as above identified as the ones described by the selected instances according to the knowledge) . For example, it is possible to strongly delete the selected instances from another target concept, with the removal of each selected instance and each relation involving it, and the cancellation of each corresponding real file from the mass memory.

As a further improvement, the proposed solution also verifies a logical consistency of any update that is required to the knowledge.

Preferably, it is also possible to correct the knowledge accordingly (so as to allow enforcing the required update) .

In a proposed implementation, virtual folders and virtual files are associated with the concepts and instances, respectively, for displaying a representation of the file system. Typically, the commands submitted to the file system manager are intercepted (for example, with hooking techniques) and then forwarded to an inference engine.

In a particular implementation, the concepts conform to a hierarchical taxonomy. Advantageously, the knowledge is expressed with a Description Logic language.

In a suggested implementation, the knowledge base is stored independently of the real files.

Another aspect of the invention proposes a computer program for performing the above-described method.

Particularly, the computer program may be included in a virtual file system manager.

Moreover, the virtual file system manager may be embedded in an operating system. A different aspect of the invention proposes a corresponding system.

Brief description of the drawings The invention itself, as well as further features and the advantages thereof, will be best understood with reference to the following detailed description, given purely by way of a non-restrictive indication, to be read in conjunction with the accompanying drawings, in which:

FIG.l is a schematic block diagram of a computer that can be used to practice the solution according to an embodiment of the invention,

FIGs.2A-2B show an example of application of the solution according to an embodiment of the invention,

FIGs.3A-3E show further examples of application of the solution according to an embodiment of the invention,

FIGs.4A-4B show another example of application of the solution according to an embodiment of the invention, and FIG.5 is a collaboration diagram representing the roles of different software components that may be used to implement the solution according to an embodiment of the invention.

Detailed Description

With reference in particular to FIG.l, a schematic block diagram of a computer 100 (for example, a PC) is illustrated. The computer 100 is formed by several units that are connected in parallel to a system bus 105. In detail, one or more microprocessors (//P) 110 control operation of the computer 100; a RAM 115 is directly used as a working memory by the microprocessors 110, and a ROM 120 stores basic code for a bootstrap of the computer 100. Several peripheral units are clustered around a local bus 125 (by means of respective interfaces) . Particularly, a mass memory consists of one or more hard-disks 130 and drives 135 for reading CD-ROMs 140. Moreover, the computer 100 includes input units 145 (for example, a keyboard and a mouse) , and output units 150 (for example, a monitor and a printer) . An adapter 155 is used to connect the computer 100 to a network (not shown in the figure) . A bridge unit 160 interfaces the system bus 105 with the local bus 125. Each microprocessor 110 and the bridge unit 160 can operate as master agents requesting an access to the system bus 105 for transmitting information. An arbiter 165 manages the granting of the access with mutual exclusion to the system bus 105.

The computer 100 implements a file system, which is used to organize files stored on its mass memory 130,140 (for their access by a user of the computer 100) . In the solution according to an embodiment of the invention, as described in detail in the following, the file system is based on an ontology.

The ontology is a formal specification for describing a semantic of generic entities of a domain of interest (i.e., their meaning in an unambiguous way) . The entities that can be described according to the ontology define a universe of discourse of the domain. Generally, the ontology is based on some sort of conceptualization, which provides an abstract view of the entities (simplified by ignoring their details, so as to capture same sort of commonality among them) , which entities can then be described with concrete data structures conforming to the ontology.

Most ontologies define instances, concepts, attributes and relations. The instances consist of the concrete things (either tangible or intangible) , which are to the described as a final goal of any ontology (for example, the instance "MyCar" of a specific car) . The concepts are abstract collections of instances (for example, the concept "Car" for all the cars) . Attributes are pieces of information (generally in the form of pairs name/value) , which are used to specify the instances or concepts to which they are applied (for example, the attribute "Color=Red" for the instance "MyCar", or the attribute "NumberOfWeels=4" for the concept "Car") . At the end, the relations associate one or more source terms to one or more target terms. The most important type of relation is the relation "is-a", which specifies that a source instance/concept is included in a target concept. The relation "is-a" allows defining a particular ontology (known as taxonomy) , which is used to classify the instances into categories defined by corresponding concepts. Typically, the taxonomy has a hierarchical structure, wherein the concepts are organized into a tree structure by the relations "is-a" - with child concepts

(including corresponding instances) that are included in parent concepts up to a root concept of the tree (for example, a concept "Vehicle" that includes the concepts "Bike" and "Car") .

Facts (i.e., clauses that are always true) consisting of the definition of specific concepts or of the assertion of specific relations (describing actual entities according to the ontology) define the knowledge on the domain, which is collected in a knowledge base. The knowledge base differs from a standard database, since in this case further knowledge may be derived from the existing knowledge by a reasoning based on logical inference. The logical inference is the process of obtaining new facts from available facts by applying logical inference rules (which define how the available facts are to be combined to obtain the new facts) . The knowledge base may be expressed (according to the ontology) by different formal languages. Typical examples are the Description Logic (DL) languages, which derive their name from the application of a logic-based semantic. The syntax of each DL language is defined by terms including instance names, concept names, role names, attribute names, constructors, intensional assertions and extensional assertions. The instance names represent instances, the concepts names represent concepts (with a standard concept "Top" formed by all the instances, and a standard concept "Bottom" with no instances) , the role names represent relations, and the attribute names represent attributes. The constructors (such as intersection, union, negation, inverse, and the like) are used to combine simpler terms (concept names or role names) into more complex terms; for example, the constructor "CarflBhasFoldingRoof" defines the concept of "ConvertibleCar" as the cars (included in the concept "Car") that have a folding roof (attribute "hasFoldingRoof" asserted) . The intensional assertions express relations among concepts; for example, the intensional assertion "Car c: Vehicle" specifies that the concept "Car" is included in the concept "Vehicle". At the end, the extensional assertions express relations among instances and other instances, concepts or roles; for example, the extensional assertion "MyCar belongsTo MyPerson" specifies that the instance "MyCar" is used by the instance "MyPerson", and the extensional assertion "MyCar is-a Car" specifies that the instance "MyCar" is included in the concept "Car". Conventionally, a DL language distinguishes a Terminological Box (TBox) and an Assertional Box (ABox) . The TBox substantially represents the conceptualization of the desired entities (i.e., a sort of schema of the data); for this purpose, the TBox includes the concepts, the roles, the attributes, and the intensional assertions. On the other hand, the ABox substantially represents the entities that actually manifest this conceptualization (i.e., the data itself); for this purpose, the ABox includes the instances and the extensional assertions. This distinction is not significant, but it facilitates the definition and the management of the knowledge base that is expressed with the DL language.

In the solution according to an embodiment of the invention, the file system is described with a knowledge base, which defines a collection of knowledge conforming to a predefined ontology; more specifically, the knowledge includes concepts, relations among the concepts, and relations of inclusion describing each file as an instance of one or more concepts. For each command that is submitted to a file system manager for accessing a set of selected instances, corresponding selected files described by the selected instances are identified according to the knowledge; these selected files can then be accessed on the mass memory.

The proposed solution allows defining the semantic of the files in a formal way and then without ambiguities (according to the ontology) . Moreover, this allows implementing sophisticated semantic reasoning on the file system.

It should be noted that the desired solution is embedded in the file system itself, which then directly manifests an intelligent behavior.

This capability of the file system may be exploited by the user (which benefits of an automatic classification of the files according to the concepts wherein the corresponding instances are included) . Moreover, the same capability may also be leveraged by software applications out-of-the-box .

Moving now to FIG.2A, in a preferred embodiment of the invention the knowledge base is expressed with a DL language. The choice of a particular DL language can permit a good tradeoff between the opposed requirements of descriptive capability and reasoning complexity (even if the proposed solution is in no way constrained to any particular DL language) .

Particularly, the TBox includes the standard concepts "Top" and "Bottom", and a concept "StandardFile" for all the files; the user can then define further custom concepts

(included in the concept "StandardFile") , roles, attributes, and intensional assertions. The user can then define the ABox with extensional assertions describing each file stored on the mass memory of the computer as an instance of one or more concepts (with all the files that are always described as an instance of at least the concept "StandardFile") , together with any desired corresponding relations.

For example, as shown in the figure, the knowledge base may define a hierarchical taxonomy, which is represented graphically with a tree 200. More specifically, each concept is represented with a virtual folder 205, and each instance is represented with a virtual file 210; hereinafter, for the sake of simplicity, each virtual folder 205 and each virtual file 210 will be denoted with the same name of the corresponding concept and instance, respectively. As pointed out above, each virtual file 210 describes a (real) file that is stored on the mass memory of the computer; the real file is identified unambiguously by a corresponding identifier - for example, consisting of a Universally Unique Identifier (UUID) . The virtual folders 205 are instead completely independent of any real folder that may possibly be used to organize the real files on the mass memory of the computer (even if nothing prevents using corresponding real folders for the first instance of each real file that is added to the knowledge base) . The tree 200 starts from the (root) virtual folder "StandardFile" (for all the real files) . The user then defined the organization of a company archive with a concept "Vehicle" for all the vehicles asserting that "Vehicle <ΞΞ StardardFile", a concept "Bike" for all the bikes asserting that "Bike <ΞΞ Vehicle", a concept "Car" for all the cars asserting that "Car £ Vehicle", a concept "Project" for all the projects asserting that "Project £ StardardFile", and a concept "Person" for all the persons asserting that "Person c: StardardFile"; the user further asserts that "Car fl Bike = Bottom" (i.e. no cars can be a bike and no bikes can be a car) .

At this point, the user defined an instance "MyBikel" of the concept "Bike" (assertion "MyBikel is-a Bike") , two instances "MyCarl" and "MyCar2" of the concept "Car" (assertions "MyCarl is-a Car" and "MyCar2 is-a Car") , two instances "MyProjectl" and "MyProject2" of the concept "Project" (assertions "MyProjectl is-a Project" and "MyProject2 is-a Project"), and three instances "MyPersonl", "MyPerson2" and "MyPerson3" of the concept "Person" (assertions "MyPersonl is-a Person", "MyPerson2 is-a Person", and "MyPerson3 is-a Person") . The instances "MyBikel", "MyCarl" and "MyCar2" may describe real files storing information about the corresponding bikes and cars (such as their plate number, mechanical characteristics, age, and the like) ; the instances "MyProjectl" and "MyProject2" may describe real files storing information about the corresponding projects (such as their scheduling, status, and the like) , while the instances "MyPersonl", "MyPerson2" and "MyPerson3" may describe real files storing information about the corresponding persons (such as their name, telephone number, and the like) . The user can also assert any desired relation among the instances. For example, it is possible to assert that "MyBikel belongsTo MyPersonl", "MyCar2 belongsTo MyPerson3", "MyProjectl belongsTo MyPerson2", and "MyProject2 belongsTo MyPerson3". The resulting knowledge base is represented in the tree 200 with the virtual folder "StandardFile" as a root thereof. The virtual folders "Vehicle", "Project" and "Person" are appended to the virtual folder "StandardFile", and the virtual folders "Bike" and "Car" are appended to the virtual folder "Vehicle". The virtual file "MyBikel", the virtual files "MyCarl" and "MyCar2", the virtual files "MyProjectl" and "MyProject2", and the virtual files "MyPersonl", "MyPerson2" and "MyPerson3" are appended to the virtual folders "Bike", "Car", Project" and "Person", respectively. The management of the virtual folders 205 and virtual files 210 in the proposed file system is made with commands that are as similar as possible to the ones typically supported by standard file systems. In this way, the devised solution is completely opaque to users and to software applications that do not leverage it. However, further commands are available to implement additional operations specifically tailored to the proposed organization of the file system based on the knowledge base.

Particularly, the user can access each virtual file 210 (and then the corresponding real file on the mass memory of the computer) as usual by any path that reaches the virtual file 210 from a generic virtual folder 205 to which it is appended. For example,

"StandardFile/Vehicle/Car/MyCarl", "Vehicle/Car/MyCarl", "Car/MyCarl", and "MyCarl " are all valid paths for the virtual file "MyCarl" (identified by its UUID) .

However, the user can now also access the virtual files 210 according to further knowledge that is inferred (by applying logical inference rules) from the knowledge base. For example, as shown in FIG.2B, the user adds a new concept "Benefit" for the vehicles that are used by the persons ("Benefit £ Vehicle AND Vehicle belongsTo Person") . In this case, it is possible to infer that the instance "MyBikel" (used by the instance "MyPersonl") and the instance "MyCar2" (used by the instance "MyPerson3") are included in the concept "Benefit". This is represented in the tree 200 by the virtual folder "Benefit" that is appended to the virtual folder "StandardFile", with the virtual files "MyBikel" and "MyCar2" that are appended to the virtual folder "Benefit". It should be noted that this result is achieved automatically by applying a reasoning on the knowledge base, without the need of explicitly asserting that the instances "MyBikel" and "MyCar2" are included in the concept "Benefit".

In this way, it is possible to discover implicit relations between the instances (and the corresponding real files) . Moreover, this allows performing semantic queries on the file system. The virtual folders 205 and the virtual files 210 may also be manipulated with standard commands (such as copy, move, delete, and the like) , which are automatically translated into the corresponding updates to the knowledge base and to the real files (if it is necessary) . For example, FIG.3A shows a portion of the same tree 200 as in FIG.2A (limited to the virtual folders "StandardFile", "Vehicle", "Bike" and "Car" with the corresponding virtual files "MyBikel"; "MyCarl" and "MyCar2") . In this case, the user creates a new virtual folder 205 for a concept "RentedGood" (for all the goods that are rented by the company) ; the user then copies the virtual file "MyCar2" into the virtual folder "RentedGood" (for example, by a drag-and-drop with the mouse - as represented by an arrow in the figure) , to indicate that the corresponding car has been rented. Moving to FIG.3B, as a result a new assertion "MyCar2 is-a RentedGood" is added to the knowledge base automatically. This is represented in the tree 200 with a further virtual file "MyCar2" that is appended to the virtual folder "RentedGood". The user then creates a new real file storing information about a PC that is rented by the company, and represents it with a new virtual file "MyPCl" that is appended to the same virtual folder "RentedGood". As above, a new corresponding instance "MyPCl" with the assertion "MyPCl is-a RentedGood" is added to the knowledge base automatically. With reference now to FIG.3C, the user decides to delete the virtual file "MyCar2" from the virtual folder "RentedGood" (as indicated with a cross in the figure) . The delete operation may be performed either in a weak mode or in a strong mode (for example, by selecting corresponding commands in a pop-up menu that is opened when the user clicks on any virtual file 210 with the right button of the mouse) .

In the case of the weak deletion, as shown in FIG.3D, only the corresponding assertion "MyCar2 is-a RentedGood" is removed from the knowledge base. This is represented in the tree 200 with the deletion of the virtual file "MyCar2" from the virtual folder "RentedGood". However, the operation does not affect the other terms of the knowledge base involving the instance "MyCar2". Therefore, in the example at issue the instance "MyCar2" of the concept "Car" (assertion "MyCar2 is-a Car") remains, as shown in the figure by the virtual file "MyCar2" that is still appended to the virtual folder "Car". For example, this operation may be performed when the corresponding car is not rented any longer, but it has been bought by the company. On the other hand, in the case of the strong deletion, as shown in FIG.3E, the instance "MyCar2" is completely removed from the knowledge base with all the corresponding assertions; in the specific case at issue, this involves removing the instance "MyCar2", the assertion "MyCar2 is-a RentedGood", and the assertion "MyCar2 is-a Car". The removal of the instance "MyCar2" from the knowledge base also involves the actual cancellation of the corresponding real file from the mass memory of the computer. This is represented in the tree 200 with the deletion of the virtual files "MyCar2" from the virtual folder "RentedGood" and from the virtual folder "MyCar". For example, this operation may be performed when the company does not have the corresponding car any longer.

Moreover, it is also possible to enforce the logical consistency of any command that is submitted by the user on the virtual folders and/or files. For this purpose, reference is made in FIG.4A to the same tree 200 shown in FIG.2A. Let us assume that the user tries to copy the virtual file "MyCar2" into the virtual folder "Bike" (again with a drag-and-drop with the mouse - as represented by an arrow in the figure) . However, in this case the operation is incompatible with the assertion "Car fl Bike = Bottom" - stating that no instances of the concept "Car" can also be an instance of the concept "Bike" (and vice-versa) . Therefore, the user is warned that the operation is not allowed. In response thereto, the user can abort the operation (for example, because s/he understands that it was requested by mistake) .

Moving to FIG.4B, alternatively the user can instead decide to enforce the operation; for example, this may happen when the user understands that an error was made previously - when the virtual file "MyCar2" was appended to the virtual folder "Car" by mistake. In this case, the instance "MyCar2" is included in the concept "Car" with the addition of a new assertion "MyCar2 is-a Bike" in the knowledge base. At the same time, all the assertions in the knowledge base that were incompatible with this new assertion are removed; in the specific case at issue, this involves removing the assertion "MyCar2 is-a Car". This is represented in the tree 200 with the virtual file "MyCar2" that is moved from the virtual folder "Car" to the virtual folder "Bike".

In this way, it is ensured that the knowledge base is always in a logically consistent condition; particularly, the proposed feature prevents the user from performing any wrong operation on the file system.

Moving to FIG.5, the main software components that can be used to implement the solution according to an embodiment of the invention are denoted as a whole with the reference 500. The information (programs and data) is typically stored on the hard-disk and loaded (at least partially) into the working memory of the computer when the programs are running. The programs are initially installed onto the hard disk, for example, from CD-ROM. Particularly, the figure describes the static structure of the system (by means of the corresponding components) and its dynamic behavior (by means of a series of exchanged messages, each one representing a corresponding action, denoted with sequence numbers preceded by the symbol

Α ) . More in detail, an operating system 505 (for example, Linux) provides a software platform implementing the basic functions of the computer through corresponding components; particularly, the components of the operating system 505 that are relevant to the present discussion include a native file system manager 510 (which controls the organization of the real files on the mass memory of the computer) and a Graphical User Interface, or GUI 515 (which controls the interaction of the user with the computer through the manipulation of graphical elements) . Software applications 520 (only one shown in the figure) run on top of the operating system 505; the application 520 may consist of either a software program implementing a specific service or a simple console for accessing the operating system 505 by the user.

In the solution according to an embodiment of the invention, a virtual file system manager 525 wraps the native file system manager 510. Particularly, the virtual file system manager 525 includes a knowledge base 530 (with its TBox and ABox, not shown in the figure) , which describes the file system in conformity with a predefined ontology. Preferably, the knowledge base is stored on the mass memory of the computer in a structure that is independent of the real files (for example, in a database) . In this way, the knowledge base 530 is de-coupled from the native file system manager 510 - so that it can be used to extend any available native file system manager 510. An interface 535 is used to edit the TBox of the knowledge base 530; for this purpose, the interface 535 exposes a set of APIs in corresponding libraries. These APIs allow submitting commands for adding, removing, or updating concepts, roles, attributes, and intensional assertions in the knowledge base 530 (action "Al. Edit"). In response thereto, the knowledge base 530 is updated accordingly in the respect of its logical consistency (action "A2.Update") .

A rendering module 540 accesses the knowledge base 530. The rendering module 540 associates the concepts and instances of the knowledge base 530 with the corresponding virtual folders and files, which are then linked according to the corresponding assertions (action "A3.Associate") . The rendering module 540 then causes the GUI 515 to display a graphical representation of the resulting structure (action "A4. Display") .

An API layer 545 exposes a set of APIs for managing the virtual folders and files (for example, implemented with a Java Extension) ; the API layer 545 supports all the commands of the native file system 510, with additional commands for the functions specific to the virtual file system 525. The application 520 can then submit any desired command to the virtual file system 525, by invoking the corresponding API exposed by the API layer 545 (Action "A5. Submit") . For example, the commands may be submitted by acting on the graphical representation of the virtual folders and files; alternatively, the commands may be submitted with corresponding instructions.

In any case, each command is intercepted by a hooker 550 (for example, by exploiting a kernel extension of the operating system 505) . In response thereto, the hooker 550 forwards the command to an inference engine (or reasoner) 555 for the knowledge base 530 (action "A6. Forward") ; examples of available inference engines known in the art (for the knowledge base 530 expressed with the DL language) are Fact++, KAON, and Pellet. In response thereto, the inference engine 555 at first verifies whether the operation requested on the knowledge base 530 by the command is logically consistent with its content (action "A7.Verify") . When the result of this verification is negative, the inference engine 555 provides a warning message to the user through the GUI 515 - for example, with a pop-up window (action "Aδ.Warn"). If nevertheless the user decides to enforce the operation, the inference engine 555 corrects the knowledge base 530 to remove the inconsistency (action "A9. Correct") . In any case, the knowledge base 530 is then updated according to the required operation (action "AlO. Exec"). When the execution of the operation involves any access and/or change to selected real files that are described by selected virtual files (either directly or through selected virtual folders) , these real files are identified by a converter 560 according to their UUIDs (action All . Identify") . If the operation consists of any change to the selected real files (such as their cancellation) , the converter 560 enforces the operation on the native file system manager 510 (action "Al2.Enforce") . Conversely, if the operation consists of an access to the selected real files (such as for their opening) , the converter 560 returns the selected real file to the application 520 through the native file system manager 510 (action "Al3.Access") .

Naturally, in order to satisfy local and specific requirements, a person skilled in the art may apply to the solution described above many logical and/or physical modifications and alterations. More specifically, although the present invention has been described with a certain degree of particularity with reference to preferred embodiment (s) thereof, it should be understood that various omissions, substitutions and changes in the form and details as well as other embodiments are possible. Particularly, the proposed solution may even be practiced without the specific details

(such as the numerical examples) set forth in the preceding description to provide a more thorough understanding thereof; conversely, well-known features may have been omitted or simplified in order not to obscure the description with unnecessary particulars. Moreover, it is expressly intended that specific elements and/or method steps described in connection with any disclosed embodiment of the invention may be incorporated in any other embodiment as a matter of general design choice.

Particularly, the proposed solution lends itself to be implemented with an equivalent method (by using similar steps, removing some steps being non-essential, or adding further optional steps) ; moreover, the steps may be performed in a different order, concurrently or in an interleaved way (at least in part) .

In any case, the same solution may be used to organize any other type of files (for example, storing e-mails, multimedia data, and the like) .

Moreover, the knowledge base may be defined in another way conforming to whatever ontology; in any case, the above-mentioned concepts, instances and relations are merely illustrative, and they must not be interpreted in a limitative manner.

Alternatively, any other inference rules - or reasoning - may be used to derive further knowledge from the available one (for example, based on a higher-order logic) .

The above-described examples of commands that may be submitted on the representation of the file system are not exhaustive. For example, similar considerations apply to a move command (i.e., a copy command and a delete command), and the like; moreover, the same commands (i.e., access, copy, move, delete, and so on) may also be applied mutatis mutandi to multiple virtual files, or to one or more virtual folders (for their application to all the virtual files appended thereto, either directly or indirectly) .

In any case, in a basic implementation is not excluded the possibility of supporting only the weak commands or only the strong commands. Similar considerations apply if the consistency of the knowledge base is verified in any other way (for example, with the possibility of relaxing its requirements for non-critical environments and/or operations) .

Moreover, nothing prevents always aborting the inconsistent operations (without the possibility for the user to force them) ; in this case, it would be necessary for the user to remove the inconsistency manually and then resubmit the same command.

The proposed graphical representation of the file system is not to be intended as a limitation. In any case, the same commands may also be submitted in any other way, even through a Command Line Interface (CLI) .

Alternatively, it is possible to intercept the submission of each command to the file system manager with other techniques (for example, by wrapping the file system manager with stub libraries); in any case, nothing prevents implementing the proposed solution directly by the native file system manager.

Naturally, the concepts may be organized in any other structure (even not based on a tree) , such as a directed acyclic graph (DAG) .

The reference to the DL language must not be interpreted in a limitative manner, with the proposed solution that lends itself to be put into practice even expressing the knowledge base with other languages (such as the Prolog) . Nothing prevents storing the knowledge base in any other form; for example, in a different embodiment of the invention

(dependent on the underlying native file system manager) , the corresponding information may be saved in metadata of real folders and files.

Similar considerations apply if the program (which may be used to implement each embodiment of the invention) is structured in a different way, or if additional modules or functions are provided; likewise, the memory structures may be of other types, or may be replaced with equivalent entities (not necessarily consisting of physical storage media) . In any case, the program may take any form suitable to be used by or in connection with any data processing system, such as external or resident software, firmware, or microcode (either in object code or in source code - for example, to be compiled or interpreted) . Moreover, it is possible to provide the program on any computer-usable medium; the medium can be any element suitable to contain, store, communicate, propagate, or transfer the program. For example, the medium may be of the electronic, magnetic, optical, electromagnetic, infrared, or semiconductor type; examples of such medium are fixed disks

(where the program can be pre-loaded) , removable disks, tapes, cards, wires, fibers, wireless connections, networks, broadcast waves, and the like. In any case, the solution according to an embodiment of the present invention lends itself to be implemented with a hardware structure (for example, integrated in a chip of semiconductor material) , or with a combination of software and hardware. It would be readily apparent that it is also possible to deploy the same solution as a service that is accessed through a network (such as in the Internet) .

In an embodiment of the invention, the virtual file system may be implemented directly at the level of the operating system. However, nothing prevents providing the same solution as a plug-in, or in any other form. Moreover, even if the proposed solution has been described above only with reference to a stand-alone file system, its application to a distributed file system is not excluded. It is also possible to integrate different file systems (on remote computers) at the semantic level, with a process of reconciliation based on a common ontology to which all of them commit.

The proposed method may be carried out on a system having a different architecture or including equivalent units (for example, based on a local network) . Moreover, each computer may include similar elements (such as cache memories temporarily storing the programs or parts thereof) ; in any case, it is possible to replace the computer with any code execution entity (such as a PDA, a mobile phone, and the like), or with a combination thereof (such as a multi-tier server architecture, a grid computing infrastructure, and the like) .