Classifications

• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
  • G06F21/60—Protecting data
  • G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
  • G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
  • G06F21/6227—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database where protection concerns the structure of data, e.g. records, types, queries
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
  • G06F16/21—Design, administration or maintenance of databases
  • G06F16/219—Managing data history or versioning
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
  • G06F16/90—Details of database functions independent of the retrieved data types
  • G06F16/95—Retrieval from the web
  • G06F16/958—Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/10—Text processing
  • G06F40/12—Use of codes for handling textual entities
  • G06F40/131—Fragmentation of text files, e.g. creating reusable text-blocks; Linking to fragments, e.g. using XInclude; Namespaces
• • G—PHYSICS
  • G06—COMPUTING OR CALCULATING; COUNTING
  • G06F—ELECTRIC DIGITAL DATA PROCESSING
  • G06F40/00—Handling natural language data
  • G06F40/10—Text processing
  • G06F40/197—Version control

Definitions

• the present invention generally relates to the field of collaboration between users in a computing environment in which resources, obtained by assembling objects, can be accessed, derived, completed, modified, etc. by these users.
• a typical resource example is a web page accessible through the Internet, but the present invention is not limited to this type of resource.
• techniques for accessing resources, modifying them, etc. to allow users to progressively enrich the content of these resources, and build personal versions of them, to which other information can be added.
• the Applicant has also proposed techniques to determine the relevance of resources according to their environment in terms of citation resources and resources cited.
• the main object of the present invention is to provide methods for accessing resources, for transforming or customizing resources according to the user, and for creating new resources, in which information of degree of elaboration can be integrated. resources, so as to provide the users with the most advanced prior information as opposed to other less elaborate information.
• Another object of the invention is thus to determine which information objects must be replaced or enriched (by alternative objects) when presenting a resource to the user.
• the present invention proposes new means of synchronization and enrichment of information covering all formats, as well as text and images as multimedia, and in particular RSS feeds and "podcasts" (audio, video).
• Another object, corollary, of the present invention is to provide methods of accessing resources, transformation or customization of resources according to the user, and creation of new resources, in which the owners of resources of origin, in particular in terms of the right of modification and dissemination, on the resources derived from it.
• the present invention proposes a method for accessing a resource in a computing environment, the resource comprising a set of objects, characterized in that the computing environment is capable of memorizing in association with at least one object of said resource.
• resource at least one modified object in that said computing environment comprises means capable of storing in association with such an object information of degree of elaboration, and in that the method comprises the following steps:
• the process includes, when lifie of an object is denied, the creation of two branches containing two alternative versions of the object, namely the modified version and the unmodified version.
• the assembly step of a resource including a certain version of the object in question is carried out by signaling the existence of a version or alternative versions of said object.
• the method further comprises a step of selecting, by a user accessing a version of the resource, a certain alternative version of the object.
• the method furthermore comprises the implementation of means for calculating the relevance scores of the different alternative versions of the objects in order to selectively present the most relevant versions.
• the given condition is a condition of presence of at least one object of another resource.
• the given condition is a condition of non-modification of the present object.
• the method is implemented in a computer environment comprising:
• At least one content server capable of providing content of objects that can be assembled to form resources
• a collaboration manager able to manage the versions of the resources and the versions of the objects which they contain, at the level of at least one user station, an extension (plug-in) of an object manipulation tool and of resources, able to communicate with the collaboration manager, and in that it includes a verification step of the authenticity of the extension by the collaboration manager.
• the degree of elaboration information is able to take one of two values, namely "the most elaborate" or not.
• the identification step includes the search for objects (OR; OA) whose degree of elaboration has the value "the most elaborate” among the avals successively modified from the object in question of the resource accessed .
• the identification step comprises searching for objects of degree of elaboration greater than one limit among the downstream objects successively modified from the object in question of the resource accessed.
• the search includes the search for objects of degree (s) of elaboration (s) higher (s) by browsing the upstream objects by modification of which the object in question was obtained.
• the identification step has made it possible to identify several more elaborate objects, it is provided in the step of assembling the objects a sub-step of adding to the resource an information signaling the existence of such multiple objects (OA).
• the object selected for assembly in the resource is the nearest most advanced downstream object in the succession.
• the assembly step is able to use successively for assembling the most elaborate objects sorted according to another criterion such as a notation.
• the method is capable, in a selection response by a user, of using an object designated by said instruction for assembly.
• the method further comprises a step of adjusting the notation of the object according to an instruction for the selection of this object by the user.
• the assembly step is able to use for assembly an object selected according to another criterion such as a notation among all the most elaborate objects.
• the method is implemented in combination with a pre-existing content server provided with means for chronologically managing the versions of the objects and in that the step of identifying the most elaborate version of an object is implemented at from version information provided by said chronological management means and contribution information of a user accessing the resource to the different versions, and in that it further comprises a step of presenting the current version of the object in the content server.
• a method implemented in association with storage means accessible in a computer environment for maintaining graphs of objects that can be assembled to form resources accessible in the environment, characterized in that the memory means are able to store, in association with these objects, information of degree of elaboration, and in that the method comprises the following steps:
• the method further comprises a step of, in response to the detection of the modification of an object, temporarily adjusting the information of the degree of elaboration of the objects, this adjustment being able to be thwarted or confirmed at the end of less the first response from the owners.
• the adjustment step gives the object immediately upstream of the modified object a higher degree of elaboration.
• the method further comprises, during a refusal response, adding to the graph a branch containing an alternative version of the object constituted by the object including the modification.
• the method furthermore comprises, in a response of refusal of a modification carried out on an object which is not the most elaborate and in case of incompatibility of the modification with at least one more elaborate object, the addition to the a branch graph containing an alternative version of the object consisting of the object including the modification or containing the incompatible object (s) and the modified objects from them.
• a method of creating a new resource from an existing resource that has been accessed in a computing environment characterized in that it comprises the following steps: detect the modification of an existing address by a user,
• the step of creating a new resource is performed by transclusion from information associated with the existing resource.
• the method is implemented in association with storage means accessible in a computer environment for maintaining graphs of objects that can be assembled to form resources accessible in the environment, the storage means are able to storing in association with each of these objects a degree of elaboration information, and the method comprises the following steps: detecting the modification of an object by a user,
• a method for propagating standard object description information between different objects that can be assembled to form viewable resources in a user interface within a computing environment characterized in that each object is associated with description metadata, and in that the method comprises the following steps:
• the user interface is suitable for hiding the user's description metadata.
• a method for making accessible to third parties within a computing environment a resource containing at least one object derived from another resource, characterized in that it comprises the following steps: detect a request from a user to modify the object,
• a common request is engen plurality of objects derived from resources belonging to the same owner.
• a computer resource capable of enabling the implementation of the method according to the fifth aspect mentioned above, comprising a set of objects and accessible through a computing environment, characterized in that association with at least some of the objects is stored a meta-data constraint dissemination of the content of the object, to selectively control its modification and / or accessibility by third parties in derived resources.
• the broadcast constraint meta-data includes at least one meta-data selected from the group consisting of authorization / prohibition modification meta-data, authorization meta-data / prohibition of access to third parties of non-modifiable objects. modified or modified, and contact meta-data of a decision-making authority.
• the resource is structured in the form of an object tree, in that in association with at least some nodes of the tree structure, a broadcast constraint meta-data item is stored, and that node-level broadcast constraint data applies to the child nodes of the node in question.
• a seventh aspect of the invention there is provided a method for making accessible to third parties within a computing environment a resource containing at least one object derived from another resource, characterized in that objects are capable of to be associated, in a stored manner in the computing environment, with diffusion constraint meta-data and these meta-data being capable of containing an identification of an owner of an object from which the aforementioned object is to be derived, and in that the method comprises the following steps:
• the method comprises the intermediate step consisting, between the sending of the request and the receipt of an authorization or a refusal, of a temporary assembly step of the resource with an object formed of an extract of the object that one wishes to derive.
• the object is a text object
• the said extract is elaborated according to legal criteria of right of quotation.
• a method for quantitatively estimating the activity of objects in a computing environment this environment allowing access to resources made by assembling objects, at least some of the objects that can be generated by derivation of pre-existing objects and modification of the objects thus derived, characterized in that it comprises the following steps: identifying the most ar objects to be derived, so that this identification propagates to objects derived from them,
• the method further comprises a step of group counting of the consultations of the most upstream objects and the objects which have been derived therefrom.
• the most upstream objects are advertising objects. * The most upstream objects are able to be derived without being able to be modified.
• a ninth aspect of the invention consists of a computer environment for implementing a method as defined in the foregoing, characterized in that it comprises a plurality of servers connected in mesh, able to contain information of derivation between objects and marking degrees of elaboration, each server being able to receive a request to indicate identifiers of objects on the basis of said information, and being able to redirect such a request to another server in the case where it is not able to respond to the said request.
• a first form of a tenth aspect of the invention is proposed a method for managing variable content resources in a computing environment, each resource comprising a set of objects and at least some of these objects being presented in a resource.
• the computer environment is capable of storing transclusion information based on object identifiers, information from which source objects have the possibility of being presented in transcluded objects
• the method includes the step of, when modifying an object, generating or updating, for each object transcluded from said object, a source object identifier to be taken into account for this object transcluded, as a function of a distance information between the modified object and said transcluded object.
• a second form of this tenth aspect consists of a method for managing variable content resources in a computing environment, each resource comprising a set of objects and at least some of these objects being presented in a resource by forming an object transcluded individually or as part of a larger object transcluded from a source object, via possibly one or more intermediate transclusive objects, so that a change to the source object can propagate to that object transclus, the method being characterized:
• the computer environment is capable of storing transclusion information based on object identifiers, information from which source objects have the possibility of being presented in transcluded objects
• the method includes the step of, during the presentation of an object, determining, for each object transcluded from said object, a source object identifier to be taken into account for this transclusted object, as a function of distance information between the modified object and said transcluded object.
• the step when modifying an object, identifies this object as its own source, with a zero distance.
• the resources comprise d arborescent objects, and in that it further comprises a step consisting, for a transclusion of an object encompassing descending objects, one of which is transcluded from the other, to define for the transclusion between descending objects of the transcluded enclosing object, a distance value between these objects shorter.
• said modifications may relate to different attributes of said objects, and in that the step of generating or updating source object is performed separately for each of the attributes, an object may thus have different source objects depending on the attribute considered.
• the different attributes comprise at least two attributes among attributes of content, metadata, position and transformation.
• each resource comprising a set of objects and at least some of these objects being presented in a resource by forming a transcluded object.
• a transcluded object individually or as part of a larger object transcluded from a source object, via possibly one or more intermediate transclusive objects, so that a change made to the source object can propagate to to said transclus object, characterized in that it comprises, according to the frequency of the modifications made to the objects and the object presentations, the implementation of either the first form of the tenth aspect of the invention, or the second form of said tenth aspect.
• the selection of the method according to the first form of the tenth aspect is automatically selected when the environment of the source object is not capable of generating said source object identifier.
• the selection of the implemented method is carried out transclusion by transclusion.
• the method is implemented in centralized server means able to supply the identifiers of source objects.
• the method is implemented in cascading processing means capable of providing the source object identifiers by step by step according to the transclusions.
• At least some transclusions are associated with object transformation information, which information each designates a predetermined transformation function to be applied to the object as the initial step of the transclusion.
• a transformation can be applied to object attributes such as content, position, meta-data and transformations attributes on internal object transclusions.
• Resources are spreadsheets and objects are cells or groups of cells in the sheet.
• obtaining an internal transclusion in a group of transcluded cells includes applying to the spreadsheet program instructions to copy / paste from a given internal transclusion of the source cell group.
• a twelfth aspect of the invention provides a method for managing a set of information objects in a computing environment, some objects being container objects that may contain other objects, and the computing environment including a first structure of objects. objects and a second object structure transcluded from the first, characterized in that:
• the method comprises the step of, during the transclusion operation of the first structure to the first structure, presenting the objects of the first structure in the first structure.
• the container objects of the second structure function of the suitability of the properties of the objects of the first structure with the constraints of the container objects of the second structure.
• the method further comprises the step of, when modifying a property of an object of the first structure, checking the adequacy of the modified property with the constraints of the container objects of the second structure, and to move, if necessary, the corresponding object presented in the second structure.
• the method further comprises the step of, when modifying a constraint of a container object of the second structure, checking the adequacy of the properties of the objects presented in this container object with the modified constraint of this object; ci, and to move where appropriate the object or objects considered.
• the information element or part of the modified element is associated with information indicating whether it replaces the original element of information or part of the element or whether it is an alternative to the element of information or part of original element, and in that it includes in the latter case a signaling step of the existence of the alternative.
• the method further comprises a step consisting, in response to the modification of an information element or part of an element, in signaling this modification to a server from which the data stream originates.
• the resources are tagged data flows that are accessed according to a syndication protocol, and in that the objects of said resources are information elements of said resources or parts of said information elements (applicable to all processes above).
• a fourteenth aspect of the invention there is provided a method for transforming a first resource comprising a tree structure of objects into a second resource comprising a tree structure of objects, based on transformations that can be performed on objects located at different levels of the tree, characterized in that, when there is a first transformation on a certain object encompassing at least one descending object and a second transformation on said descending object, the second transformation is performed as a priority to the first transformation.
• provision is made for user access to information objects generated by a collaborative system where different user groups can contribute to respectively forming different versions of objects from common starting objects, characterized in that the user is capable of belonging simultaneously to different groups, and in that it comprises the steps of:
• the modifying actions can be taken into account by default in other groups.
• a method for access by users to information objects generated by a collaborative system where different users can contribute to respectively forming different versions of objects, and where users can selectively accept or deny versions is characterized in that it comprises means of accounting for the contributions of users and acceptances / refusals by other users of the versions of objects containing these contributions.
• a seventeenth aspect of the invention provides a method for making accessible to a group of users within a computing environment a resource containing a plurality of objects that can be modified by the users to obtain different versions of said objects. characterized in that it comprises:
• the method comprises a step of selectively providing the decryption keys of the objects to the users according to the authorization information of said users.
• the versions of an object are constituted by successive updates of said object at the level of client computers, and that the step of creating a new key during the creation of a new version of the object is performed at the client node, a subsequent step of transmitting the new key to a key server being provided.
• the versions of an object are constituted by versions with different contents of said object, coexisting simultaneously and reserved for different groups of users, and in that that a communication of such an object from a first group to a user of a second group comprises:
• the method comprises a step of cutting the multi-version object into homogeneous parts from the point of view of the access rights, each part containing positioning information allowing its replacement in the structure, so that manipulations can be performed on the multi-version object even in the absence of access rights to all of its versions.
• a method for making accessible to different groups of users (ERC) within a computing environment a resource containing a plurality of objects that can be modified by the users to obtain different versions of said objects characterized in that each object is likely to exist in different versions corresponding to different groups of users and descendants of a multi-version object encompassing them, and in that it comprises, when a user accesses an object, presenting it to the versions of the object corresponding to the groups to which it belongs, each object version being obtained by transformation from another version of said object.
• a transclusion action by a user of an object belonging to a multi-version object causes a transclusion of the whole of the multi-version object.
• Each object is also likely to exist within the same group of users in different versions corresponding to different users, these versions can also be presented when the object is accessed by the users of said group.
• the method furthermore comprises the implementation of means for calculating the relevance scores of the different versions corresponding to the different groups and / or the different users in order to selectively present the most relevant versions.
• Any information that is accessible and uniquely identified is an object.
• a uniquely identified XML element is an object.
• a paragraph contained in a document in Word format is not an object because it does not have a usable identifier.
• We will implement ways to "reify” (reify means to make an object).
• a reified object is typically selectable by click 1 , movable or copiable (or “transcluable” - the transclusion is defined later), including drag and drop.
• a resource is an object managed by: a system level such as the operating system or the Internet server. Typical resources are web pages, files and directories. 2
• the owner of a resource is not necessarily the person who owns intellectual property rights over its content, but rather the creator of this resource (the latter may for example present the same content as a resource belonging to someone else, this content having been obtained by transclusion or by copy).
• a Set of Collaborative Resources is defined as a set of resources identifiable by a particular type of server (described below) that is referred to as collaborative server 3 , or by a similar device. 4 Moreover, CRF is characterized in that said set all resources are accessed by a defined set of users.
• ERC refers to both the ERC and the user group that has access to it. It is said that the user "belongs" to an ERC.
• an ERC is managed by at most 5 a collaborative server (or similar device), but a collaborative server can manage several ERC. It is said that a resource belongs to (or is part of) an ERC if it is identified as such by the collaborative server (or similar device) that manages this set 6 .
• Access to a resource is said to be through (or as part of) a given CRT 7 (in order to benefit from the features inherent to the CRFs that are described below). 8
• the user can also access a resource by letting the system determine which collaborative servers might identify that resource.
• system level is subjective and relative to one's point of view. Note also that resources contain objects that are usually not resources themselves, but there are many examples where this is not the case, especially directories (which contain resources themselves) and e-mails (which are resources and the attachments they "contain” are too).
• a resource can belong to several ERCs.
• the resource is not identified by the given ERC, it is just ignored.
• the user can place himself in several ERCs at a time.
• the user can also switch from one ERC to another using an interactive means provided for this purpose.
• the actions of the system are performed separately for each ERC and the results can be presented separately or in combination.
• a collaborative server does not store (not necessarily) the objects it manages but (rather) its identifiers. "User” may also mean “(exte itil of information manipulation (on the client)”.
• the user can select it is meant that the user can choose an option either at the same time or by configuring / setting the system in advance (except against direction).
• the user having the rights of access . is meant the individual user or group of users, or a user role, having the access rights in question (except against meaning).
• a collaborative server 9 allows a set of users to manipulate resources in common similar to a "wiki” (a method known per se, see in particular on http://www.wikipedia.org/wiki/Wiki).
• the difference with wikis is that, on the one hand, the method of the invention makes it possible to modify any resource present in the Internet (which is not necessarily provided for) and on the other hand that it can simultaneously manage variants for parts of these resources (expressing for example several points of view).
• the method is used via the usual navigation tools, equipped with extensions performing the interface with a collaborative server.
• FIGS 1-a to 1-g illustrate different stages of use of the method and allow to understand it intuitively, even before reading its description that follows.
• v represents a version of a collaborative resource.
• a vowel followed by a number (al) represents a version of an object (a); it is underlined (al) when it represents the most recent version 12 .
• Figure 1-a presents a first resource and a first version (al) of an object that this resource has.
• Figure 1-c shows the situation after the object has been modified in v2.
• the user views vl or v2, he automatically sees the most recent version of this object, that is to say that of v2, which is therefore underlined in figure (a2).
• Figure 1-d shows the case where the owner of vl denies the most recent version of object a (that is, version a2, from v2). As a result, a new "branch" is created for this object and a2 is put on it. As for al, the version of this object in vl, it finds itself alone in the first branch and thus becomes the most recent (for this branch).
• branches of an object are presented to the user as alternate versions of that object. 13
• Figure 1-e presents the case where the user viewing vl selects, for the object a, the second branch (whose most recent version a2 is presented to him as alternative version, that is to say as a selectable option). It is said that the user "activates" the second branch (he does this simply by selecting the alternative version in question). In the figure, we represent this by a displacement of the rectangle towards the branch of right whereas the object created initially remains well in the branch of left.
• Figure 1-f presents the case where the user modifies in vl the object a being in the second branch. He thus creates the version a3_ which becomes then the most recent in the second branch. As a result, when a user views v2 by having activated the second branch, he sees the most recent version of the latter, so that of v1 (that is to say a3).
• Figure 1-g shows the case where the user viewing v2 activates the first branch. He thus sees the version (al) of vl which is the most recent for the first branch of the object a.
• the method provides the ability to deny object versions (i.e. object changes made by another user).
• object versions i.e. object changes made by another user.
• the consequence of this refusal is to create a branch for each object whose version of the other user has been refused, and to move those versions to the new branches. Of the other versions available in the same branch, this will be the most recent one that will be displayed after the rejection.
• Each object of a collaborative resource can thus be partitioned into several branches, and each user then has the possibility to choose (for each object) which branch he prefers (this is presented in the form of "alternative versions", as described in the section next).
• each version of the collaborative resource specifies for each object that (there is exactly one) branch is enabled.
• each collaborative resource contains a number of objects
• each object has a number of branches
• each collaborative resource version can provide a local version.
• Figures 3-a to 3-d continue the case shown in Figure 2-d.
• the different branches of an object are represented by as many adjacent columns.
• a box (rectangle) indicates that the branch corresponding to the column is active in the version of the collaborative resource corresponding to the row.
• Figure 3-a The owner of v2 denies the change b3 (of v3). This creates a new branch (branch 2) into which b3 is sent, and bl becomes the most recent version in the old branch. Only v2 activates the new branch. At this time, versions vl and v2 display a4, bl and cl as values for the three objects and v3 displays a4, b3 and cl.
• Figure 3-b The owner of v3 takes revenge and refuses the value a4 of object a, which is in turn sent to a new branch. The most recent version in the first branch of a becomes a3 again. The values displayed for the three versions are respectively: a3 bl cl, a4 bl cl, a3 b3 cl.
• Figure 3-c v3 modifies its version of b, in its branch, and writes b4. However he is the only one to see it because he is the only one to have this active branch.
• v3 selects the second branch of a. This has the effect that viewing v3 shows a4, b4 and cl as values. Then he modifies a to write a5. At this time v3 has two local versions of a (one for each branch), the second of which is visible. The values displayed for the three versions are now a3 bl cl, a5 bl cl, a5 b4 cl.
• the method allows the user to view (and activate) the different branches 16 existing for each object. When a branch of an object is shown, the most recent version in that branch is displayed by default. It offers the user different methods to do this.
• the user can ask to see the different versions of the collaborative resource (which differs from each other by the active branches) - this allows the user to see the correlations between the different branches of the different objects of the collaborative resource.
• the user can also use a mixed method: when there is a large number of versions of the collaborative resource the user can "filter” among them by first choosing a branch for a particular object (or several), then by viewing the different versions 19 of the collaborative resource having activated the same branch for this object.
• the system will also avoid distinguishing two versions with the same combination of branches
• the user can endorse the most recent object version (as presented to him) of a branch, so as to make it his local object version for that branch (and replace the one that was there if applicable).
• the filtering can then be done by considering sets of versions of objects endorsed.
• the contributions of the users themselves are exploited to ensure the consistency of the branches activated between them. Derivation
• the user is offered several ways to avoid the task of selecting object by object the branches he prefers.
• each collaborative resource version is derived from the version whose change gave it birth.
• another method consists of looking for a user which version is close (in his choice of branches - this can be measured by looking at the proportion of branches that correspond to the total number of objects) from that of the user, and propose to the latter to place its version in derivative of this other version.
• Such "posterior derivation" can also be done by other methods of affinity search, or even manually by the user (particularly in the case of a student who derives his version from that of his master or a director who derives from his secretary).
• Figures 4-a to 4-d takes exactly the same operations as the example of Figures 3 -a to 3-d but assumes that the derivation relations were placed as follows: v3 drift of v2 then vl drift of v3. This implies that branch changes taking place in v2 will be reflected in v3 and any changes that take place in v3 will be reflected in vl, except that explicit branch selections will not be overwritten as well.
• Figure 4-a The owner of v2 denies the change b3 (of v3). This creates a new branch in which b3 is sent. v2 will explicitly choose the first branch and v3 will explicitly choose the second.
• vl does not make an explicit choice and therefore follows that of v3 (ie the second branch).
• v2 displays a4, bl, and cl as values for all three objects, while vl and v3 show a4, b3, and cl.
• Figure 4-b The owner of v3 denies the value a4 of object a, which is in turn sent to a new branch.
• v3 will therefore explicitly choose the first branch and v2 will explicitly choose the second, vl e ⁇ '?>, and therefore does not follow v2 in its branch change.
• the values attested for the three versions are respectively: a3 bl cl, a4 bl cl, a3 b3 cl.
• FIG. 4-c v3 modifies its version of b, in its branch, and writes b4. Contrary to the previous example, it is not the only one to see it because vl derives from it and also (implicitly) activated this branch (vl and v3 will thus see this new value whereas v2 will continue to see the old value bl ).
• FIG. 4d v3 selects the second branch of a. As in step 4-a, vl will implicitly activate this second branch. All three versions have activated the second branch of a and see the value a4. Then v3 modifies object a to write a5 to it. The values displayed for the three versions are now a5 b4 cl, a5 bl cl, a5 b4 cl.
• the different branches of an object can represent several points of view. Users are thus allowed to attach to the object branches "categories" describing the nature of this point of view. Each user having the possibility of changing the content of an object also has the possibility to change to which category his version of the object belongs.
• the system maintains a hierarchy of categories (taxonomy), from within which users can select qualifiers for their changes. This hierarchy is global to the ERC, but it can allow users to change, including adding or identifying 20 categories. Once users have tagged their changes, this information can be used and other users can filter available versions based on categories. This provides a fourth method for navigating the different versions of a collaborative resource, in addition to those proposed in the "Select branches automatically" section above. We will now show how it works.
• a user will consult a resource and declare to be interested in one or more categories in particular. 2.
• the system eliminates (from all possible choices) versions that have chosen at least one branch whose most recent content is categorized in a contradictory way to the categories requested.
• Deleting an object simply removes the reference from the parent. Here again we consider that only the parent is modified, not the object itself. These considerations are important when considering that for example one object can be deleted in one branch (of the parent) but not in another 22 .
• the object creation is done (from the point of view of the system) in two steps: first of all a new object is created at the level of the collaborative resource (because an object is a global concept to the collaborative resource, and not specific to a collaborative resource version). Then the object where the user asked to create a child is modified to contain a reference to this new object. So if for example a version wants to refuse this creation it will only refuse the modification of the parent, which will have the effect of making the new object invisible.
• Figure 5-a to 5-d continues the case of Figure 4-d, with the additional assumption that b and c are children of a, that is, all versions of a contain two slots, one for b and one for c.
• Figure 5-b The owner of v3 now moves object d as a child of cl. This means that it deletes the reference in b5 and adds a reference in cl. He creates new versions of these two objects, b6 and c6. A consequence of this is that now d is made visible to v2 also because it was introduced into an object branch that was active in its version. Also note that d has not been modified in the operation, there is still only one version dl, belonging to vl.
• Figure 5-c The owner of v2 refuses the irruption of this object. To do this he does not refuse himself (because a refusal means in fact the refusal of the content of the object, and not the object itself), but the new version c6 of c. This has the effect of creating a new branch of c, the old branch taking the old key value devoid of reference to d. Note that since vl is derived from v3, it will follow v3 in the new branch, and the new object will only be rejected in v2.
• Figure 5-d The owner of vl deletes the object b. To do this he modifies the object a to remove the slot pointing to b. This will create a new a6 version of object a.
• this operation is seen as a deletion, an object creation, and in some cases as the same object appears in several places.
• Figure 6-a Let there be two objects a and b, which each have two branches (al, a2 and bl, b2). We say that an object x (whose contents and branches are not relevant to us for this example) is present in each branch of a. At that moment the constraint is satisfied whatever the choice of branches because in all combinations x is child of a and only of a.
• Figure 6-b Suppose now that a user moves x from al to bl (in version vl). (Thus doing the values al 'and bl'). At this time there are three allowed combinations, al'bl ", al'-b2, and a2-b2 In the second of these combinations, x is not visible at all but it is not in violation of constraint (but we can redo the same example where the constraint would be that x must be visible exactly once and therefore this second combination would then be prohibited.) If there is at least one version of the collaborative resource that had activated a2-bl as combination (v2), make sure that the move has no visible effect in this version.This is done by creating a new branch that contains the original state of bl before it was received.
• the system must choose one of the two contents. For example, if one of the two branches is active, its content will be preferred, otherwise we take the most recent one.
• the user can destroy any of these contents
• resources may contain other resources, such as a directory containing documents or other directories. It can for example change the organization of files and directories, and its changes will have a consistent effect regardless of the directory viewed by another user. If different collaborative resources were used for each directory, this would not be the case - the changes would only be visible if you viewed the structure from the same point as when editing. transclusions
• a transclusion is similar to a resource version with the difference that objects seen through a transclusion can coexist with objects not seen through a transclusion, or seen through another transclusion etc.
• a transclusion is indeed treated, from the point of view of the implementation of the method presented here, as an object in the sense that it can be modified in the different versions and that these modifications can be refused by other users, this which makes the transclusion can have several branches.
• the content of a transclusion describes the differences applied to the sources.
• a transclusion differs from an object in that a transclusion can not itself be placed as a child of an object, and can not be directly displayed to the user (he can only see the image of objects by this transclusion).
• the resources identifiable by a given ERC contain objects possibly defined as being replaceable 23 as part of this set.
• users of the same ERC can modify and thus contribute new versions of some of their replaceable objects. These will replace 24 those presented to users of this set, or enrich bringing (optional) alternative versions 25s representing "different views.” It is the collaborative server (or similar device) that determines what these objects are.
• Means of presentation and / or manipulation of resources can be a browser such as Internet Explorer, or a tool such as Microsoft Word, or the file explorer of the operating system.
• a browser such as Internet Explorer
• a tool such as Microsoft Word
• Microsoft Word or the file explorer of the operating system.
• this tool In practice we will provide this tool with an extension (plug-in) able to implement the process.
• PCS Primary Content Server
• Collaborative server Server capable of providing, for a version of resource accessed, the identifiers of the object versions.
• the information manipulation tool performs the following steps:
• step 2. obtains from the collaborative server the identifiers of the object versions to present; 3. (continued with step 2.) obtains servers of secondary contents said versions of objects;
• An object (of a collaborative resource) - this represents not a particular version of this object but the class of all its branches and versions (the examples use the letters a, b, c, etc. to represent an object). As said above it can be a transclusion and not an object.
• a reference to a content i.e., a particular version of a branch of an object that is in a content server.
• a reference to a content indicates
• the user may activate none, one or more CRF at the time of its application. These sets can also be configured by default in the information manipulation tool. • If applicable, the category or categories this content. A version specifies
• the algorithms described below query the constraints (that all objects must be unique, for example) by asking whether a certain combination of branches of a collaborative resource should be allowed or not. This way of doing things allows to leave open the types of constraints that can be applied.
• the implementation of the constraint can provide a list of problematic branches. For example, for a uniqueness constraint, it is the list of branches containing the multiplied object.
• the client requests an active branch change indicating which object of which version of collaborative resource is affected, as well as the identifier of the new branch chosen.
• the system first checks whether the resulting combination of branch choices for this version violates a constraint. If it does, it will automatically change which branches are active in the other objects to satisfy the constraints.
• the description of a change contains a collaborative resource identifier, a version identifier (of the resource), the identifier of the modified object, and the description of the content of the object after the modification (all the attributes listed in the description of the data structure for "reference to content").
• the collaborative resource is also updated with the pointer to the most recent version in this branch.
• an object creation is done in two steps. First, the creation itself, then the modification of the parent object to contain a reference to that object. The first step is described below, and the second step will be requested by the client to the system as if it were a "normal" change.
• An object creation request indicates that this object is created, what should be the initial content (in the form of an identifier) and which version of the collaborative resource has created the object. The answer to this request will be the identifier of the new object.
• the processing of this request consists of:
• the client informs the system which version of the collaborative resource is refusing which objects. It is assumed that the denied versions are those currently displayed at the object locations for the given version.
• a lock system is used, where a user wishing to modify an object must first lock it and take the exclusive rights for the time it is modified, a period of time during which no one is allowed to modify the object.
• the system can provide the user with tools to perform this merge quickly: if the system detects the nature of the modifications made by the users it can try to merge the actions of the two users automatically, and ask the help of the last one only when it's about making decisions, eg if the same part of a paragraph has been changed by each user.
• Propagation restrictions A function can be offered to request, object-by-object, variations from the normal behavior of collaborative resources.
• a user can request to have for an object a "secret" branch to which he is the only one to have access.
• a "secret" branch behaves in every respect like any other, except that it is not made visible to other users (and they can not select it). If a user creates an object as a child of such a secret branch, the new object will also be made secret.
• the user can always request to see his local version for a particular purpose, even if a newer version exists in the same branch.
• One way to do this is that as soon as a change occurs in a branch, such a write-protected object is sent in his own branch (as himself). If the user then modifies this object again, it is sent again to the branch where it was previously, so that this new version is made visible to other users.
• Unidirectional propagation As another type of restriction one can have an object or a resource for which the modifications propagate only in one direction, for example from upstream to downstream as is the case of the transclusion.
• Transclusion can be used more for collaboration (by propagating the most recent or sophisticated changes) if this mechanism is extended to also propagate the changes to the source (upstream).
• This generalization of transclusion to serve as a mechanism of collaboration as defined so far).
• each such version is in fact a resource (downstream) in its own right (having a distinct resource identifier) that transcludes all its content from the resource ( upstream) that it aims to modify.
• the downstream resource is said to derive from the upstream resource.
• the method essentially consists in determining which objects must be replaced (by a replacement object) or enriched (by alternative objects) when presenting a resource to the user.
• FIGS 8 to 21 illustrate different stages of use of the method and allow to understand it intuitively, even before reading its description that follows.
• These figures illustrate examples of resource derivation: a resource R1 is derived into a resource R2 in order to be further elaborated, then R2 itself is derived to incorporate further modifications, and so on. However an object thus modified in a resource can be refused by one of the owners of the resources from which it is derived,
• R2 derives from Rl and modifies al to a2 ( Figure 9): So a2 is the most elaborate.
• R3 derives from R2 and modifies a2 into a3 (figure 10): So a3 is the most elaborate. R2 refuses a3 ( Figure 11): As a result of this refusal, a new branch is created (Branch 1) while the original flow is in Branch 0. a2 is the most elaborate in Branch 0 and a3 is the most elaborate in Branch 1 .
• R4 derives from R2 and modifies a2 into a4 (figure 15): So a4 is the most elaborate in BrancheO.
• R2 refuses a4 (Figure 18): A new branch is created (Branch 2) with a4 as the most elaborate object.
• Branch 0 is more relevant than Branch 1.
• R5 derives from R2 by changing a2 to a5 ( Figure 20): 28 So a5 is the most elaborate object in Branch 0.
• Derived Resource Creation Rule 0 When a user accesses a CRF for a resource using an information manipulation tool, for the purpose of modifying it, but can not or does not want it
• the training tool automatically creates a derived resource that presents the same content "" and presents it to the user, and the user modifies said derived resource in place of said accessed resource.
• the derived resource is stored in any server 31 available to the user (and therefore not necessarily in the server of said accessed resource).
• said resource accessed for modification is upstream of said derived resource (and that the latter is therefore downstream of said accessed resource).
• a resource can be derived from a resource itself derived, thus forming an upstream-downstream chain (or cascade).
• the initial situation is governed by the following rule.
• Rule 2 The said amendment is spontaneously offered to owners 33 respective corresponding resources upstream.
• the amendments may be proposed only if said owner is available, eg where their email address is known.
• the accessed resource is itself a derived resource (in the context of an ERC)
• the problem does not arise since its owner is already known and accessible automatically.
• the process of replacement / enrichment of an object can itself serve as a means of proposing acceptance or not of the modification (of the object which serves precisely as a replacement or enrichment).
• Resources are identified by an uppercase letter followed by a number (index) that indicates their version number; the objects are identified in lowercase and have the same index as the resource in which they were created or modified. 38
• the content of resource Rl is the object ri. ri itself contains three objects: al, bl and cl (in reality, the user who sees the content of the resource Rl sees the object r which contains the objects a, b, c, the indices will serve us here to see more easily what is the resource that contained the object in question initially)
• R1 is derived (in R2) to modify the specific content 39 or position 40 of objects r, a and c (ri is modified in r2, al is modified in "2 and cl is modified in c2) and insert a new object d (d2).
• R2 in turn is derived (in R3) to modify b (b2 is changed to b3) and delete c (delete c2).
• the data structure managed in the collaborative server advantageously does not contain the resources or the objects themselves, but only their respective identifiers.
• a structure of pointers and markers is presented schematically here, the pointers making it possible to reconstruct the derivations and modifications and the markers used to distinguish the most elaborate objects (as well as object deletions). This structure includes:
• Object modification trees 41 (such as: rl->r2;al->a2;bl->b3; cl ->c2->e3-; d2) whose nodes are accessible from the corresponding nodes of resource diversion trees 42 .
• the nodes forming the object modification trees only include the modified objects. Missing nodes represent non-objects
• the position can be specified by the parent object and a sibling object (left or right, depending on the convention taken).
• a variant of this approach will be described later in the section "Slots" (note that the slot approach was the one adopted in the previous chapter).
• Each node 42 of the tip resource derivation tree on the corresponding nodes of the tree object modification (as shown in the figures).
• it is possible to implement a different but equivalent data structure in particular by using relational DB tables. modified, that is to say that they reflect the content of their correspondents upstream.
• the figures presented schematically show a resource derivation tree and object modification trees. They show, in the form of black rectangle in the trees of modification of objects, the nodes marked as being the most elaborate.
• Figure 23 shows the data structure before the taps (i.e., before neither R2 nor R3 exists). Objects ri al, bl and cl are marked as under Rule 1 A are more elaborate. 45
• Figure 24 shows the data structure after the modifications in R2 and before the derivation of R3. It shows the nodes marked as the most elaborate (ie the black rectangles) assuming no changes have been accepted or rejected yet.
• Rule 1 the objects r2, a2, c2 and d2 become the most elaborate, while bl remains the most elaborate, since b2 46 has not been modified.
• Figure 25 shows the data structure after modifications in R3.
• the nodes marked as being the most elaborate presuppose that no modification has been accepted or refused yet.
• one of the changes made was to delete c.
• the object c2 is no longer the most elaborate but that it is e3- (the absence of the object c) which is it (always under Rule 1).
• R2 there is indeed the object b2 (which reflects the content and position of bl) and that in R3 there are the objects r3, a3 and d3 (which reflect the contents and positions of r2, a2 and d2 respectively), but they do not appear in the modification trees of these objects since only the nodes representing the modified objects are stored there.
• Figure 25 shows the initial situation on which the following examples are based.
• Rule 6 The "most elaborate" objects, except the object that serves as a replacement object under Rule 5, are considered alternative objects and are presented to the user as options. Each alternative object has a priority depending on the
• 46 b2 is not in the tree of modification of the objects since this tree understands only the identifiers of the modified objects (except those not modified but being the most developed) as already mentioned. proximity of the branch in which it is in the same branch being a priority and the nearest branches having a higher priority). 47
• the latter replaces the current object displayed (the latter may be the object contained in the resource, a replacement object or another alternative object previously selected).
• the collaborative server finds, in the set of resource derivation trees, the node representing the derived resource in question. From there he finds for each object for which there exists a tree of modification of objects, while traversing this tree, the object of replacement - the most elaborate object in the same branch downstream - and the objects alternatives (other more elaborate objects in the other branches) according to Rules 5 and 6.
• the user sees the resource R4 as when the user visits R1 just after "R1 refuses R3 and d2", except that, advantageously, there is no b3, e3- or d2, since R4 do not have them as ancestors 49 .
• This is shown in Figure 34.
• the user sees the resource R4 as shown in Figure 35.
• a2 is changed to a4 and b2 to b4.
• Alternative objects are b2, e3- (the absence of c) and d2. Note that b3 is not presented because it is neither ancestor nor descendant of b4. 50
• the user now sees the resource R1 as shown in Figure 36, and the resource R2 as shown in Figure 37.
• the user may prefer an alternative object to a replacement object that is presented to him.
• the user accesses the resource Rl after "R1 refuses R3 and d2" then selects the alternative object b3 and wants to modify it in b4.
• Rule 0 a derived resource R4 is created and one obtains the structure of Figure 38 in which the branch in which is located b3 is extended by b4 (which takes from b3 the most elaborate object marking.
• the implementation of collaborative development server can also have b3 as lower priority AC object, considering that it is a descendant of bl (because the resource R4 drift R).
• the user sees the resource R1 as shown in Figure 39.
• the resource R4 is shown in Figure 40, R1 as shown in Figure 41 and finally R2 as shown in Figure 42.
• R1, R2 and R4 present the same objects to the user, namely: r2, a2, b2, c2 and d2, and finally b3 as an alternative object.
• R3 it has r2, a2, b3 (b2 being alternative), c2 and d2. Since c2 will be logically refused by the user since he has just accepted the absence of c 52 , by way of optimization the collaborative server can refuse it of office and one thus obtains figure 44.
• rule 3v replaces rule 3 previously stated:
• Rule 3v In the case where the modification of an object is accepted (upstream), this modification is propagated to the accepting object. If said accepting object and said modified object accepted are in different branches, then said object thus accepting all its descendants to the first object from which a branch ends (directly or indirectly) to the branch in which the modified object is located. accepted are moved to the branch where the accepted modified object is located.
• a grain is a composite object whose modifications (objects that it contains) are propagated 55 in "all or nothing"; that is, they are
• Figure 47 presents an example in which such a grain al exists in a resource R1, then is derived in a2 in a resource R2 (derived from R1), then further derived in a3 in R3.
• the modification of the object b of the grain a2 is propagated towards the grain a3.
• the grain a3 contains the values al, b2 and c3.
• the modification of the object b (bl is modified in b2) of the grain a2 can not be propagated in the grain a3 57 .
• b2 and c2 go hand in hand, which means that replacing, in the grain a3, bl
• each grain downstream grain accepted can be removed (and thus become an implicit grain) in the modification of grain tree, if it reflects the content already 61 grain which is immediately upstream of to himself 62 .
• the grain nearest to the upstream in the same branch becomes it in its place.
• Figure 48 shows that, in the case where the grain a3 is rejected by R1 or R2, from a2, a new branch is created from the branch where the grains al and a2 are, to contain a3.
• the grains a of R2 and R3 can be deleted since they inherit the grain a of Rl composed of objects al, b2 and c3. 65
• Figure 50 thus presents a resource R containing an object (a) which itself contains two objects (b and c) example in which, the respective innertexts are as follows: • a: "I would like to read a beautiful book about ⁇ b ⁇ ⁇ c ⁇ »
• Rl the initial version of R (with the objects al, bl and cl corresponding to a, b and c).
• R1 is derived in R2, then R2 is derived in R3, and then in R3, "forward drive” (cl) is changed to “propelled” (c3), which results in the phrase "I would like to read a beautiful book on the first powered cars.
• the slot approach is advantageous because it considers the innertext to be globally atomic.
• the approach that consists in considering displacements or deletions of objects as modifications of themselves and not of their parent is much more advantageous because it allows to operate at a finer granularity (the advantage is that the parent object is not globally “frozen” when an object child of that parent is moved or deleted).
• the process will implement the slots or not.
• the activation of the slot option (respectively non-slot) can be automatic depending on the case as explained above.
• the rating (rating) of the owner of the resource containing each object selected by the user e; sstt maintained in the computer environment 72 These ratings are relative to said user 73 .
• the history of access to objects (or grains) 75 by the user can be modeled using a "context stack", where in theory to each object (which can be presented to the user) is associated a relevance score (regardless of the method used to calculate it) for the user at each navigation level, and when an object is non-existent in the context stack, it is considered a object whose score is zero.
• the system 76 adds a level to the context stack. 77
• the context score is an average of the non-contextual scores 78 at each level of the context stack, weighted according to the depth.
• the contextual score at the last level is: lambda.r + (1 - lambda) .s (lambda being a weighting constant between 0 and 1, in principle less than 1 A: the larger the lambda, the greater the importance of the past). Since we know for every alternative object the non-contextual score of each other object known in the collaborative server with respect to it, we can select the alternative object for which the non-contextual scores of the other objects with respect to they are closest to the navigation context (that is, the closest to the contextual scores at the last level of the context stack). Note that instead of considering all the other objects one can be satisfied with a (smaller) set of representative objects, for example categories, and select the closest alternative object from the objects representative of the context. 79
• Resources that make up an ERC can be • shared by a set of users (at least read-only, for example these resources can be the web pages constituting a corporate intranet),
• a nonshared resource must be imported, for example, received by e-mail, to benefit from the automatic replacement feature.
• it contains a newer object than - and co-identified 80 with - an existing object, then it replaces it. This is because the co-identified imported object is placed in the object modification tree and becomes the most elaborate object within the meaning of Rule 5.
• co-identified objects we include objects having the same discriminative description, within the meaning of Guha's articles, obtained by semantic negotiation.
• a newly created object plays the same imported object, with respect to its co-identified objects.
• an object must at least be characterized, in other words: the metadata that characterize it must be informed.
• the user interface is adapted to hide the meta-data description from the user.
• transclusion in the usual sense of the term, is inclusion by reference.
• a classic example is the application of the "img" HTML tag that allows you to include an image by reference.
• Transclusion consists of creating a view ("the result") of at least one object ("source”) and placing that view in another object ("the container”).
• source the object
• the container the object that contains the object that contains the container.
• the transclusion technology described here makes it possible to modify the result of transclusion. Indeed, the user must be able to modify the content of a derived page (as described so far).
• the user can define the modifications to be made by acting directly on the result of the transclusion, by using a common tool of manipulation of contents, for example the tool which allows him to manipulate the container (and its local contents) or the tool he would use if he wanted to change the source.
• a common tool of manipulation of contents for example the tool which allows him to manipulate the container (and its local contents) or the tool he would use if he wanted to change the source.
• the results of the actions he performs (such element is deleted, the content of another is changed, another is moved and modified ...) are recorded so to be able to find these changes automatically the next time the object is updated. For example if the user exchanges two parts of a transclusive object, when the content of this object changes at the source, the two parts will keep their new position but their content will always match that of the source.
• transcluded object we mean “object resulting from transclusion” (as opposed to source object) except when the context makes clear the opposite.
• Source objects can be remote. They are either identified directly or implicitly as a result of a search query. For example, the result of a query to a database can be included in a Word document.
• the source (of a transclusion) means “the source object or the set of source objects (of said transclusion)”.
• a presentation of the source will be visible at the location of the transclusion. In other words, whenever the containing object is opened or updated manually or automatically, the current (ie most recent) version of the source will be presented here. Being able to modify the result of the trance in the same way as modifying a local copy of the source 83 , but without losing the link with the source, is the paramount feature of the transclusion technology described here.
• Each object has an identifier.
• Locally created objects have an atomic identifier, which is a unique integer in the system.
• each transclusion has an atomic identifier, which is also unique.
• A the head of this identifier
• B the tail of this identifier
• transclusion A is considered on the one hand a set of objects "seen through” A, and on the other hand to a set of modifications (Differences) concerning these objects.
• the current version of the result of a transclusion is the result of the transclusion as it was presented the last time the page was displayed. This current version is maintained, and is typically updated by the system each time the user accesses it.
• the differences indicate the source (s) of this transclusion, as well as the modifications to be applied to it.
• the differences are based on the current version 6 and thus do not need to contain "in extenso" the contents and positions of the objects to be modified.
• the differences refer to the objects of the current version (that is, to their respective identifiers) to define the transformations that are applied to them. the next time that said idea page (or simply refreshed), these changes are re-applied to an updated version of the source, while using the content of said derived page (current version) to have the contents and positions of the modified objects. These changes include
• a special case is the following: when the user performs a transclusion, the algorithm, to perform this operation , will first create the transclusion but at this moment it is not yet accessible (because no object seen through this transclusion is still placed as a child of an accessible object.) The second step is then nothing more than a displacement of one of these inaccessible objects as a child of an accessible object.
• an implicit transclusion is said to contain no modification. Indeed, it will be said that such modifications will be treated by the transclusion by which this implicit transclusion has come. For example if an object ((1: 2): 3): 4 is modified, this modification will be associated with transclusion 1.
• the Differences node indicates the identifier of the transclusion, which is then referenced in a Transclude node, at the location of the result.
• the identifier of the result of this transclusion will be 10: 7. Note that the source can be identified by a reference or a query. 88
• This example also shows that to move and modify the same object (8: 6: 4: 3) two operators are placed in the object of the differences.
• FirstSentences could be selected by the user from an (extensible) list of operators at the time of the transclusion or afterwards by associating it with it.
• the user may request that the content of the source of a transclusion not be included at all, but that a simple hypertext link be placed as a result, pointing to the source (s).
• the Differences object in this case, would look like this:
• a reference or a (unilateral) relationship from one object to another is a transclusion whose result is neither constructed nor presented (nor even contains a simple hypertext link).
• an object is an XML element and the content of the object is the "innertext" of the XML element. Both attributes and children are considered child objects, but attributes with the same attribute name from different sources must be merged.
• each derived resource is transferred from the global content of the source resource.
• the method of transclusion can also be used to transclude, in a derived page, any object found on any page. This is how a derived page can be used to assemble objects in external pages.
• the "differences" associated with the transclusion result constituting the content of a derived resource may themselves include transclusions. The latter can then themselves benefit from the replacements and enrichments resulting from the replacements and enrichments of the source.
• Each object of the result of a manual transclusion benefits from the main benefits described here (ie, replacements and enrichments), provided that its source is in a resource managed under the same ERC.
• the said object will thus be automatically replaced by a replacement object according to Rule 5 and enriched with alternative objects according to Rule 6, applied to the said source.
• the additional objects obtained from the downstream of out-of-derivation transclusions are considered as alternative objects. Implicit transclusion, transclusi
• Each object having a composite identifier has a set of sources 90 represented by different (equivalent) shapes Ti: Si of its identifier, where Si is the source and Ti the transclusion by which it has transited.
• the sources of 4: 3: 2 are represented by 4: (3: 2) and (4: 3) :( 4: 2).
• T 0 S 0 of the identifier.
• Ti ': Si' be the transclusion-source pairs of S 0 .
• a composite identifier consisting of only two atomic identifiers will have only one source.
• set we include here the case of a set of a single element.
• transclusion means through a transclusion "higher” (encompassing); for example, transclusion 4 is higher than transclusion 4: 3.
• Rule 8 In the presence of several candidate sources for the content (or position) of an object, we prefer the one whose proximity is greatest (or the one whose distance is the smallest).
• a first method is based on the notion of "density" of identifier.
• d (X) the density of an identifier X.
• a density is of the form ⁇ S x d x where S x is a polynomial in s and d x is the weight of the atomic identifier x.
• the polynomial S x above is called the partial density of x in X.
• the density is calculated recursively as follows (s is a symbol without a defined numeric value):
• the density d (n) of an atom is d n .
• the density d (A: B) of a composite identifier A: B is (ls) d (A) + sd (B).
• a polynomial simplification algorithm consists in replacing all the products of sums by sums of product, then for each x to group the terms in dx .
• proximity is used because the larger the value, the closer the object is.
• the transclusion between descending objects of the transcluded enclosing object shall be defined as a shorter distance value to be fixed between these objects. objects.
• the "length" of a transclusion can be determined as follows. We give a length of 1 to non-implicit transclusions (thus having a single term in their identifier), a length a little smaller 1- ⁇ ( ⁇ tending to 0) to implicit transclusions having two terms, one still a little more small (l-2 ⁇ ) to transclusions with 3 terms, and so on. So we give the value 1- (w-1) ⁇ to transclusions with n terms (By term we mean the atomic identifiers composing the transclusion, for example (1: 2): 3: 4 contains four terms).
• the source is at a distance of zero. So when comparing a local change to a change from upstream, the same rule applies and the local change has priority over any other change propagation source.
• This algorithm will calculate as Y information (position + content) of a given object that the origin of this information (separately the origin of the position and the origin of content) 93.
• TJ F
• X will be placed (by convention) as the last child of TJ: F. Otherwise it will be put (by convention) just after TJ: B. [Iocal7].
• Each object must memorize the fact that it has already been processed by the local or global algorithm, respectively, so that each algorithm does not process any object more than once.
• X is the object on which the current pass of the global algorithm runs.
• X is a locally created object (and therefore has an atomic identifier)
• its contents and the list of its children are already known, so it just has to execute the global algorithm on its children.
• the origin of the information is of course just X.
• the origin of information for sources will typically be obtained by a recursive call to the local algorithm on each source.
• the local algorithm does not loop because it will always reach, by going back transclusions, objects providing their content locally, to the limit by reaching the objects not found in a result of transclusion.
• Each persistent query corresponds to a subset of this space, that is to say to a set of subtrees (represented by a set of abstract triplets).
• a set of concrete triplets i.e. • Table of Transclusions
• any transclusion is indicated in the Table of Transclusions, and for any result of transclusion, in the case where it is directly modified itself, the information of the existence of this modification is indicated in the Table of the Transclusions.
• Local Changes while in the case where it must be updated following an upstream modification, the information of the existence of this modification as well as the address of the modified object 98 are in the Table of Changes of the Upstream.
• the extension of the information manipulation tool gets its current version from the content server that hosts it. In parallel he asks the Upstream Changes Table if there have been any changes for this resource (and for which objects there have been changes), in which case this Table returns 99 addresses where the objects in question lie. Then, the extension of the information manipulation tool obtains these objects and assembles them, within the current version received for the resource in question, in order to obtain a new current version 100 .
• This information also contains the identifiers of all the ancestors of the corresponding object, so that if another transclusion indicated in the Table of Transclusions has as its source said corresponding object or one of its ancestors, another information is added in the Table of the Changes in the Upstream, and so on until there is no corresponding transclusion in the Table of Transclusions.
• Each new object change information resulting from a transclusion is added with the distance information between the source object and the result object.
• Each difference (be it a local change or a consequence of a change in upstream) may be characterized by the type of change, the identifier of the changed object, and the identifiers of its ancestor ...
• the latter is then communicated to the server hosting the resource R, so it replaces the previous current version, and that's Upstream Changes Table may indicate the corresponding entries for these changes, as the change in question is already taken into account in the current version and so do not go get it.
• this indication is deleted in the entry in question. added only if the distance with the s transclusion considered is less than the distance of the information if any already existing (in which case it replaces it).
• the information concerning the change of an object resulting from a transclusion only the first time, that is to say when the The entry corresponding to the change has just been created in the Table of Local Changes.
• the Transclusions Table when a new transclusion is inserted into the Transclusions Table, the information for all the objects contained in the result of the transclusion are inserted into the Upstream Changes Table along with their creation date.
• a modification date is stored (and maintained) with each entry in the Local Changes Table. With each access to a resource, the date contained in the Upstream Changes Table is compared with the date of the source change in the Local Changes Table.
• Figure 54 presents a second scenario.
• the push algorithm is interesting when upstream changes are less frequent than downstream accesses (or refreshments), especially when the source is inside the system and therefore the source 102 can automatically be informed when it is changed.
• Figure 55 shows the evolution of the current versions during an upstream change.
• the first line shows the state before modification.
• the second line the upstream is modified, and the modification is passed on to the intermediate object but not the downstream object.
• the last line shows that the change is observed during a request downstream (the contents of the intermediate object being copied downstream).
• Figure 56 uses the same scenario as the previous figure. It can be seen from the first line that the object downstream contains a reference to the object upstream, indicating that this content will have to be refreshed (in pull) at each request.
• Both the pull algorithm and the push algorithm can be implemented either by a centralized architecture (with a collaboration server) or by a cascade architecture.
• the collaboration server manages the transclusion tables and the local change tables (describing the difference objects for the transclusions).
• the push method it is the content servers or the extension of the information manipulation tool that inform the collaboration server of a change to be made in these tables, whereas in the case of the pull method
• These tables function as a cache, the collaboration server going, at each request, to query the content servers.
• the algorithm is performed entirely on the collaboration server, and the content servers do not communicate with each other.
• the cascading method works as follows. We no longer use a collaboration server, and it is the content servers that each manage their tables of transclusions and local changes.
• the transclusion tables 103 indicate the servers to contact in case of local change, whereas for transclusions in pull, the tables indicate the servers to be interrogated during a request.
• a content server knows the results of the transclusions in push of which it contains the source, and the sources of the transclusions in pull of which it contains the result.
• the centralized architecture has the advantage that if a content server is inaccessible, the difference tables stored in the collaborative server are used and the algorithm still works, at worst with a version that is not the most recent. with some missing content.
• the advantage of cascading architecture is that the processing is distributed and can therefore be more efficient in the presence of complex transclusion structures.
• the centralized method is used, and at each change of collaboration server, the cascade method is used.
• Figure 58 shows an example with three collaboration servers. Rectangles are collaboration servers, and small circles are objects. Large circles group collaboration servers with the objects they process. The arrows show transclusions.
• Continuous double lines represent the parts of the algorithm that work centrally, while interrupted double lines represent cascading communications.
• the server in the middle gives an example of a degenerate collaboration server that only matches one object, which is the case of an object that only works in cascade.
• the transclusion whose result is c.
• This causes the simultaneous appearance of 5 and 6.
• the order 5 ⁇ 6 is chosen to correspond to the order of their immediate sources 1 ⁇ 3.
• the operation of the object replacements is the same as explained above, that is, in a set of objects having the same created source, the most elaborate is the one that has been created. the latest, and that provides local content. If an object is modified locally but at least one more elaborate object having the same created source was created later and is incompatible with the modified content 104 , then the first more elaborate object (and subsequent ones in the same branch) is (are) moved to a new branch (Rule 7). 105
• the replacement object for a given object is the newer content having the same source created (this has the advantage over the other method that two users can alternatively contribute to the same object while remaining in the same branch).
• Figure 60 illustrates three scenarios.
• the tree structure represents the transclusion structure (each object is image by transclusion of the one pictured above it, and all objects, before rejection, are in the same branch).
• the hatched circles represent the denying object (the replaced object) and the dashed circles are the rejected object (the replacement object). Traced lines indicate the region that will be moved to a new branch.
• FIG. 63 extends "Case 2" from the example presented in the "Replacing / Enriching Grains” section. The objects of this figure are introduced in FIGS. 61 and 62.
• FIG. 61 shows that, in the resource R, the grain a is now included in an object d and, within the latter, it is reproduced by transclusion (the grain a is transposed to the right in Figure 43). 107
• Figure 62 shows that R1 (this is the resource R of Figure 61) is derived at R2 and that R2 is derived at R3. These two derivations give rise to transclusions "2" and "3", respectively.
• the transclusion "2" of d results in 2: d
• the transclusion "3" of 2: d itself results in 3: 2: d.
• this same figure 62 presents the transclusion "1" of the grain a in the object d, which gives rise to the implicit transclusions "2: 1" and "3: 2: 1" within 2: d and 3: 2: d respectively.
• the identifiers of the objects contained in d, 2: d and 3: 2: d are prefixed according to the transclusion that gave them birth.
• objects that are the result of several transclusions of which at least one is implicit have several possible sources. It is always from the nearest source that we will propagate the changes to them.
• Figure 63 shows the situation after the last step (i.e. after step 3 above).
• dot-covered objects represent objects in the table of changes from upstream (which are therefore modified as a result of propagation of local changes).
• the collaborative server does not memorize the values of the objects but only their identifiers, in the collaborative server can be associated with these identifiers a code (checksum) by the method Cyclic Redundancy Check (CRC) known per se or a similar method.
• CRC Cyclic Redundancy Check
• one grain (or objects belonging to no grain) can be the "most developed”.
• Figures 64 to 88 show transclusion operations as part of a file explorer, in this case in Windows Explorer.
• each object is potentially a container 111 in the sense that it can contain other objects (child objects).
• a transclusion 112 has the effect: either creating a new object that will contain the result of the transclusion (as described so far) o be the "fusion" of his result with a pre-existing object that possibly contains itself pre-existing container objects; • and that each container can be specified constraints (or preferences) with respect to the properties of the objects it can receive.
• the source object's (innertext) value replaces the destination object's (root node) value, and its children are automatically placed in the contained containers. in the destination object and whose associated constraints are compatible with the properties of said child objects.
• a "pick-up" container is created and said object from the source is placed directly therein.
• Figure 89 illustrates a transclusion-merge of directories (typical container objects) that are rearranged so that the contents of the A and C directories, as well as the contents of the directories themselves contained in A, go to the A 'directory. , that the contents of B go into B 'and that all the other objects go into C. 114
• FIG. 114 shows an example where the directory names are properties (referred within the constraints associated with the containers located at the destination of the transclusion). Other properties such as the date of creation or last modification can for example also represent such properties.
• Figure 90 shows an example where: to automatically place, in a document containing container objects (such as cells in a spreadsheet spreadsheet), links to the documents contained in the source of a transclusion, based on properties of these.
• the advantage of such transclusions is that when a new object is added to the source is automatically propagated to the right location at the destination; when a property of an object is changed at the source, it can be moved from one destination container to another (depending on the constraints associated with them); and when a constraint of a destination container is changed, its contents may be moved to another destination container.
• domain of a container, the set of all possible objects having properties compatible with the set of constraints associated with this container.
• we call the domain of an object the set of values compatible with its properties.
• a metric is automatically associated with the width of the domain of each container, and in the case where several containers can receive an object in question, the selected container is the one whose domain is the smallest.
• the child containers inherit the properties of their parents and add (by D) their own properties.
• the transclusion method consists of: 1. searching for each source object 116 all the destination containers whose domain is equal to or wider than that of the source object in question;
• the child objects can thus be placed automatically in the destination object of a transclusion.
• the domain of a container can be expanded with the properties of the objects that the user places there "manually".
• This method makes it possible to give the containers the properties of the objects inserted therein, without mentioning these properties explicitly. So it's kind of a very simple method of machine learning.
• Other options Before expanding the recipient container, the user is presented with the option to restrict the domain of the placed object. Finally, in the case where the object belongs to a "class" (in the taxonomic sense) different from the class of the container, we can make the class of the object subclass of the class of the container. Object placement becomes a tool to help create a taxonomy.
• Another way (or a complementary way) to proceed is to base the learning on the content of the inserted objects (e.g., naive Bayesian learning).
• naive Bayesian learning e.g., naive Bayesian learning
• This example further implement a transformation that replaces chaqe source document by linking to it.
• a third method is to retro-propagate the objects, that is to say to propagate them in the opposite direction of the transclusion-fusion. This is necessary especially when a modification representing a replacement or alternative object must be propagated upstream.
• the method includes an additional step of storing an association with the source container. When all objects in a destination container come from the same source container, any new objects added to the destination container will automatically be back-propagated to the same source container. In other cases, select a source container that includes the domain of the destination object to be backpropagated and / or which has the largest intersection with the domain of the destination object to be backpropagated.
• the owner of an object can constrain possible transclusions from this object.
• conditions or options to choose such as from the following can be presented:
• the object can be transcluded and modified but an authorization for republication must be sent to the owner before republishing it and it may be republished (pending the response) as long as the answer is not a refusal o It can not be republished only once an acceptance response has been received - note that in this case the law allows in some cases that a short quotation be published; an automatic system for such a publication will be implemented and automatically replaced by normal publication as soon as the acceptance occurs.
• the owner downstream of the transclusion can force the publications upstream.
• the upstream owner can be proposed including the conditions or options to choose from the following:
• the contribution of the downstream can be further modified upstream, but republished by the upstream only after emission by the upstream of a request of acceptance from the downstream o and after reception of the acceptance o or pending acceptance and until a refusal is received.
• Customization is defined as a function that is based on objects 118 (content and position) and / or metadata associated with them, or other data from the environment, as well as groups of objects. targeted users, returns the content and position of the same or other objects. A customization can also take as input the result of another customization.
• Each object can in particular be identified by an identifier or by its position in the structure of the resource.
• An encryption mechanism allows the conditions that are part of the customizations to be respected. For example, in the case where a resource can be derived we will ensure that a certain object (such as an advertisement) that it contains can not be modified. We will also ensure that these conditions are inherited from one transclusion to another.
• Figure 91 shows the architecture of a system implementing this.
• a set called Personalization Server itself composed of the following servers:
• a Collaborative Server that manages in particular the transclusions and other processes described in this document
• a Key Server that stores all keys for encrypted content and is responsible for communicating with the Authentication Server to authenticate the user;
• FIG. 91 shows the client part (plug-in) that includes
• a Customization Client It is a component that is responsible for submitting the "credentials" (login / password) to the Key Server, obtaining customizations from the Collaborative Server and applying them to the objects specified by the Manipulation Tool Extension; to encrypt (during a publication) the desired objects, and to decrypt the encrypted objects transparently.
• the Manipulation Tool Extension which is responsible for providing a user interface to choose a customization to apply; take the user's credentials and communicate them to the Customization client; obtain content from content servers; in the event that content is published, transmit the content and credentials of the user to the Key Server.
• the client part (plug-in) is authenticated by the Key Server and the Collaborative Server as a condition for their operation. 119
• the Manipulation Tool Extension gets the contents of the current version from the corresponding Content Server
• the Manipulation Tool Extension asks the Customization Client for the customization that must be applied to the resource, transmitting to it the content of the resource (which will need to be customized / decrypted) and the credentials of the user.
• a pair of public-private key is used for each installation of the client part.
• the public key is stored in the Key Server and the private key is stored in the Customization Client.
• the Customization Server can check the checksum (or other fingerprint) of the executable code of the client part.
• the client gets the registration information (such as the software owner, etc.) and uses the generated code (from the machine's essential hardware specifications) to read its private key and then crypt the registration information with the private key and sends it to the Key Server for authentication in a session.
• the Key Server decrypts the information using the public key it has in its database and verifies the checksum and registration data for that client. If successful then a secure channel is established between the client and server using a protocol such as SSL. 3.
• Customization Client requires keys to Key Server
• the Key Server checks the credentials of the user by contacting the Authentication Server 5. In the case of successful authentication the Key Server transmits the keys to the server.
• Customization Client requests from the Collaborative Server the customizations that must be applied to the resource 7.
• the Customization Client requests the required objects (determined in step
• the Customization Client then applies the customizations, decrypting the encrypted contents.
• the result is passed to the Manipulation Tool Extension that presents the result.
• the Content Server the content of a resource such as a document is generated dynamically from query (s) to a database (or other type of data organization), the process will be implemented so that the user can manipulate and collaborate at the level of the resource presented to him and that the resulting changes are reflected in the database (transparently).
• the difficulty lies in identifying such objects made available to the user. If it is a relational database, we will consider each row of the given database and each field (each column of the table in question) as shown in Figure 92. For each line, the identifier of the "object" (in the sense of the present description) in question may for example be the primary key. Similarly, the object identifier for the fields can be the composition of the primary key and the name of the column of the table in question. 20
• An additional plug-in is then required at the Content Server level to inject, by means of "invisible" tags into the presentation (such as ⁇ A> in HTML), the information of the identification of the object corresponding to the data of the database.
• any request to the Content Server (ultimately intended for the database) is in fact addressed to this component and the latter manipulates the request so that the result in return contains in addition the object identifier of each data returned by the database.
• the owner of a resource can accept or reject replacement objects and alternative objects presented in this resource. In the case where an object (replacement or alternative) is refused, all the other objects of the branch in which this object is found are also implicitly rejected.
• the information manipulation tool illustrated here is a web browser with an extension capable of assembling replacement and alternative objects in the web pages.
• the same principles can be implemented on any other information manipulation tool and to manipulate other types of resources.
• Figure 93 schematically shows the web browser with a toolbar (which represents the extension in question).
• the user can thus enter a URL "www.site.org/page” and click on "Send” to display on the screen the Web page corresponding to this URL, within the framework of an ERC "El” (which it can select from a drop-down list).
• Figure 94 shows the Web page in question, displayed as part of the ERC, with replacement or alternative objects (schematically represented by rectangles), as well as an "Edit” button in the toolbar.
• Figure 95 shows the browser schematically after the user has clicked the "Edit” button and has made changes. This button is now replaced by a "Save” button.
• the user clicks on the latter in case he is the owner of the page in question, the system gives him the choice to save the changes either in the same file or as a new page derived in a file. different to indicate; in the case where the user is not the owner of the page in question, it must necessarily save it as a new derived page.
• Figure 96 shows schematically that the user has the option to accept or reject replacement and alternative objects.
• the user can accept / reject such an object by positioning itself on it and • selecting it and then clicking on "Accept” or "Reject" in the toolbar
• the "Send" button is not necessary if the sending is done in a conventional manner using the Web browser and if not to view the page through an ERC can for example select "no collaborative resources" in the drop-down list.
• an alternative object can be automatically determined when the user registers a derived resource in which the object in question has been replaced by said alternative object; and the replay of a replacement object can be determined automatically when it has been replaced by the original object (for example by using the left-pointing arrow mentioned in the previous paragraph).
• the user interface also makes it possible to highlight the objects (reifications) and grains, or to create them.
• ERC usage patterns are for activation or not (to propagate downstream updates across transclusions and other contributions).
• the user interface allows users to select default ERCs first, then for each access to a resource to specify the respective modes of the ERCs (however these modes persist by default from one access to another).
• the user is offered a screen as follows consisting of two parts: First part: 0D (checkbox can take one of two values: checked or not) -
• FIG 97 presents a resource R2 R.1 in the ERC El which transcludes (by the transclusion T2) an object 'c' of the resource Sl in the ERC E2 and E3.
• the R2 resource is opened by the user in a "secret" mode for the ERC E3, then T2: d is changed.
• Another question for the user may be what are the most recent and / or relevant resources for him that other users have seen in the CRFs he is using.
• the user can ask the Collaborative Server to provide both relevant (and / or recent) resources and CRFs from those he / she has the right to use that are relevant to visit these relevant resources.
• users may also want to discover each other (for example to meet or exchange information) from the resources / ERC they will respectively visit or manipulate (see also the rating approach of users described in the section "Method of sorting alternative objects by rating (rating)").
• the Collaborative Server Since the Collaborative Server knows which user accesses which resource in which set of collaborative resource (these triplets are stored), it can simply apply collaborative filtering methods to get answers to the four types of questions above, including by counting to determine the proximity of the users in terms of the number of resource / ERC couples that they have visited / used in common and to exchange between their close users their (good) respective experiences.
• the proximity of the users to each other in terms of the number of 'resource / ERC' pairs that they have visited / used in common
• the ERC represents an effective means of collaboration to write / compose a work to several contributors. Simply that all contributors share the same ERC 125 for each contributor can further develop resources produced by others.
• FIG. 100 An interesting application is the preparation of a future publication. Its principle is illustrated in Figure 100.
• the rectangles (Rl, RI l, etc.) represent resources; the arrows represent derivations; the upside-down "L" shaped regions, framed by lined lines, represent ERCs (E1, E2 and E3).
• any update made upstream is reflected downstream; For example, if the Template template is improved, all the publications benefit because they are downstream, and conversely any proposal submitted by the collaborators of a publication that is submitted (downstream). will be seen collaborators of the subsequent publication (which form another branch downstream) only if it is accepted. Indeed, employees of an issue R do not see the contributions of employees of the publication R-I before they are accepted, since they are not members of the same ERC.
• the log creates a new ERC (The log can also use a pre-existing ERC).
• a clickable link makes it possible to download an extension (plug-in) to the tools of manipulation of current information such as the current browsers Internet Explorer or Firefox. From this download and following the automatic installation of said extension, said ERC is automatically activated in the user information manipulation tool. In the case where the extension is already installed, the ERC is directly activated without the need for downloading or installation. All this is done only by a simple click of the user.
• An advertising content (object) is included in each resource (Web page) and a non-modifiability constraint is associated with it (see later sections "The Web read-write” and "Association of constraints to objects").
• another method consists in that the tool handling information filter the content on immutable objects (such as advertisements) in the case where the value of the counter 127 transclusions this object exceeds a certain threshold (threshold which of course can be a function of the payment already made or planned to be made to the service provider delivered by the collaborative server).
• a certain threshold threshold which of course can be a function of the payment already made or planned to be made to the service provider delivered by the collaborative server.
• Wikis are sites where visitors can change pages as desired. Wikis are particularly well suited to exchange ideas and articulate and develop them together. They are typically used to cooperate on collective projects, encourage contributions and accelerate the flow of information.
• a link added by an ERC user to a derived resource from a starting resource may cause a user (the same or another) of the same ERC to visit the site. resource pointed by this link added.
• a method of automatically adding, on a resource derived from said pointed resource, a link (“reverse link”) that can bring to said starting resource a user of the same ERC visiting said pointed resource may cause a user (the same or another) of the same ERC to visit the site. resource pointed by this link added.
• the set of reverse links can for example be automatically presented to the user in a (sub) window, adjacent to the (sub) window presenting the content of the visited resource.
• the essential idea is that the information manipulation tool automates or facilitates the issuing of a request to request permission to (re) publish content, and then manages the publication process pending the response to such a request. request.
• the activation of automatic authorization means can be triggered as soon as a resource is derived 129 for publication, and the publication will start automatically at the latest when the authorization arrives.
• Pending permission to publish a mechanism to publish only citations (restricted extracts) taken within reasonably (legally) permitted limits may be implemented.
• resources include or combine contact metadata from a decision-making authority.
• Meta-data may be associated with an object to selectively control its modification and / or its accessibility by third parties within derived resources.
• metadata of broadcast constraints may specify that (as already mentioned) given objects may be reproduced (with or without modification allowed) provided that specified subparts are included without modification.
• the resource containing-or associated with-metadata can be structured as an object tree, so that in association with at least some of the nodes of the tree, a metadata of broadcast constraint is stored, and a broadcast constraint meta-data item at a node applies to the child nodes of the node in question.
• the information manipulation tool When accessing a resource, if the user has not expressly specified at least one ERC (and / or collaborative server) for that access, the information manipulation tool sends a request to the (x) collaborative server (s)) configured by default, to obtain the identifiers of replacement objects and alternative objects.
• each collaborative server is able to search for other collaborative servers that can provide the required identifiers, and to return these identifiers 130 to the information manipulation tool.
• the information manipulation tool is thus able to obtain the required identifiers from any collaborative server, the latter acting as an intermediary if it can not answer itself. It is therefore not useful to block, especially for purposes of censorship, access to some 131 collaboration servers since the others will take over.
• Figure 101 illustrates this process: instead of receiving the identifiers of the replacement objects and alternative objects from a collaborative server ES1, because the connection with ES1 is cut off (which is represented by the big X in Figure 101 ), the information manipulation tool gets them from an ES2 collaborative server with which the connection is possible.
• ES2 queries the collaborative servers that it knows, which in turn relay the request to the servers they know themselves, and thus immediately, in a conventional peer-to-peer process known per se and that is not described here more.
• the Collaborative Server is able to return the replacement object and alternative object identifiers, as well as their respective ERC identifiers, so that replacement object and alternative object identifiers can be used. selectively, that is, only if the CRFs that provide them are suitable for the user or as a member)
• Servers can aggregate several channels and republish them
• the ⁇ content> tag (in the ⁇ item> tag) for the content - for example, this tag corresponds to both the ⁇ title> and ⁇ description> tags of RSS 2.0; 133
• tags and attributes presented are "abstract" in the sense that they correspond to different tags / attributes of existing protocols. In reality, it will be the tags and attributes of the existing protocols that will be used and not these.
• PSE means "PSE and ASE” except in the opposite sense. equivalent to those above will be but ignored (that is, will not be interpreted) by the PES protocol.
• PSE will typically include the implementation of the most common existing protocols such as RSS 2.0, RSS 2.0 with SSE, RSS 1.0 and so on. so that their respective tags (and attributes) are interpreted in their respective source protocols.
• RSS 2.0 Really Low-Sidelity
• RSS 2.0 with SSE
• RSS 1.0 and so on. so that their respective tags (and attributes) are interpreted in their respective source protocols.
• PSE does not recognize a tag it ignores it but retains it in the channel so as not to lose information for other servers participating in the network.
• the PSE protocol first implements the specifications of the protocol (s) of the source (or of a protocol chosen by the default user in the case where the server is the source itself) and then add the PSE elements (as brothers or children of elements
• PSE elements are declared in a separate namespace ("namespace" in English terminology), and it is expected that they will simply be ignored by other servers that do not recognize them (ie which does not process the elements belonging to the namespace).
• namespace in English terminology
• a copy of the source elements is also kept so that subscriber servers that do not understand PSE can still interpret the source protocol and thus interoperate with PSE.
• the PSE protocol performs the processing specific to the source protocol (s) 135 so that the server appears (to the subscriber servers that only include the source protocol) as a server of the source protocol .
• Figure 102 shows different servers publishing content in different protocols.
• the server that implements PSE can interoperate with these various protocols and add the PSE extension to the respective channels. For example, it takes 'Channel 1' from 'Server 1' which uses RSS 2.0 with the SSE extension, adds the PSE layer in 'Channel 1' and republishes it. It also publishes 'Channel 3' in OPML 1.0 + SSE format (the format can be chosen by the user who creates the channel) to which subscribes "Server 4" which recognizes this protocol.
• This figure also illustrates that in the PSE protocol, the source protocol is retained so that those who understand the source protocol can subscribe to the republished channel.
• 'Channel l' is republished by 'Server 3' using the same protocol as the source, namely RSS 2.0 with SSE, so that 'Server 5' which understands RSS 2.0 with SSE can subscribe to 'Channel l'.
• “Server 7" it uses the ASE protocol and can subscribe to all the channels published by "Server 3" but by ignoring the elements in PSE.
• the PSE extension to sharing protocols allows the user to transcribe from one source an item or part (of the content) of an item.
• the user may mark a portion 136 of an item as an object; the latter can then be transcluded in another channel or in the same channel. The characteristics described so far of the transclusion remain valid.
• source protocol means of the protocol of the source of the item republished or the protocol chosen by the user to the original items.
• This element can be in the ⁇ item> element or in the ⁇ channei> element at the same level as ⁇ item>.
• this ⁇ pse: part> element appears in the ⁇ item> element to encapsulate the created object.
• an ⁇ item> element is transposed into another channel at the same level as an ⁇ item> element, then it is inserted into the ⁇ channei> element. Note that the position of this element counts.
• Tid This is a required attribute that gives the identifier of the object according to the PSE protocol.
• src-tid This is an optional attribute that gives the Tid of the nearest modified source. During synchronizations, the mechanism for updating this attribute is as follows: the src-tid attribute is compared with (if any) the src-tid attribute of the source element in order to take its value if it is closer. In the case where there is no src-tid attribute, this means that the source does not itself depend on another source.
• changetype This is an optional attribute that is added when the object is modified locally. It can take its value among the following: CREATED, MODIFIED,
• Figure 103 shows two streams (channels) RSS, Server 1 and Server 2, and the fact that a Server 1 item is transposed to be placed between two existing items of Server 2.
• the new ⁇ pse: part> element has the attributes tid, src-tid, and changetype.
• the tid is the identifier of the object in question which, in this scenario, is the result of the transclusion.
• the 'src-tid' is the identifier of the nearest modified source. Only one of the src-tid and changetype attributes will be present because when the object is modified locally there is no more source.
• the PSE Server includes not only the implementation of PSE but also the implementations of other protocols that it understands (such as for example RSS 2.0 and SSE). Thus, although these elements are ignored by the PSE protocol, they are taken into account by the implementation of their respective original protocol in the PSE Server itself.
• the implementation of the process comprises means for determining for example semi-automatically (or simply by asking the user) the modification in question is dependent on the context or not. Keeping item '13' or not will then be linked.
• Context dependent essentially means that the modification cites at least part of another item of the same channel. for the use of other protocol. Any later will be done in 'T 1 : 13' and in '13'.
• the 'changetype "modified"' attribute is added and the 'src-tid' attribute is removed:
• Item '13' will continue to synchronize with its source (by the original protocol), while the element 'T 1 : 13' will no longer receive updates from the source since it is modified locally.
• Figure 104 shows a transclusion whose result is placed within the content of another item.
• Figure 105 presents the case of the transclusion of only a part of the content of an item, this part ('113') being now the source object to be transcribed within the content of another item ('22') .
• Figure 106 shows the case of an internal transclusion in Server 1 that gives rise to an implicit transclusion 141 in Server 2.
• the notifications are only made to the immediate sources, which themselves propagate to their own sources and so on. It has not need to send notifications to all possible sources 147.
• the XML tags include the following 148 :
• This tag is placed at the highest level, that is to say at the same level as the item tag. It is present for each item that (or if part of the item in question) has contributions.

Landscapes

• Engineering & Computer Science (AREA)
• Theoretical Computer Science (AREA)
• Databases & Information Systems (AREA)
• Physics & Mathematics (AREA)
• General Engineering & Computer Science (AREA)
• General Physics & Mathematics (AREA)
• General Health & Medical Sciences (AREA)
• Health & Medical Sciences (AREA)
• Computational Linguistics (AREA)
• Audiology, Speech & Language Pathology (AREA)
• Artificial Intelligence (AREA)
• Data Mining & Analysis (AREA)
• Bioethics (AREA)
• Computer Hardware Design (AREA)
• Computer Security & Cryptography (AREA)
• Software Systems (AREA)
• Document Processing Apparatus (AREA)
• Storage Device Security (AREA)
• Information Transfer Between Computers (AREA)
• Stored Programmes (AREA)

Applications Claiming Priority (5)

Publications (1)

Family

ID=36587242

Family Applications (1)

Country Status (3)

Families Citing this family (69)

Family Cites Families (20)

• 2006
  • 2006-04-12 EP EP06725740A patent/EP1920358A2/de not_active Withdrawn
  • 2006-04-12 WO PCT/EP2006/061567 patent/WO2006108865A2/fr not_active Ceased
  • 2006-04-12 US US11/911,340 patent/US8442996B2/en active Active
• 2013
  • 2013-05-13 US US13/893,264 patent/US9076015B2/en not_active Expired - Lifetime

Non-Patent Citations (3)

Also Published As

Similar Documents

Legal Events