EP1920358A2 - Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefor - Google Patents

Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefor

Info

Publication number
EP1920358A2
EP1920358A2 EP06725740A EP06725740A EP1920358A2 EP 1920358 A2 EP1920358 A2 EP 1920358A2 EP 06725740 A EP06725740 A EP 06725740A EP 06725740 A EP06725740 A EP 06725740A EP 1920358 A2 EP1920358 A2 EP 1920358A2
Authority
EP
European Patent Office
Prior art keywords
object
objects
resource
characterized
user
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Withdrawn
Application number
EP06725740A
Other languages
German (de)
French (fr)
Inventor
Enrico Maim
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Maim Enrico
Original Assignee
Enrico Maim
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to FR0503612 priority Critical
Priority to FR0507016 priority
Priority to FR0509001 priority
Priority to FR0600213 priority
Application filed by Enrico Maim filed Critical Enrico Maim
Priority to PCT/EP2006/061567 priority patent/WO2006108865A2/en
Publication of EP1920358A2 publication Critical patent/EP1920358A2/en
Application status is Withdrawn legal-status Critical

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60Protecting data
    • G06F21/62Protecting access to data via a platform, e.g. using keys or access control rules
    • G06F21/6218Protecting 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/6227Protecting 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/21Design, administration or maintenance of databases
    • G06F16/219Managing data history or versioning
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/90Details of database functions independent of the retrieved data types
    • G06F16/95Retrieval from the web
    • G06F16/958Organisation or management of web site content, e.g. publishing, maintaining pages or automatic linking
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/20Handling natural language data
    • G06F17/21Text processing
    • G06F17/22Manipulating or registering by use of codes, e.g. in sequence of text characters
    • G06F17/2229Fragmentation of text-files, e.g. reusable text-blocks, including linking to the fragments, XInclude, Namespaces
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F17/00Digital computing or data processing equipment or methods, specially adapted for specific functions
    • G06F17/20Handling natural language data
    • G06F17/21Text processing
    • G06F17/22Manipulating or registering by use of codes, e.g. in sequence of text characters
    • G06F17/2288Version control

Abstract

The invention concerns a method for accessing a resource in a computer environment, the resource comprising a set of objects. The invention is characterized in that the computer environment is adapted to store in association with at least one object of said resource at least one modified object, in that said computer environment comprises means for storing in association with such an object information concerning degree of elaboration, and in that it includes the following steps: identifying, for each object of the resource to which corresponds at least one modified object, based on data concerning degree of elaboration, at least one most elaborated version of said object; assembling the objects thus identified for display in the resource. The invention also concerns other methods for accessing to resources as well as resources structured therefor.

Description

Title: "Procedures for access to resources modifiable by users in an IT environment, and structured resources for this purpose"

The present invention relates generally to the field of collaboration between users in an IT environment in which resources, obtained by assembling objects can be accessed, derivatives, supplemented, modified, etc. by these users.

A typical example of resource is a web page accessible through the Internet, but the present invention is not limited to this type of resource. already known, including previous patent publications in the name of the Applicant, techniques to access resources, modify, etc. to allow users to gradually enrich the content of these resources, and build personal versions of these, which other information can be added. The applicant has also proposed techniques for determining the adequacy of resources according to their environment in terms of citing resources and cited resources.

The present invention is primarily intended to provide methods of access to resources, processing or according to user customization resources, and creation of new resources, where we can integrate degree of development of information resources, so as to provide priority to users prior information more elaborate, as opposed to other less elaborate information. Another object of the invention is thus to determine which information objects should be replaced or enriched (by alternative objects) during the presentation of a resource to the user.

The invention thus provides new means of synchronization and enrichment of information covering all formats, both text and images that the media, including RSS feeds and "podcasts" (audio, video). Another object corollary of this invention is to provide access to resources processes, processing or according to user customization resources, and creation of new resources, in which the owners of the resources of origin may have an influence, especially in terms of right of modification and distribution, the resources derived therefrom. Thus the present invention provides in a first aspect un_grocédé to access a resource in a computer environment, the resource comprising a set of objects, characterized in that the computing environment is adapted to store in association with at least one object of said at least one modified resource object, in that said computing environment includes means for storing in association with such an object degree information developed, and in that the method comprises the steps of:

- identify, for each object of the resource which corresponds to at least a modified object, from the information of degree of elaboration, at least the more elaborate version of the object,

- assemble the objects thus identified for their display in the resource. Some preferred but not limiting aspects of this process are:

* The information of degree of elaboration of an object derived from the sequence of changes in the object, in that it is provided in the modification of an object by a user a step allowing other users refuse the modified object, and in that the assembly step is carried out with a version of the object selected according to the presence or absence of rejection. The method comprises, when lifiée an object is rejected, the creation of two branches containing two alternative versions of the object, namely the amended and unamended.

* The assembly step of a resource including a certain version of the object in question is made by reporting the existence of a version or alternative versions of said object.

* The process further comprises a step of selecting, by a user accessing a version of the resource, in some alternative version of the object.

* More elaborate versions of objects are formed independently for different alternative objects in each branch.

* The method further comprises the implementation of calculation means pertinence of scores of different alternative versions of objects to selectively present the most relevant versions.

* Multiple versions of a resource can be generated by users, and that in the assembly step is proposed by default the version of the object based on the version of the resource.

* There is provided a step of inhibiting the use of an object in the assembly of a resource if a given condition relative to the object or another object of the resource to be assembled is not fulfilled. * The contents of an object whose use may be inhibited is encrypted, and in that the inhibiting step comprises the inaccessibility to a decryption key.

* The given condition is a condition of presence of at least one subject to another resource.

* The given condition is a non-changing condition of the object present. * The method is implemented in a computing environment comprising:

- at least one content server adapted to provide content items can be assembled to form resources,

- a collaborative manager capable of managing versions of resources and versions of objects they contain - in at least one user station, an extension (plugin) a tool of manipulation of objects and resources capable of communicating with the working manager, and in that it comprises a step of verifying the authenticity of the extension by the collaborative manager. * IT degree of development is able to take one of two values, namely "most developed" or not.

* The identification step includes searching for objects (OR; OA) whose degree of development has the value "most developed" among the downstream objects successively changed from the object in question from the accessed resource . * The identifying step comprises searching for objects of higher degree of development at a boundary among the objects downstream successively changed from the object in question from the accessed resource.

* Research includes research degree objects (s) the drawing (s) higher (s) are browsing objects upstream changes which the object in question was obtained. * If the identification step has identified several more elaborate objects, it is provided in the step of assembling objects an addition sub-step to the resource of information signaling the existence of such multiple objects (OA).

* The selected object to the assembly in the resource is the most developed nearest downstream object in succession. * In response to object change instructions received from the user, the assembly step is adapted to be used successively for the assembly of the more elaborate objects sorted by another criterion such as a notation. * The method is adapted, in response "; tion of selection by a user, to be used for assembling an object designated by said instruction.

* The process further comprises a step of scoring the adjustment of the object in accordance with a selection instruction of this object by the user. * The step of assembling is adapted to be used for assembling a selected object according to another criterion such as a rating among all the more sophisticated objects.

* The process is implemented in combination with a pre-existing content server with time management means of object versions and that the step of identifying the most elaborate version of an object is implemented versions from information provided by said time management means and a user input information resource for accessing the different versions, and in that it further comprises a presentation step of the current version of object in the content server. According to a second aspect there is provided a method implemented in combination with storage means accessible in a computer environment to maintain update object graphs may be assembled to form resources available in the environment, characterized in that the storage means are adapted to store in association with these objects information of degree of elaboration, in that the method comprises the following steps:

- detecting the change of an object by a user,

- identify resource owners containing the corresponding objects in the upstream,

- towards these owners a proposal for acceptance or rejection of the amendment,

- waiting for a response of the owners,

- based on the contents of at least the first response, adjust the information of degree of elaboration of the objects. Some preferred but not limiting aspects of this process are:

* IT degree of development is able to take one of two values, namely "most developed" or not.

* The process further comprises a step of, in response to detecting the change of an object, to temporarily adjust the information of degree of development objects, this adjustment may be upset or confirmed at the end of the least the first response of the owners.

* For a first response acceptance of an owner, we apply the change in the resource owner said.

* When responding refusal of an owner, then the adjustment step gives the object immediately upstream of the modified object a highest degree of elaboration.

* The process further comprises, during a refusal response, adding to the graph of a branch containing an alternative version of the object consisting of the object including the modification.

* The process further comprises, during a denial response of a change made to an object that is not the most elaborate and in case of incompatibility of the modification with at least more elaborate object, adding to graph of a branch containing an alternative version of the object consisting of the object including the modification or containing the incompatible objects and modified objects from them. According to a third aspect of the invention there is provided a method of creating a new resource from an existing resource that was accessed within a computing environment, characterized in that it comprises the following steps: - detecting modifying an existing otr rce by a user,

- in response to this detection, create a new resource with the same content as the existing resource,

- apply the changes to the object from said another resource that corresponds to the subject of the existing resource for which the change has been detected.

Some preferred but not limiting aspects of this process are:

* The step of creating a new resource is performed by transclusion from information associated with the existing resource. * The method is implemented in combination with storage means accessible in a computer environment to maintain update object graphs may be assembled to form resources available in the environment, the storage means are adapted to storing in association with each of the objects information of degree of processing, and the method comprises the steps of: - detecting the modification of an object by a user,

- in response to this detection, create a new resource with the same content as the existing resource,

- apply the changes to the subject of the other resource that is the subject of the existing resource for which the modification was detected, - identify resource owners containing the corresponding objects in the upstream,

- towards these owners a proposal for acceptance or rejection of the amendment,

- waiting for a response of the owners, - based on the contents of at least the first response, adjust the information of degree of elaboration of the objects.

According to a fourth aspect there is provided a method for propagating information of standard object description between different objects may be assembled to form viewable resources in a user interface within a computing environment, characterized in that each object associated descriptive meta data, and in that the method comprises the steps of:

- entry in a propagation mode in the initiative of the user,

- the selection of an object of which is to borrow the description of metadata, - the selection of at least one other object to assign the same description of metadata.

Some preferred but not limiting aspects of this process are:

* User interface is adapted to mask the user with the description of metadata.

It is proposed according to a fifth aspect of the invention a method for making it available to third parties in a computing environment a resource containing at least one derivative object of another resource, characterized in that it comprises the following steps: - detecting a request from a user to modify the object,

- in response to the detection result in the computing environment a request from an owner of said another resource to authorize the availability of the modified object,

- depending on the response received from the owner, selectively allow or accessibility.

Some preferred but not limiting aspects of this process are: * a common query is engen plurality of objects derived from resources belonging to the same owner.

It is proposed according to a sixth aspect of the invention an IT resource capable of permitting implementation of the method according to the fifth above-mentioned aspect, 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 distribution constraint metadata from the content of the object, to selectively control its modification and / or its accessibility by third parties within the resources derived.

Some preferred but not limiting aspects of this resource are:

* Mailing constraints metadata include at least one metadata selected from the group consisting metadata authorization / modification ban metadata authorization / prohibition of access to third objects not modified or altered, and contact metadata of a decision-making authority.

* The resource is structured as a tree of objects, in that in combination with at least some nodes of the tree, a metadata distribution constraint is stored, and in that a meta- data dissemination stress at a node applies to the child nodes of the node.

According to a seventh aspect of the invention there is provided a method for making it available to third parties in a computing environment a resource containing at least one derivative object of another resource, characterized in that only objects are likely to be associated, so as stored in the computing environment, diffusion constraint metadata and the metadata being capable of containing an identification of an owner of an object from which the above object is to be derived, and in that the method comprises the steps of:

- detecting whether an object contained in a resource that a user wants to access is derived from another resource, - detection of the existence in the IT environment diffusion constraint meta-data of the object question,

- if so, reading said metadata,

- detection of the existence in those metadata of an identification of a decision-making authority - if so, sending said well recognized authority of access authorization request to third parties, and

- in the event that an acceptance of said request is received, provision of resources such third parties. Some preferred but not limiting aspects of this process are:

* The availability of the resource is published.

The method comprises the intermediate step, between sending the query and receiving an authorization or a refusal, a preliminary assembly step of the resource with an object formed of an extract of the object that you want to derive. * When the object is a text object, said extract is developed based on legal criteria quote right.

According to an eighth aspect, the invention provides a method to quantitatively estimate the activity of an object in a computer environment, this environment allowing access to resources performed by assembly of objects, at least some of the objects can be generated by derivation from existing objects and modifying objects and derivatives, characterized in that it comprises the following steps: - identifying the most ar objects to be derived, so that this identification is propagated to objects derivatives thereof -this,

- counting the numbers of derivations of the most upstream objects and objects that were derived.

Some preferred but not limiting aspects of this process are:

* The method further comprises a step of counting bundled consultations of the most upstream and objects which have been derived objects.

* The most upstream objects are advertising purposes. * The most upstream objects are able to be derived without being changed.

A ninth aspect of the invention consists in a computing environment for implementing a method as defined in the foregoing, characterized in that it comprises a plurality of servers connected in mesh, adapted to contain branch information between objects and degrees of development marking, each server being adapted to receive a request for indicating identifiers of objects on the basis of said information, and being adapted to redirect such request to another server in case it is not responsive to said request. In a first embodiment of a tenth aspect of the invention there is provided a method for managing variable content resources in an IT environment, each resource comprising a set of objects and at least some of these objects are presented in a resource forming a transcluded object individually or as part of a larger transcluded object from a source object, via the appropriate one or more intermediate transcluded objects, such that a change in the source object can propagate to said transcluded object, the method being characterized:

- in that the computing environment is adapted to store information transclusion based on object identifiers, information from which source objects are able to be presented in transcluded objects, and - in that the method comprises the step of, when the modification of an object, to generate or update, for each object transcluded from said object, a source object identifier to be considered for this object transcluded in function a distance information between the modified object and said transcluded object. A second form of the tenth aspect is a method for managing variable content to resources in a computing environment, each resource comprising a set of objects and at least some of these objects are presented in a resource forming a transcluded individually or object as part of a larger transcluded object from a source object, via the appropriate one or more intermediate transcluded objects, such that a change in the source object can propagate to said object transcluded, the method being characterized:

- in that the computing environment is adapted to store information transclusion based on object identifiers, information from which source objects are able to be presented in transcluded objects, and - in that the method comprises the step of, during the presentation of an object, determining, for each object transcluded from said object, a source object identifier to be considered for this object transcluded, using distance information between the modified object and said object transcluded. Some preferred but not limiting aspects of these processes are:

* Said step, when the modification of an object, identifies the object as its own source with zero distance. * Resources comprise of tree objects, and in that it further comprises a step of, for a transclusion an object encompassing descendant objects one of which is transcluded from each other, to define for transcluding between the descendant objects of the object including transcluded, a distance value between the shortest objects. * Said modifications may involve different attributes of said objects, and in that the step of generating or source object update is performed separately for each attribute, an object that can thus have different source objects according to the attribute considered.

* The different attributes include at least two attributes among content attributes, metadata, position and transformation.

According to an eleventh aspect of the invention there is provided a method for managing variable content to resources in a computing environment, each resource comprising a set of objects and at least some of these objects are presented in a resource at an object transcluded individually or as part of a larger transcluded object from a source object, via the appropriate one or more intermediate transcluded objects, such that a change in the source object can propagate up transcluded said object, characterized in that it comprises, as the frequency of changes to objects and presentation objects, the implementation of either the first form of the tenth aspect of the invention, or the second shape of said tenth aspect.

Some preferred but not limiting aspects of this process are:

* The selection of the method according the first embodiment of the tenth aspect is automatically selected when the environment of the source object is not adapted to generate said source object identifier.

* The selection of the implemented method is performed transclusion by transclusion.

* The method is implemented in centralized server means capable of providing the object identifiers of sources. * The method is implemented in a cascade of processing means capable of providing the object identifiers sources close path in close as transclusions.

* At least some transclusions are associated with the object processing information, the information designating each of a predetermined transform function to be applied to the object as initial transclusion a step.

* A transformation is adapted to be applied to object attributes such as content attributes, position, meta-data and transformations concerning internal transclusions objects.

* Resources are spreadsheets and that the objects are cells or groups of cells of the leaf.

* Formulas associated with cells of a group of transcluded cells are considered internal transclusions the group.

* Obtaining an internal transclusion in a group of cells transcluded comprises applying to the spreadsheet program instructions to copy / paste from a given internal transclusion source cell group.

A twelfth aspect of the invention provides a method for managing a set of information objects in a computer environment, some objects are objects containers may contain other objects, and the computing environment comprising a first structure objects and a second structure object transcluse from the first, characterized in that:

- at least some objects of the first structure have properties; - at least some co objects a second structure have constraints, and in that the method comprises the step of, when transclusion operation of the first structure to the first structure, to present the first structure objects in container objects of the second structure function of the adequacy of object properties of the first structure with the constraints of the second structure objects containers.

Some preferred but nonlimiting aspects of this method are as follows: the method further comprises the step of, when change in a property of an object of the first structure, to verify the appropriateness of the changed property with the constraints of the second structure object containers, and moving the appropriate corresponding object presented in the second structure.

* The process further comprises the step of, upon modifying a constraint of a container object of the second structure, to check the suitability of the properties of the objects presented in this container object with the modified strain celui- it, and move if necessary or considered objects.

According to a thirteenth aspect of the invention there is provided a method for modifying the contents consist of marked data stream which are accessed according to a syndication protocol, each content being accessible as a channel that includes a plurality of information elements each having a unique identifier, characterized in that it comprises the following steps:

- delimitation of an information element or part of an element to change, - application of the modification to the information element or the element portion,

- development of a content containing one hand the piece of information or some element of change defined by specific tags, and also the original of information delimited by its original tags so as to avoid loss of information when the stream is treated according to a protocol that does not support said specific tags.

Some preferred but not limiting aspects of this process are:

* To the modified element information or some element associated information indicating he replaces the information or part of original item element or constitutes an alternative to the element information or part of the original element, and in that it comprises in this case a step of signaling the existence of the alternative.

* The process further comprises a step of, in response to the modification of an information or element part element, to report this change to a server from which the data stream. * Resources are marked data stream which are accessed according to a syndication protocol, and in that the said objects are resources of the information or resources of said portions of said information elements (applicable to all processes above). According to a fourteenth aspect of the invention there is provided a process for converting a first resource comprising a tree structure of objects in a second resource comprising a tree structure of objects, based on transformations that can be performed on objects at different levels of the tree, characterized in that, when there is a first processor under a certain object including at least one descendant item, and a second transformation on said downward object, the second processing is primarily executed in the first transformation. According to a fifteenth aspect, there is provided a core user access to information objects created by a collaborative system where different user groups can contribute to form respectively different versions of objects from common starting objects, characterized in that the user is likely to belong to different groups simultaneously, and in that it comprises the steps of:

- as a function of an identifier of one of the groups with which the user performs access, present the corresponding versions of the objects from the input objects,

- based on a contributory access mode information / non-contributory by the user, taking into account or not in the collaborative system at group level considered subsequent amending user actions on the versions of objects that it accessed.

Some preferred but not limiting aspects of this process are:

* In non-contributory access mode when accessing under a given group, the modifying actions can be taken into account by default in other groups.

According to a sixteenth aspect of the invention, a method for access by users to items of information generated by a collaborative system where different users can contribute to form respectively different versions of objects, and where users can selectively accept or refuse versions, is characterized in that it comprises means for user contributions for the recognition and acceptance / rejection by other users of versions of objects containing these contributions.

- based on a contributory access mode information / non-contributory by the user, taking into account or not in the collaborative system at group level considered subsequent amending user actions on the versions of objects that it accessed.

A seventeenth aspect of the invention provides a method for making it available to a group of users in a computer environment a resource containing a plurality of objects may be modified by users to obtain different versions of said objects characterized in that it comprises:

- at least some of the objects, assign to different versions of the objects encryption keys / decryption different,

- provide versions of said objects encrypted with respective keys - when accessing the resource by a user, perform the decryption of encrypted versions of objects belonging to the resource using the respective decryption keys,

- When changing a particular object by a user, create a new version of the object, when a new key is assigned. Some preferred but not limiting aspects of this process are:

The method comprises a step of selectively providing key decryption of the objects to users according to enabling said user information.

* The clearances are processed by groups of users, two users of the same group having the same rights. * Versions of an object are formed by successive updates of the object at endpoint computing environment, and in that the step of creating a new key when creating a new version of the object is performed at the client terminal, a subsequent step of transmitting the new key to a key server being provided. * Versions of an object are formed by different content versions of said object, coexisting simultaneously, reserved for different user groups, and in that communication of such an object pa r of a first group to a user of a second group comprises:

- providing the user with the second group, by any appropriate channel, multi versions of an object containing the contents of the object reserved for the second group, the encrypted state, and - the independent supply by a server keys, with the second group of user, a decryption key for decrypting said content item reserved in the second group.

The method comprises a step of cutting the subject multi versions homogeneous parts from the viewpoint of access rights, each part containing positioning information allowing its replacement in the structure, such that the manipulations can be performed on the multi-versions object even in the absence of access to all of its versions.

Finally, according to an eighteenth aspect of the invention there is provided a method for making it available to different groups of users (ERC) in a computer environment a resource containing a plurality of objects may be modified by to give different versions of said objects, characterized in that each object is likely to exist in different versions corresponding to different user groups and downlink of a multi-object versions the inclusive, and in that it comprises, when access by a user to an object, the presentation in this version of the object corresponding to the groups they belong to each object version being obtained by transformation from another version of said object.

Some preferred but not limiting aspects of this process are: * the process is implemented using a management method according to claim

62, specific predetermined processing for obtaining each of the versions of the object.

* Action of transclusion by an object belonging to a multi-user versions object causes a transclusion of the entire multi-version object. * Each object is likely to exist within the same group of users in different versions for different users, these versions can also be presented at the access to the object by users of the group.

* The process further comprises the implementation of means for calculating saliency scores different versions corresponding to different groups and / or different users to selectively present the most relevant versions.

preliminary definitions

Object, Resource

Any information accessible and uniquely identified is an object. For example, a uniquely identified XML element is an object. A paragraph contained in a Word document is not an object insofar as it does not use ID. means we will implement in the "reification" (reify means to make an object). A reified object is typically selectable by clicking 1, movable or copyable (or "transcluable" - the transclusion is defined below), including drag and drop.

1 (by clicking on the object itself, or on a graphic handle that appears in the vicinity of the object when the resource containing the object is displayed in a special mode, or by selecting the object and pressing a button, etc.) a resource is a managed object: system level as the operating system or Internet server. Typical resources are web pages, files and directories.2

Note that the owner of a resource is not necessarily the person who holds intellectual property rights on its content, but rather the creator of this resource (the latter may for example have the same content as a resource belonging to someone else, this content has been obtained by transclusion or copy).

For brevity worries sometimes use the term "resource" instead of "resource owner." For example, we say "R3 accepts b4" to express that "the owner of the resource R3 accepts the modification made to the object b, which resulted in the b4 object."

ERC, collaborative server

We define a Collaborative Resource Kit (ERC) as a set of resources identified by a particular server type (described below) is called collaboration server 3, or a similar device.4 Moreover, CRF is characterized in that said set all resources are accessed by a defined set of users. In the following, the term refers to both ERC ERC that the user who has access group. We say that u user "belongs" to an ERC.

Note that an ERC is managed by more than 5 a collaboration server (or the like), but a collaboration server can handle multiple RCTs. That a resource belongs to is said (or part of) an ERC if it is identified as such by the collaboration server (or similar device) that manages this set 6.

It is said that access to a resource (or collaborative resource) is across (or under) a specific ERC 7 (to take advantage of functionality inherent in ERC described below).8 The user can also access a resource by letting the system determine the collaboration servers may identify this resource.

We say either "collaboration server" or "collaboration server".

User

By "user" is defined as "user or program"; in particular, for "user interface" means "user interface or programmatic" (except against sense). The term

2 The "system level" is subjective and relative to the view in which it is placed. Note also that resources contain objects that typically are not the resources themselves, but there are many examples where this is not the case, including directories (which themselves contain resources) and emails (which are resources and attachments they "contain" the are too).

3 By abuse of language, we say that a resource is "identified by a specific ERC" rather than "identified (that is, recognized) as belonging to a specific ERC."

See section 4 presenting cascaded architecture. Moreover, it is shown in the "Extensions to existing syndication Protocols" (towards the end) a £ 7? C can also be a set of identifiable resources in a syndication network (or share), even without existence of a Collaborative Server 'itself. However, it also describes the availability of at least one collaboration server provides benefits.

5 However, the distribution management of ERC on multiple servers is also possible.

6 And a resource can belong to several ERC.

7 If the resource is not identified by the given ERC, it is just ignored. The user can place in several ERC both. The user can also switch between ERC to another using an interactive medium for this purpose. The system actions are performed separately for each ERC and the results can be presented separately or in combination.

8 Note also that a collaborative server stores (not necessarily) the objects it manages but (rather) the identifiers. "User" can also mean "(ext ITIL handling of information (on the client)."

By "the user can select ..." means that the user can choose an option either at the same or by configuring / setting system in advance (except against sense). By "the user with access rights .." means the individual user or group of users, or a user role, having access rights in question (except against sense).

Finally, we will give examples of when each user contributing a change to a resource has its own version of the resource, its modifications are local to this release. These examples are provided to facilitate understanding and well means that the same version of a resource can usually be modified by multiple users and a user can change several.

Description

Introduction A collaboration server 9 allows a set of users to manipulate resources together similarly to a "wiki" (a process known per se; see including http: // en wikipedia org / wiki / Wiki..).

The difference with wikis is that on one hand the method of the invention can change and any resource in the Internet (which is not necessarily expected) and secondly it can simultaneously manage variations for portions of these resources (eg expressing different points of view).

In the case of modification of an external resource 10, the changes that occurred in the latter are reflected in its different versions views using the method.

The method is used via conventional navigation tools provided with extensions performing interface with a collaboration server.

It is similar to wikis in the sense that when a user changes one element of a resource that change is immediately shown to other users of the ERC when they will see this resource (if they are placed in the same spot view).

We will have one (or more) set (s) of public collaborative resource (s), and in parallel smaller groups can create their private ERC 11

principle of the method of the illustration

Figures 1-a to 1-g illustrate different steps of using the process and help to understand intuitively, even before reading the description which follows.

By convention, the letter V followed by a number (vl) is a version of a collaborative resource. A vowel followed by a number (s) is a version of an object (a); it is underlined (al) when it represents the latest version of 12.

9 Here we consider a design by implementing a collaboration server; will be presented by the end of this document to another approach (the same process) which does not require such a server (see "Extensions to existing syndication protocols", see the section with the "Architecture Cascade").

10 (such as a public Web page that was not created using the method of the invention)

11 An extreme case is the creation of an ERC by one person for his own use, if it wishes to use the functions of modifying objects without wanting to share those changes

12 (more elaborate) Figure 1-a shows a first resource and to a first version (s) of an object that has this resource.

It is assumed that the user wants to modify the object; a new version (v2) is then derived from yl; this is what is shown in figure 1-b. By convention, the figures show only created or modified objects.

Figure 1-c shows the situation after the object has been modified in v2. When the user views vl or v2, it automatically shows the latest version of this item is to say that of v2, which is highlighted in Figure (a2).

Figure 1-d this case the owner refuses vl the latest version of the object (that is to say the a2 version from v2). As a result, a new "branch" is created for this purpose and a2 is put there. As for al version of this object in vl, she finds himself alone in the first leg and thus becomes the latest (for this industry).

The branches of an object other than the currently active branch, are presented to the user as alternative versions of this object.13

Figure 1-e shows the case where the user viewing yl selects for the object, the second part (the latest version is presented a2 him as alternative version, that is to say as an selectable option). They say that the user "activates" the second leg (he does this simply by selecting the alternative version in question). In the figure shows this by moving the rectangle to the right leg while the object originally created remains in the left branch.

Figure 1-f shows the case where the user changes in the object yl located in the second branch. It creates the a3_ version becomes the latest in the second leg. Accordingly, when a user views v2 having activated the second part, it sees the most recent version of the latter, so that vl (that is to say, a3).

Figure 1-g shows the case where the user viewing v2 activates the first branch. It therefore sees the version (s) vl is the latest for the first part of the object.

We will now resume detailed description.

Versions of a collaborative resource branches to facilitate understanding, in the examples and the following explanations, each user having contributed a change to a collaborative resource has its own version of this collaborative resource. We say that these changes are local to this version of the collaborative resource.

In the absence of "branches" which will be described below, when the user views a collaborative resource for each object he will see the latest version of this item. This means that all versions of the collaborative resource are presented identically 14.

The user, however, has the possibility, when viewing a version of a collaborative resource, ask to see, when available, local changes in this version.

13 These are the latest object versions of these other branches that are presented.

14 However, we can consider that the system offers users to have objects or changes "secrets" in their versions of the collaborative resource In what follows, we will first Solely non-structural changes, ie which merely change values ​​( "InnerText") objects without creating, move or delete.

In Figures 2-a to 6-b, one uses tables where the lines are different versions of the collaborative resource (as in Figures 1-a to 1-g) and the columns are different objects in the resource collaborative. The values ​​in the table give the local versions of these objects - an empty box indicates no local version. Each column contains an underlined value that refers to the latest version in this column. In 2-a to 2-d, a collaborative resource is considered that contains three items a, b and c. This first is a single version vl, where the values ​​of the objects are al respectively, bl and cl (2-a).

Then (2-b) a user changes the object and writes a2 instead. This causes the creation of the v2 version of collaborative resource, the first content al remaining unchanged in the vl release. However a user views vl or v2 a2 he sees as the content of the first object as this is the most recent value.

Then (Figure 2-c) another user edits the objects a and b, and writes a3 and b3, respectively. This creates a third version of the collaborative resource, v3.

Then (2-d) v2 owner changes the object and enter therein the value a4. Because it works in its own version, it replaces the old local value a2. If a user views any version of the collaborative resource he will see the values ​​a4, b3, and cl, respectively, for the three objects.

The process offers the possibility of refusing versions of object (ie object changes by another user). The consequence of this refusal is to create a branch for each object whose version of the other user was denied, and move these versions reiusées in new branches. Other versions available in the same branch, it will be the latest to be displayed after the refusal.

Each of the collaborative resource can thus be partitioned into many branches, and each user then has the opportunity to choose (for each object) which branch he prefers (this is presented in the form of "alternative versions" as described in section next). Thus, each version of the collaborative resource specifies what each object (there is exactly one) branch is activated it.

A change takes place in a branch of an object will not be reflected in the versions where this branch is not activated (unless the user requests to make visible the other branches, see the next section).

The different branches of an object are treated independently with regard to the changes, as if it were different objects.

In summary: • Each collaborative resource contains a number of objects

• Each object has a number of branches

• Each collaborative resource has a number of versions

15 (as XML) • each version of a resource colla nine for each object which branch is active.

When a user views a version of the collaborative resource for each object its latest version in the active arm is presented.

Optionally, for each branch of every object, every version of collaborative resource can provide a local version.

The example of Figures 3-a to 3-d continue the case shown in Figure 2-d. We represent different branches of an object by as many adjacent columns. A framed box (rectangle) indicates that the branch corresponding to the column is active in the version of the collaborative resource corresponding to the line.

Figure 3-a: The owner of v2 refuses b3 change (v3). This creates a new branch (branch 2) in which was sent b3, and bl becomes the latest version in the old branch. Only v2 enables new branch. At this time, the vl and v2 versions appear a4, bl and cl as values ​​for the three objects and displays v3 a4, b3 and Cl.

Figure 3-b: The owner of v3 retaliates and refuses a4 value of the object, which is in turn sent to a new branch. The latest version in the first branch has becomes a3. The values ​​displayed for all three versions are therefore respectively: a3 bl cl cl bl a4, b3 a3 cl. 3-c: v3 modifies its version of b, in its field, and writes b4. However it is the only one to see it because it is the only one with this active branch.

Figure 3-d: v3 selects the second branch of a. This has the effect that view v3 a4 shows, b4 and cl as values. Then he has changed for writing a5. At this time v3 has two local versions of a (one for each branch), the second is visible. The values ​​displayed for the three versions are now a3 bl cl cl bl a5, b4 a5 cl.

Watch alternative versions of a collaborative resource

The method allows the user to view (and activate) the different branches 16 entered for each object. When a branch of an object is shown, it is the latest version found in this branch which is displayed by default. It offers the user different methods to do this.

First the user can view, in connection with each object 17, the list of alternate versions of this item 18.

Secondly the user can ask to see the different versions of the collaborative resource (which differ from each other by active branches) - this allows the user to see correlations between different branches of the various 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 to a particular object (or more), then viewing 19 different versions of the collaborative resource that activated the same branch for this object. The system will prevent further distinguish two versions of the same combination of branches

16 (that is to say, the various alternative versions)

17 (e.g., next to each object)

18 (eg directly in the collaborative resource or via a pop-up window)

19 (or rather by viewing the branches configurations for these different versions) within the resource considered r more users can even request to have the variants that a portion of the resource).

Finally, in a version of collaborative resource, the user may confirm the object the most recent version (as presented to it) of a branch, so as to make its local version for this subject branch (and replace that contained therein if applicable).

Alternatively it may refuse the latest version of the object in question (and other older versions which are presented according to him), until finally endorse a (which can be its own version or another). To the extent that it has endorsed several objects, it communicates (particularly when recording the version of collaborative resource in question) a set of local versions of objects that seems coherent him.

When using the mixed method described above, the filter can then be done by considering games endorsed versions of objects. Thus operates the contributions of users themselves, to ensure consistency branches enabled them. Derivation

several ways are offered to the user to avoid the working select object by object branches he prefers.

On the one hand by viewing a different version of collaborative resource, it can request copies in its version these different choices of branches. Another way is to allow a version of the collaborative resource (the downstream collaborative resource) to "derive" from another (upstream) so that when the upstream version changes for a branch of its objects, the downstream release will automatically adopt this new class, unless the owner explicitly stated which branch he preferred for this purpose. By default, each version of collaborative resource is derived from the version the change has given birth to him.

In addition to this, another method is to search for a user which version is closer (in its choice branches - this can be measured by looking at the proportion of choice branches that correspond to the total number of objects) from that user, and offer it to place its version derived from this other version.

Such a "bypass posteriori" can also be done by other affinity research methods, or even manually by the user (especially in the case of a student who derives his version of his master or a director who derives his secretary).

The example of Figures 4-a to 4-d uses exactly the same operations as the example of Figures 3 -a 3-d but suppose the derivation relations were placed as follows: v3 v2 drift and drift vl v3. This implies that changes in industry taking place in v2 will be reflected in v3 and the changes taking place in it will be reflected in vl, except that explicit branch of selections will not be replaced as well. Figure 4-a: The owner of v2 refuses b3 change (v3). This creates a new branch in which b3 is sent. v2 is going to explicitly choose the first branch and v3 will explicitly choose the second. By cons vl does not make explicit choices and thus follows that of v3 (ie the second leg). At that time, only the v2 poster a4, bl and cl as values ​​for the three objects, while vl and v3 show a4, b3 and Cl. Figure 4-b: The owner refuses v3 a4 value of the object, which is in turn sent to a new branch. v3 will thus explicitly choose the first branch and v2 will explicitly choose the second, vl eι '?>, and therefore does not follow v2 change in his branch. Attichées values ​​for all three versions are therefore respectively: a3 bl cl cl bl a4, b3 a3 cl.

4-c: v3 modifies its version of b, in its field, and writes b4. Unlike the previous example, it is not the only one to see because vl drift and also (implicitly) enabled this branch (vl and v3 will therefore see the new value while v2 will continue to see the old value bl ).

Figure 4-d: v3 selects the second branch of a. As in step 4-a, vl will implicitly activate the second leg. The three versions have therefore activated the second leg of a and see it as the value a4. Then v3 modifies the object for writing a5. The values ​​displayed for the three versions are now b4 a5 cl cl bl a5, b4 a5 cl.

Categorization of collaborative resources versions

Here we describe an improvement to qualify changes made by different users using keywords or categories. As already described, the different branches of an object can represent multiple viewpoints. therefore allows users to attach to the branches of objects "categories" describing the nature of this view. Each user has the ability to change the content of an object also has the option to change which category his version of the object. To ensure that all users use a common vocabulary, the system maintains a hierarchy of categories (taxonomy), the interior of which users can select the 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 and their changes, we can use this information and allow other users to filter versions available according to categories. This therefore provides a fourth method to navigate the different versions of a collaborative resource, in addition to those proposed in "Select automatically branches" above. We will now show how it works.

As the categorization of a change is an option and not an obligation the system proceeds by elimination of the branches have been categorized differently:

1. A user will see a resource and expresses its interest in one or more categories in particular. 2. The system eliminates (of all possible choices) versions have selected at least one branch of which the most recent content is categorized in a contradictory way the requested categories.

3. Then the user can explore the versions that are valid under the latter method described in "Select branches automatically" section. Structural changes, niche

We now describe how to generalize this mechanism to all types of changes, including creation, moving and deleting objects.

20 (or under folksonomies) is taken by the convention that t relatio two objects is not stored in the child but the parent. This information is shown as slots 21 being in Te InnerText "indicating which child must be present.

Thus the movement of an object from one point to another without changing the parent is to change the parent only; an object moving with the effect of changing which is the parent of the latter (without changing collaborative resource) consists of modifying each parent. Note that in both cases the moved object is not changed, only his parents and source destination are.

The removal of an object is simply to remove the reference to the parent. Again we consider that only the parent is changed, not the object itself. These considerations are important when you consider that such an object can be deleted in one branch (the parent) but not in other 22.

The object creation, is (the system point of view) in two stages: first a new object is created at the collaborative resource (because an object is a global concept to collaborative resource, not version specific collaborative resource). Then the object where the user has requested to create a child is modified to contain a reference to this new object. So if such a version wants to deny this creation she will only refuse the modification of the parent, which will have the effect of making the new object invisible. The example of figure 5-a to 5-d continues the case of the 4-d, making the additional assumption that b and c are children of a, that is to say, all versions has contain two slots, one for B and one for c. For example you could say that a3 is set to "<b> lives <c>" b4 is set to "Arthur" and cl is set to "Amsterdam", and so on. 5-a: The owner of vl instructs the system to create a new child b. To do this he places a niche in its branch b (he selected the second leg, so will add a window to b4. The version b4 scope of a new niche is local to vl. It is called b5) . The system will create a new empty object is called for, and this empty initial value is called dl. The dl object is created and enabled in all versions, but as it is only referenced from b5, only vl and v3 will be the subject.

Figure 5-b: The owner of v3 now moves the object as a child of cl. This means that it removes the reference being in b5 and adds a reference in cl. It creates new versions of these two objects, b6 and c6. A consequence of this is that now is made visible to v2 also because it was introduced in an object that was active branch in its version. Also note that d was not changed in the operation, there exists still a version dl, owned by vl.

5-c: The v2 owner refuses the irruption of this object. To do this he does not refuse dl itself (because a refusal actually means the refusal of the object content, not the object itself), but the new version of c6 c. This has the effect of creating a new branch of c, the former branch taking the old value cl without reference to s. Note that as vl drift v3 v3 he will follow in the new branch, and the new object will be refused in v2.

Figure 5-d: The owner removes the object vl b. To do this it modifies the object to remove the niche pointing b. This will create a new A6 version of the object. As

21 ( "slot" in English terminology)

22 To avoid having thus becoming inaccessible objects (all references have been removed) but occupying memory, a "garbage collector" (garbage collection) that will destroy the objects longer referenced anywhere may be necessary . all versions have activated the second speci 1 has the effect of eliminating all versions b. However b is not actually removed because it is still referenced from al, a3, a4 and a5. So if for example any one of three versions activates the first branch then a3 will be made visible, with its reference to b. On the other hand if either v2 or v3 asks to see his local version of the collaborative resource then again b will be made visible. If, against each of the five versions of the object removes the reference to the object b then nobody will be able to achieve the latter, and may therefore be deleted transparently (by the garbage collector ).

Note that in some cases, multiple references to the same object are rendered visible simultaneously. For example, if immediately after the step Figure 5-b has a user moves as a child of v then a user has activated the first part of a see b both as a child of a and c.

Management inconsistencies

When a user drags it can happen in other versions of the collaborative resource (depending on selected branches) this operation is seen as a deletion, object creation, and in some cases that the same object appear in several places.

There are applications in which this type of phenomena is not problematic, but the user may wish to place a number of constraints, such that some object to appear more than once, or when a transaction travel must, for another specific user, either have no visible effect, or be seen as a movement.

To ensure such constraints, while continuing to allow any changes to objects in case this operation would be seen by another user in an unauthorized manner, it is creating new branches for the origin and / or destination of the movement, whose value contains one before moving, and then automatically enable these new branches or among users in violation of constraints.

Note that these constraints, particularly those of an object position uniqueness, will prohibit certain combinations of branches. If a user attempts to activate an invalid combination, the system will automatically adjust the other branches to arrive at an authorized combination.

In the following example (see Figures 6-a and 6-b) it is assumed that provided the constraint that an object should not be displayed in two places simultaneously.

Figure 6-a: Consider two objects a and b, each having two legs (al, a2 and bl, b2). It is said that an object x (the content and any branches do not interest us for this example) is present in each branch of a. At that time the constraint is satisfied regardless of the choices branches because in all combinations x is child and has only a.

Figure 6-b: Now suppose that a user moves x al to bl (vl in the view). (Doing so ss values ​​'and bl'). At this time there are three permitted combinations Al'-bl "Al'-b2, a2 ​​and b2. In the second of these combinations, x is not visible at all, but it is not in violation of the constraint (but you can make the same instance where the constraint is that x is visible exactly once, and thus this second combination would be prohibited). If there is at least one version of the collaborative resource that was activated as a 2-bl combination (v2), we must ensure that the movement has no visible effect in this version. this is done by creating a new branch that contains the original state of wheat before the latter have received . object x the system will then, just before making the trip, activate in all affected versions (v2) the new branch bl If the user asks réΣ. he bl 'in one of these versions (v2 ) the system will force him to also enable al branch 1 of the object to avoid combina ison a2-b ', and, symmetrically, if a user requests to activate a2 branch in a version (lv) where the branch bl is active, the system will force the user to either activate or b2 bl b for the object .

Merger of branches

We have previously described a mechanism (refusal) to create new branches for an object. As described this operation was irreversible because there is no way to delete or merge branches. That's what this section provides. A user can express his opinion that the two branches of an object must be merged, including copying the latest content from one of the branches as content for another branch. As an immediate consequence, a user activates one or the other of these two branches after the operation, he will see the same content.

When this happens the system will merge the two branches of this object. It will therefore have to determine for each version which content placed in the branch after the merger (whether or not to put content at all).

When a version of the collaborative resource has a local version in more than one branch concerned, the merger is trivial.

By cons if a version has a local content for each of the two branches, the system must choose one of two content. For example if one of the two branches is active, the content will be preferred, if we take the most recent.

To avoid destroying the other one can create for this purpose an "inactive" branch (that is to say, that is never presented to the user as such but is used to store content and "disabled"). When the owner of this version views the collaborative resource the system informed of the situation and proposes various actions:

The user can destroy any such content

It may request to recreate a branch there to recover its contents (and other content "disabled")

Case's unique collaborative resource simplifies the process may be considered where there is in fact for each "ERC" one "collaborative resource" that encompasses all known objects in the system.

Then, unlike the method described elsewhere in this document, when the user is going to view or edit a resource he always does through this same collaborative resource and must tell the system what particular object he wishes to be treated (with his descendants).

This also implies (see section "Implementation" below) that a resource not indicate what its "root", ie it is no longer tied to a particular object.

This is useful if resources can contain other resources, such as a directory containing documents or other directories. It can for instance change the organization of files and directories, and amendments will have a consistent effect regardless of the directory viewing another user. If different collaborative resources were used for each directory that is not the case - that the changes would be visible condition see the structure from the same point as when editing. transclusions

We will describe the mechanism of "transclusion" later in this document for building objects that are modified versions of other objects.

Briefly, a transclusion is similar to a resource version except that objects seen through a transclusion can coexist with non objects seen through a transclusion, or seen through another transclusion etc.

You can watch any object through a transclusion, and place the result as a child of another object. The parent will then contain a reference (under crenellated) identifying the transclusion one hand and the other source. When the user changes the result of a transclusion, since this result has no independent existence, the changes will be stored "in" the transclusion itself (in terms of differences).

A transclusion is indeed processed, from the standpoint of setting out the method presented here as an object in the sense that it can be modified in various versions and these changes may be rejected by other users, which makes the transclusion may have several branches. The contents of a transclusion describes the differences applied to the sources. A transclusion differs from an object that a transclusion can itself be placed as a child of an object, and can be directly displayed to the user (he can only see the image of objects by this transclusion). Implementation

Architecture

The resources identified by a specific ERC may contain objects defined as replaceable 23 as part of this set.

By the method described here, the users of the same ERC can edit and 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 collaboration server (or similar device) that determines what those objects.

A simple architecture (among others) to implement this method is selected as basic description of the inventive method. It is presented very schematically in Figure 7 and includes the following:

- Information handling tool (represented by the icon of a laptop):

Means of presentation and / or resource handling. May especially be a browser such as Internet Explorer, or a tool such as Microsoft Word, or the explorer of the operating system files. In practice this tool will provide an extension is (plug-in) adapted to implement the method.

primary content server (PCS) server capable of providing the version resource required by the user in the information manipulation tool.

Groupware Server (ES): Server able to provide, for a version of accessed resource identifiers versions of objects.

23 In the following, all objects of all resources are considered replaceable (although it is considered as an object than those reified), but other methods may be implemented to selectively choose those that are. In particular, it implements the constraints of non-changeability of certain objects (eg which are advertisements) as explained below.

24 (replacing their content or their position or both, or delete or add).

25 As already mentioned, another architecture is described in the end of this document. Secondary content servers rors able to provide the contents of object versions.

As illustrated schematically in Figure 7, the user who requested a version resource by giving its identifier (URL, URI, ...) by conventional means, and for each identifier ERC given by the user 26, the information handling tool performs the following steps:

1. obtains the resource required version of a primary content server;

2. (in parallel with step 1.) received the collaboration server the identifiers of the versions of objects to be displayed; 3. (continued in step 2.) gets secondary content servers those versions of objects;

4. and assembles said object versions in said version of requested resource.

We will now describe the operation of a collaboration server. The term "system" always indicates below the collaboration server. Data Structures

There are basically four types of data structures which are manipulated by the system, which:

1. A collaborative resource

2. An object (a collaborative resource) - this is not a particular version of that object but the class of all its branches and versions (examples use the letters a, b, c, etc. to represent an object). As said above it can be a transclusion and not an object.

3. A version (a collaborative resource)

4. A reference to a content (ie a particular version of a branch of an object) that is in a content server.

We will describe what the data stored and maintained in these data structures. An object has

• a unique ID for collaborative resource,

• a list of branches and each one identifier (it is not necessary that the object identifiers or branches are unique between different collaborative resources).

• To avoid having to search at any time the latest version, it is advantageous to store for each branch a reference to the version (version of collaborative resource structure) latest of its content. (It is also possible to dispense with this information and go to each request the Table of versions and check the dates of the local versions change).

A reference to a content indicates

• ID and the server from which the actual data can be obtained

• What are the objects that reference content via slots • the date on which this content was last modified

26 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 that this content. A version specifies

• the customer who is the owner

• if applicable, what other version of the collaborative resource it derives • for any object (given by its identifier) ​​may indicate which branch is activated (and nothing is specified for the purposes for which we need to get the choice branch given by the collaborative resource which it is derived)

• for any branch of each object for which it provided a local version, a reference to the content of this local version. Finally, a collaborative resource brings together all this by storing

• all objects it contains

• the ID of the root object of the collaborative resource (which is common to all versions)

• all versions of the collaborative resource constraints

Thus, the algorithms described below interrogate constraints (all objects must be unique, for example) asking if a certain combination of branches of a collaborative resource should be allowed or not. This method allows to leave open the types of constraints that can be applied. To assist in meeting the constraints, the latter, instead of simply refuse block some combination of branches, the implementation of the stress can provide a list of the branches problematic. For example, for a unique constraint, it comes to the list of branches containing the object multiplied.

Algorithms The following sections will describe the various operations that a collaboration server provides to its environment, which are:

• Access "reading" (the structure built to present to a version of a collaborative resource)

• Change active branch in a version of the collaborative resource. • Modifying an object

• Create an object

• Refusal of an object

Construction of the present structure for a version of the collaborative resource identifiers from a collaborative resource and a particular version of this collaborative resource, given the references to the contents of items to be provided to the customer in order that that it can build collaborative resource as it should be presented to the client. (Remember that the collaboration server does not access the contents themselves but only their identifiers, which is why it can build itself the page). We start from the root of the resource al: What is determined is the active branch in the requested version. If it is an object seen through transclusion must apply at that time differences of the transclusion (as described in the section of this document on transclusions). Then this operation is repeated from the children of this content.

Change active branch

The customer requests a change of active branch indicating which object of which version of collaborative resource is affected, and the identifier of the newly selected branch.

The system first checks whether the combination of choice resulting branches for this release is in violation of a constraint. If this is the case it will automatically change which active branches in other objects to satisfy the constraints.

Once a valid combination found, the system will simply store the new value in the structure.

Reaction to changes This section describes how the system is informed of a change, and how it maintains its data structures to reflect this change.

The description of an amendment contains a collaborative resource identifier, a version identifier (of the resource), the identifier of the modified object and description of the contents of the object after the change (all the attributes listed in the description of this data structure "refers to a content").

Note that in practice it will group a set of changes in a single query, and process these changes in parallel. In particular constraints should be checked only after making all changes and not between each.

Since a modification can change the effect of stress, it is possible that other versions are found in violation of a constraint. If this occurs the process will perform a refusal branches problematic (this amounts to simulate the user who refuses). This will cause that version having enabled these branches will retain the old values ​​of the objects.

Sometimes a change is itself in violation of a constraint (eg if the user tries to place in the same object twice the same child subject to a unique constraint. At that moment any combination branches having chosen this branch will be in violation of the constraint. It may be preferable in these cases simply changing fails, rather it is accepted, then the system will not display it.

After eventually created these new branches simply place the new information (content and child lists) in the original branch.

day is also put into the collaborative resource the pointer to the most recent version in that branch.

Processing an object creation

As already explained above, an object creation is performed in two steps. Firstly the creation itself, and then the change of the parent object to contain a reference to this item. The first step is described below, and the second step will be requested by the customer to the system as if it were a change "normal". An object creation request indicates collaborative sSource this object is created, what should be the initial content (in the form of an identifier) ​​and which version of the collaborative resource carried creation. The response to this request will be the identifier of the new object. The processing of this request is:

• select new object identifiers and branch

• create a new content structure with the given identifier, the date is now and do not have children

• create a new object structure with the new selected identifier and one branch of which the latest version is the one who made the creation

• add the new item to the list of objects of the collaborative resource

• insert the ID that provides the initial content provided in version.

It is assumed that the initial content of the object is empty or neutral view of the constraints and therefore there is nothing to check (otherwise one could imagine such a constraint setting a maximum the total size, such as number of characters, the collaborative resource. in this case creating an initialized object of a nonzero content could violate the constraint).

Indeed, if the user creates a non-empty object, this must be sent to the system in two stages, first create an empty object and its modification to a non-empty object. Treatment of a refusal

To notify a refusal, the client informs the system which version of collaborative resource refuses what objects. It is assumed that the rejected versions are those that appears for now to the locations of objects for the given version.

Sometimes a refusal fails, for example if the user tries to refuse the single version of an object in a branch. At this point the error is reported to the user and the system does nothing.

We first determine which versions of the collaborative resource provided the denied content. To do this we look for each branch denied what version of the latest object for this branch. In case the refusal would cause a constraint violation, the system will attempt to solve the problem by refusing another branch also problematic. This can occur when a user wants to reject a move. In case of non-multiple constraint (ie there must be at most one instance of a given object), if the user refuses the disappearance of the object to the source of the movement, the system requires it to also refuse the appearance of the object to the destination. If this second refusal fails, the first should fail also.

It creates a new branch identifier for the refused object. It moves the content declined in the new branch, for the version of the collaborative resource which had provided this content. This also has the effect of removing the content in question for the old branch in this release. Since the deleted version was the latest must now recalculate what is the latest version in that branch.

If the content was denied active in version providing this content the new active branch is rendered in this release. Finally, if the dt version of the rejected version is activated

(Explicitly) the old branch in the latter (to prevent it follows the version rejected in the new branch).

Managing concurrent operations The system described so far assumes that the changes made by users are atomic, that is to say on the one hand they are based on the latest state of the collaborative resource and the other two users do not attempt to simultaneously edit the same object. This can not be guaranteed in reality, for example if a user wants to modify an object and another wants to deny simultaneously. In particular, the actions performed by the user may be made based on an obsolete version of a collaborative resource, it has been modified since the last time it was downloaded to the client.

Here are two methods to resolve this problem.

a system of locks used, a user wishing to change an object must first lock it and take the time exclusive rights to the modification, time interval during which no one is allowed to change the subject.

We do not take preventive measures, but if a user tries to perform an operation which is thus in conflict, he was asked to make itself the merger of two conflicting operations. For example, if two users download a collaborative resource, everyone amends part, and each tries to send its version, when the system receives the second request to change it will return to the user the updated resource collaborative and ask him to apply it to new amendments.

The system can provide the user with tools to carry out the merger quickly if the system detects the nature of the changes made by users may try to merge the actions of both users automatically, and seek help from the last only when it comes to making decisions, eg whether the same part of a paragraph was changed by each user.

Restrictions spread function can be offered to ask, object by object, variations from normal behavior of collaborative resources.

Read protection

A user can ask for an item to a "secret" branch to which he is the only one with access. Such branch behaves in all respects as another except that it is not rendered visible to other users (and they do not have the opportunity to select). If a user creates an object as a child of such a secret branch, the new object will also be made secret.

One can of course consider finer adjustments when a non reduced to one user group is allowed to access this branch. Write Protection

The user can always ask to see his local version for particular object, even if a newer version exists in the same branch. One way to implement this is that as soon as a change occurs in a branch, such a write-protected object is sent in its own branch (as if). If the user then changes this object again, he was again sent to the branch where it was previously, so this version is made visible to other users.

When the object is thus moved into its own branch the user always has the option to check the other branch to see the latest version.

Furthermore versions derived from the one containing the protected content writing will continue to see protected content in question, as they inherit its active branches (except of course if they have explicitly enabled another branch).

Unidirectional propagation As another type of restriction can have an object or resource for which the changes propagate only in one direction, for example, from upstream to downstream as is the case of the transclusion.

Variation: resources versions as Transcl usions

Transcluding can further be used to collaborate (by propagating the latest or the most elaborate modifications) if this mechanism is also extended to propagate changes in the direction of the source (upstream). We will now describe this generalization of the transclusion (to use collaborative mechanism as defined to date).

Instead of having different versions of a collaborative resource will now consider each such version is actually a resource (downstream) full (with a separate resource identifier) ​​that transclut all content of the resource ( upstream) that it intended to change. It is said that the downstream drift of the upstream resource resource.

Similarly, instead of versions of objects will now be considered full-fledged objects (having identifiers of distinct objects) that result from a transclusion from the corresponding objects in the upstream resource 27. The process thus consists essentially determine which objects should be replaced (by a replacement object) or enriched (by alternative objects) during the presentation of a resource to the user.

As both the source (upstream) as the destination (downstream) now have identifiers of distinct objects, it is possible to consider them in parallel. For example to have a site in a page that is transclue another or having a directory resource transclue another located in the same directory.

New processes of cooperation that is now described were designed to integrate (and complementary) with the transclusion process. The essential difference is that the upstream-downstream direction and upstream-downstream cooperation will now not symmetrical. We will thus describe objects "most developed" versions instead of "latest" object.

principle of the method of the illustration

Figures 8 to 21 illustrate different steps of use of the process and possible to understand intuitively, even before reading the description which follows. These figures illustrate resource bypass examples: a resource Rl is derived by a resource R2 to be further developed, then R2 is itself derived for still incorporate other modifications, and so on. However well a modified object in a resource may be denied by the owners of the resources which it is derived,

27 And the implementation we will adapt the concept of "branch" accordingly. and then leads to the creation of an aut s branches and represent different viewpoints. In each branch, the object that is most downstream is the "most developed".

Initial (8): The resource has R s object. So al is the most developed.

R2 is derived from R and modifies al a2 (Figure 9): So a2 is the most developed.

R3 is derived from R2 and modifies a2 a3 (Figure 10): Therefore a3 is the most developed. R2 refuses a3 (Figure 11): As a result of this refusal, a new branch is created (Branch 1) while the original stream is in Sector 0. a2 is the most developed in Branch 0 and a3 is the most developed in Branch 1 .

The resulting branches diagram is shown in Figure 12.

When users visit Rl or R2 sees what is shown in Figure 13. However, when R3 visit, he sees what is shown in Figure 14.

R2 and R4 drift modifies a2 a4 (Figure 15): So a4 is most developed in BrancheO.

When the user visits Rl or R2 or R4, he sees what is presented in Figure 16.

However, when the user visits R3, he sees what is presented in Figure 17.

R2 refuses a4 (Figure 18): A new branch is created (Branch 2) with a4 as the most elaborate object.

The branches chart is now as shown in Figure 19.

Note that when the user sees an object in Branch 2, for example in the R4 resource, alternative items are not all on an equal footing, Branch 0 Branch is more relevant than 1. One could limit the visibility of a branch with ancestors and descending branches, or alternative sort objects according to the proximity of their branch.

R5 R2 drift by modifying a2 a5 (Figure 20): 28 So a5 is the most elaborate object in Branch 0.

Rl accepts a3 (Figure 21): As a result of this acceptance, al is replaced by a3 and placed in one branch.

A method of creating the more elaborate objects is described a resource modification process comprising the following two main steps:

1. derivation of the resource that at least one object is to be modified, and modification of this (or these) object (s) in the derived resource,

2. proposal of the amendment to the upstream and determining the position of objects "most developed" based on the response (or lack of response) to this proposal.

These two milestones are respectively described in the following two sections. We will then describe how the replacement of objects is determined (OR) and alternative objects (OA).

Creating derived resource Rule 0: When the user accesses through an ERC to a resource using a tool of manipulation of information, for the change, but it can not or will the

28 (or drift R, or R3, R4 or R5 but chooses the alternative a2 then change) change directemenr, maπ training tool automatically creates a derived resource that has the same content "" and this at the user, and it modifies said derived resource instead of said accessed resource.

The derived resource is stored in any server 31 available to the user (and hence not necessarily in the server of said accessed resource).

The amendments are proposed to the upstream

It is said that said accessed resource to be modified is at the upstream of said derived resource (and the latter is downstream of said accessed resource). Indeed, a resource may be derived from a resource itself derived, thus forming a chain (or cascade) upstream and downstream.

The initial situation is governed by the following rule.

Rule V: The objects in a resource that one hand is not derived from another and also from which there is no derivative resource are (implicitly) considered "the most elaborate ". Then we have the following rules:

Rule 1: Each modified object 32 in a derived resource until it has been modified further downstream, is the most developed (and the closest object if any upstream ceases to 'be).

Rule 2: The said amendment is spontaneously offered to owners 33 respectively corresponding to the upstream resources.

Each of these can accept, reject or ignore the proposal. Here are the results:

- Rule 3: If the modification of an object is accepted, the result of this change is propagated to the accepting object. - Rule 4: If the modification of an object is not to be upstream, whatever the position of the object refusing, the first object that is upstream (refused said modified object)

• becomes the most developed 34

• and starting with this item refused a separate branch is created (in the change tree of objects) for placing the identifier of said modified object refused 35 and its descendants. It may well be several objects labeled "the most

29 (either because it is read-only; either one is in the case of the user who tries to modify a resource that has the right to change, but it does not directly change because it prefers rather change a resource derived from it)

30 This is described in "Method for Deriving by TransClusion" section. Note that the content of the derived resource is then synchronized with the resource from which it derives.

31 (selected by user)

32 It may especially be the addition of an object, deleting an object, or modifying the content or the position of an object. Alternatively, one can take the approach of "niche" described in detail below.

33 The amendments may be proposed only if said owner is available, eg where their email address is known. When said accessed resource is itself a derived resource (as part of an ERC), the problem does not arise because the owner is known and accessible office. In fact, the replacement process / beneficiation object can itself serve as a means of acceptance proposal or not the change (of the object that just serves as a replacement or enrichment).

34 (without the objects that were most developed prior refusal cease to be)

35 (so as to subsequently extend the "trunk", without following this branch) developed "in a tree myself identifying the same object; we say that these are alternative objects.

Example

We will now explain and illustrate (see Figure 22) these rules by considering two branches (and associated changes) from a successive RI resource.

Note that these leads can be performed by different users 37.

Background Example

Resources are identified by a capital letter followed by a number (index) that indicates the version number; the objects are identified in lower case and the same index as the resource in which they were created or modified.38

Figure 22 shows that:

• The content of the RI resource is the object laughed. laughed itself contains three objects: al bl and cl (actually, the user sees the content of the resource Rl r sees the object that contains items a, b, c; the indices used here to view more easily what is the resource that contains the object in question initially)

• R is derived (in R2) to change the specific content 39 or position 40 of the r objects, a and c (ri is changed by r2, al is changed to "2 and A is modified in c2) and insert a new object d (d2).

• R2 in turn is derived (in R3) to change b (b2 is changed to b3) and c delete (remove c2).

In the implementation of the collaboration server that we will now describe the data structure managed in the collaboration server advantageously does not contain the resources or objects themselves, but only their IDs. Is presented here schematically a structure pointers and markers, pointers for reconstructing derivations and modifications and markers used to distinguish the most elaborate objects (as well as object deletions). This structure includes:

• Resource bypass Trees (as R -> R2> R3)

• Objects modified trees 41 (such as RL-> r2; al> a2; BL> b3; cl -> C2> E3; d2) whose nodes are accessible from the corresponding nodes resource derivation trees 42.

Advantageously, in reality nodes forming objects modified trees include only the modified objects. Missing nodes represent objects not

36 Indeed, there is a most elaborate object different in each different branch.

37 (different from each other and / or different Owner R)

38 For clarity, in bold italics are put created or modified objects.

39 For example, in the case of elements in a log to XML, the al laughed and their contents are "InnerText".

40 The position can be specified by the parent object and a brother (left or right, according take agreement). a variant is described this approach further to the "Slots" section (note that the approach adopted was that of the slots in the previous chapter).

41 (or "objects of diversions trees" - note that further considering composite objects called "grains" and then manipulates the "grain modification trees")

Each node 42 of the tip resource derivation tree on the corresponding nodes of the objects of modification shafts (as seen in the figures). In practice, we can implement a different data structure but equivalent, including using tables of relational database. modified, that is to say, they reflect the content of their corresponding upstream.44

The figures shown schematically show a resource derivation tree and tree object modification. They show, as a black rectangle in the trees of modifying objects, nodes marked as the most elaborate.

Figure 23 shows the data structure before the branches (that is to say before that 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 changes to R2 and R3 before the bypass. It shows the nodes labeled as the most developed (ie the black rectangles) assuming no changes have yet been accepted or refused. We see in the figure that under Rule 1, the objects r2, a2, c2 and d2 become more elaborate, while wheat remains the most elaborate since b2 46 has not been changed.

Figure 25 shows the data structure after the changes in R3. Again the nodes marked as the most elaborate presuppose that no changes have yet been accepted or refused. Recall that changes made to remove consisted c. Note and c2 object is not the most sophisticated but it's E3 (the absence of the object c) who is (still under Rule 1).

Recall again that in R2 there are many b2 object (which reflects the content and position of bl) and in R3 there is well r3 objects, a3 and d3 (which reflect the content and r2 positions a2 and d2, respectively), but they are not included in the modified trees because these items are stored as nodes representing the modified objects.

25 shows the initial situation in which the following examples are based. Thus, we will consider before the bypass (and modification) of R2 R3, there was neither acceptance nor rejection of any object.

A method of determining the replacement object and alternative objects

Rule 5: Each current object to be presented to the user, if he himself is not the most elaborate, is replaced (in said presentation) by its most elaborate corresponding lying downstream in the same plugged.

Of course, the user can at any time activate and deactivate this feature replacement of objects.

Rule 6: The objects "most developed" unless the object that serves as replacement object pursuant to Rule 5, are considered alternative and objects are presented to the user as options. Each alternative has a priority object depending on the

43 (thanks to transcluding process, described later)

44 Accuracy: According to the method, although in principle, in the trees of modifying objects, are represented as object identifiers, the content or the position is changed (or the deletion of an object), it can also put the nodes representing non-modified objects but are nonetheless marked as the most elaborate. Indeed, there are several possible implementations of a management mechanism of the most elaborate objects and the method presented here is only one of them.

45 In an optimized implementation can be avoided represent in unmodified objects. We present them here for clarity.

46 b2 is not in the tree of objects change since this tree includes only IDs modified objects (except unmodified but being the most developed) as already mentioned. close to the branch in which it _ "jet in the same branch being priority and closest branches having a higher priority).47

When the user selects an alternative object, it replaces the current display object (the latter being the object contained in the resource, a replacement object or another alternative object previously selected).

It is advantageous for the user to submit together all alternative items from the same resource, for reasons of consistency. When the user views a resource, alternative group objects according to the resources where they are. Of course, the user can at any time turn on and off this presentation of alternative objects functionality.

The implementation may simply be as follows. To determine the replacement items and alternative collaborative server found in all resources bypass trees, the resource node representing derivative in question. From there he found for each object for which there is a change in object tree, browsing the tree, the replacement object - the object drawn in the same branch in aval- and objects alternative (in other more elaborate objects in other branches) according to the rules 5 and 6.

Examples

Ignorance or acceptance (Fig. 26)

Assume that the user visits RI foremost acceptance or refusal. During the presentation of Rl to the user (Figure 26), pursuant to Rule 5, r2, a2, b3, the absence of c and d2 will replace the corresponding objects of Rl. As for Rule 6, there is no alternative object to present as there is every time one the most elaborate object and it is already used as replacement object within the meaning of rule 5.

As a result of the stated rules, as long as there has been no refusal, the resource and its derivatives are presented in the same way even after acceptances (unless there have been changes to the upstream subsequent changes to downstream, in which case we must refer to rule 7 set out below).

Rejection (Fig. 27-32)

Suppose the user Rl visit after "R2 refuses". During the presentation of R to the user, under Rule 5, r2, a2, b2, c2 and d2 will replace the corresponding items of RI. In addition, pursuant to Rule 6, the b3 objects and lack of c are shown as option compared to the corresponding objects that are presented in the RI resource (see Figure 27).

Suppose the user Rl visit after "R refuses R3 and d2". During the presentation of R to the user, under Rule 5, r2, a2, b2 and c2 are coming replace ri al, bl and cl. In addition, pursuant to Rule 6, the b3 objects, the absence of c, and d 2 will be presented as options in relation to their objects (or no object) correspondents are presented in RI resource (see Figure 28 ).

47 An additional approach to prioritizing alternative objects is described later in "A method of sorting objects by alternative scoring (rating)." Assume that the user visits R2 apri Fuse ". There is no replacement within the meaning of Rule 5 since these objects are themselves the most elaborate. However, within the meaning of Rule 6 there are alternative objects b3 and lack of c (see Figure 29).

Assume that the user visits R2 after "R refuses R3 and d2". There is no replacement within the meaning of Rule 5 since R2 objects (or reflected in R2) are themselves the most elaborate. There are alternative objects b3, c in the absence of R3, and in the absence of of Rl, as defined in Rule 6 (see Figure 30).

Assume that the user visits R3 after "R2 refuses". He sees R3 objects that actually reflect the R2 objects, except for b3 and c3 that were remodifiés in R3. There is no alternative because all these objects are already the most developed. However, pursuant to Rule 6, b2 and c2 represent alternative objects relative respectively to b3 and the absence of c (see Figure 31).

Assume that the user visits R3 after "R refuses R3 and d2" (see Figure 15). He sees R3 objects that actually reflect the R2 objects, except for the absence of b3 and c are the changes made in R3. There is no alternative because all these objects are already the most developed. However, with respect to Rule 6, b2, c2 and d represent the absence of alternative objects (see Figure 22).

multiple derivations of the same resource (Fig. 33 through 44)

Suppose the user accesses the resource R just after "R refuses R3 and d2" and wants to change the objects a2 and b2 (replacement) presented to it automatically. Under Rule 0 R4 resource derived from Rl is automatically created and such modifications constitute a4 and b4 objects. Figure 33 illustrates that succeeds a4 a2 and not al, a2 is because the replacement object al (this is a2 which is modified to a4). Moreover, b4 extends the "trunk" in which is b2 and it takes the most elaborate object marking.48

Before modification, the user sees the R4 resource as when the user Rl visit just after "R refuses R3 and d2" except that, advantageously, there is no b3, or E3 or d2, since R4 not them as ancestors 49. This is shown in Figure 34. After modifications, the user sees the R4 resource like this Figure 35. a2 is changed to a4 and b4 b2. Alternative objects b2, E3 (the absence of c) and d2. Note that b3 is not presented because it is neither ancestor nor descendant b4.50

The user now sees the RI resource as presented in Figure 36, and the resource R2 as presented in Figure 37. The user may prefer an alternative object to a replacement object presented to him. Suppose the user accesses the resource R after "R refuses R3 and d2" then selects the alternative b3 object and want change it b4. By Rule 0 a resource is created and R4 derivative is obtained the structure of Figure 38 wherein the arm is located in b3 b4 is extended by (b3 which takes the most elaborate object marking.

48 Since this is b2 (replacement object presented automatically instead of wheat), which was amended in b4, it is the "trunk" (containing b2) which is extended and not the branch that was created for the purpose refused b3.

49 It is therefore not alternative priority items and by default it is not so presented. But the user can make them appear as non-priority alternative objects.

50 Alternatively, 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). After selecting the alternative object b3 n îodification (so R4 is not yet necessarily created), the user sees the RI resource like this Figure 39. 51 After modification (which creates resource R4), the R4 user sees the resource as presented in Figure 40, R as presented in Figure 41 and finally R2 as presented in Figure 42.

Suppose finally that alternative objects presented in Rl, namely: b4, E3 and d2, are accepted in Rl. We then have the structure of Figure 43.

Rl, R2 and R4 have the same objects to the user, namely, r2, a2, b2, c2 and d2, b3, and finally as an alternative object. With regard to R3 it has r2, a2, b3 (b2 being reciprocating), c2 and d2. As c2 will logically be refused by the user since it has accepted the absence of c 52, by way of optimizing the collaboration server may refuse the office, thus obtaining Figure 44.

Description of Rule 3 (Fig. 45)

In this embodiment, the following rule 3v replaces Rule 3 set out above: Rule 3v: in the case where the modification of an object is accepted (upstream), this change is propagated to the accepting object. If said object and said accepting accepted modified object are in different branches, then accepting said object and all its descendants to the first object from which a connecting lead (directly or indirectly) to the branch is located in said modified object accepted are moved to get into the branch where said modified object location accepted.

In the previous example where the owner of R b4 accept alternative objects, E3 and d2, the result is now at Figure 45. At Rl:

• bl is replaced by b4, but the latter is moved (to the right in the figure) to get into the branch where b3 is located; Note that b4 that is located in R4 is not deleted; accordingly, when R will be visited by the user, b4 replacement object (not b2) to be presented to him;

• E3- moves (to the right in the figure) to be placed in the branch where E3 of R3; Note that E3-R3 has not been removed; accordingly, when R will be visited by the user, is "the replacement object" E3 (not c2) to be presented to him. Substitution / Enrichment grains (Fig. 46-49)

We will now take into account that

• objects are potentially composite,

• there is coherence between the different parts of a composite object to check before deciding whether a spread should be done or not, • and that for the discussion in relation to Rule 3, it is better to take as appropriate, either implementation approach presented first (Rule 3), or the approach of its variant (Rule 3v shown above).

It is the user who defines the "granularity" of the manipulated composite objects.

51 Variant of implementation: After selecting the alternative object b3 but before R4 modification is directly created, the user then sees the R4 resource.

52 However, for b2 can not decide so easily: the owner of R may decide to refuse it or not. However, since it is atomic objects (as opposed to composite objects - will be described below), given the fact that R had preferred b4 to b2, we can perform the same optimization for c that is to say, refuse b2 automatically. Instead of unit objects as objects décri replacement and alternative objects will now grain 53. A mark will be the most developed (if any) not only unit objects but also grains 54.

Definition: A seed is a composite object whose modifications (the objects it contains) are propagated in 55 "all or nothing"; that is to say, they are

• (case 1) is fully propagated to an object corresponding to the downstream - where there is no spread of incompatibility;

• (case 2) or they are not propagated at all to an object corresponding to the downstream - if there is a conflict of propagation. II inconsistency propagation when propagated changes from grain source to the downstream objects, are different for at least one downstream object

• already modified locally

• or a change which has already been propagated from a source closer (this is defined below) than said grain source. Note that in the user interface, rather than (or in addition) to enable it to specify which objects are (explicitly) grains and which ones are not, when the user instructs the system to reify content containing parts themselves reified, is allowed to de-reify reified parts contained in the selection, or if not specify if he wants changes reified parts are necessarily spread sets (when the downstream is not incompatible). If he said that changes must propagate sets then it means that the object in question is a grain.

To describe the treatment of seeds, we will consider the example of a grain object "a" 56 containing two objects: "b" and "c" (Figure 46).

Figure 47 shows an example wherein such al grain exists in a resource Rl, then is derived by a2 in a resource R2 (derived from Rl), then again derived by a3 in R3.

In this example, first, in R3, A is modified c3 - this is shown in the first part of Figure 47 (top of figure).

The second part of Figure 47 shows two cases for the result of Example: Case 1: only bl is changed in R2 (to give B2).

Case 2: bl and cl are both changed in R2 (to give b2 and c2). Here's how these changes are propagated to downstream:

• In the first case, the change of the object b is the grain a2 a3 propagated to the grain. Thus it is seen in the grain a3 the result of the fusion of changes a2 grains objects and a3: the grain a3 contains al, b2 and c3.

In the second case, the modification of the object b (bl is changed b2) a2 grain can not be propagated in the grain a3 57. Indeed, by definition of grain, b2 and c2 go hand in hand, which means that the fact that, in the grain a3, bl

53 In the following, by abuse of language, by "grain" all we hear of objects specified as one grain or object not part of any set of objects specified as one grain. So when we talk about grain, we include objects that are not part of an explicitly specified grain as such.

When an object 54 is in a grain, only said grain is a candidate to be marked as being the most developed. If a unitary object is not in a grain, it can be marked itself.

55 (by transclusion mechanism presented below)

56 The grains are noted in bold.

57 In fact, by design, the transclusion mechanism (described later) will not perform this spread. This is described in the section presenting the transclusion in "push". b2 without also replace c3 pi t provide inconsistent results, c3 gold as result of a change whose source is closer (in fact the source that is the object itself, since it is' a local change) there is no question of replacing it with c2. Thus, in the grain a3 is maintained the values ​​al, bl and c3.59 '60

Rules Rule 1 to Rule 6 set out in the preceding sections now apply to grain rather than the objects they contain. It will replace the object by the word grain in these rules and replace Rule 3 (or its variant 3v) with the following:

3g Rule: If changing a grain is accepted (upstream), this change is propagated to accepting grain. Then,

• each grain downstream grain accepted can be removed (and thus become an implicit grain) in the grain modification tree, if it reflects the content already 61 grain which is immediately upstream of to himself 62. If a grain and was deleted (marked as) the most elaborate, the nearest grain upstream (in the same branch) becomes in its place.

• If said modified accepted item is not deleted as well and if it is in a different branch of the accepting said object 63, the latter and its descendants (undeleted) to the first object from which a connection results (directly or indirectly) to the branch is located in said accepted modified object are moved to get into the same branch as said modified object accepted.

We will also add an additional rule:

Rule 7: When modifying an object in a grain makes the grain corresponding to the inconsistent downstream, it is automatically rejected.64 (This rule will be illustrated later in "Algorithms in Push").

Figure 48 shows that in the case where the grain a3 is refused by Rl or R2, from a2, a new branch is created from the branch where grains are the al and a2, a3 to contain.

As shown in FIG 49, in the case where the grain a3 is accepted by Rl (pursuant to Rule 3 g):

• In the first case, the grains of R 2 and R 3 can be deleted as inherit the grain Rl compound of objects al, b2 and c3.65

58 A concrete example is shown just a little further.

59 Indeed, there is always bl b2 because the amendment has therefore not been taken into account.

60 Note however that if the object then Rl is changed a2, that change will be propagated to a2 R2 grain and from there to a3 grain R3, although this torque b2-c2 values a2 (in R2) is inconsistent with the value of c3 a3 (in R3). Indeed, here one can imagine that a2 only plays an intermediary role for transit a change that comes over the upstream and it would not be advantageous for it "blocks" the spread upstream.

61 (automatically by transclusion)

62 We are then in the case of the example 1 above.

63 (as a result of the fact that objects that are upstream of said modified object accepted and downstream of said object accepting refused said modified object accepted)

64 This rule 7 unifies the concepts of "most recently changed object" and "the most elaborate object." Indeed, any change that does not spread to objects that are downstream (because incompatible) refuses to them automatically, and the modification in question is therefore done so on the most downstream object of the active branch. The modified object is necessarily as the "most developed" object that the object "most recently modified" of the active branch (since all the others that are further downstream are driven in another branch!) .

65 (thanks to the fact that there is no incompatibility between

• b2 and c3 objects that are part of the grain Rl

• and or modification resulting in the b2 object in R2, or modification resulting in c3 object in R3) • However, in the second ca o as the content of the new grain Rl (compound al objects, bl and c3) can not be propagated to the grain of R2 (consisting of al, b2 and c2) because of its local changes (b2 and c2), the grain of R2 does not reflect the new grain of RI and can not therefore be deleted o and as the grain of R3 is in a different branch (because he had been refused), said new grain has moved from R 66 in the branch where is the grain of R3 that he accepted; o in addition, the grain of R3 (al bl c3) can not be removed either they do not reflect the grain of the contents of R2 (al b2 c2).

The following section illustrates this method with a concrete example.

Slots (Fig. 50)

We can adopt a structure of "niche" in the values ( "InnerText" 67) parent objects, each pulse being a benchmark to include the contents of the child object that matches it. The main advantage of this approach is that it allows to consider any moving or deleting a single child object as a change for the (s) segment (x) to (s) of his (or her) object (s) Parent (s).

Figure 50 and has an R resource containing an object (a), which itself contains two objects (b and c) example in which the respective innertexts are as follows: •: "I would like to read a good book on { b} {c} "

• b "the first cars"

• c "before traction", which can present in R the text "I want to read a good book on the first front wheel drive cars." We will now illustrate again the advantage to specify that a (with its child objects b and c) as a grain. Rebuild the two case of the example in the previous section.

Rl call the original version of R (with the objects al, bl and cl corresponding to a, b and c).

R is derived by R2, R2 and R3 is derived, and then in R3, "FWD" (cl) is changed to "propulsion" (c3), resulting in the phrase "I would like to read a beautiful book about the first powered cars. "

Then in R2,

• In the first case, only "the first cars" (bl) is changed to "old cars" (b2), resulting in "I want to read a good book on old cars FWD" (al b2 cl) • in the second case, "the first cars" (bl) is changed to "hats"

(B2), and "FWD" (cl) is changed to "melon" (c2), resulting in "I want to read a good book on bowler hats" (al b2 c2).

So, in R3,

66 (pursuant to the second point of Rule 3g)

67 (in the sense of including XML)

68 (parent before displacement can be different from the parent after displacement - in the case of movement of a child object of a parent to first place it within another object that will be the new parent of said child object) • in the first case was "I airm IAU book on old automobiles powered" (al b2 c3) 69

• In the second case, because a is a grain, the spread can not be done and be always "I would like to read a good book on the first powered cars" (al bl c3). Indeed, the content of the grain R2 could not be propagated to R3, because: o "powered" can not be replaced as a result of a local modification o grain secures al, b2 and c3, which means that we can not spread without affecting b2 c3 c2 - indeed, it is clear that combining b2 ( "caps") with c3 ( "powered"), to form "I would like to read a good book on powered hats "would be inconsistent - gold source c3 is closer (in fact the source is the object itself as it is a local change).

When an object has a "InnerText" fragmented because interspersed with child objects, the niche approach is advantageous because it considers the atomic InnerText as globally. However, when this is not the case (that is to say when there are no parts of InnerText to manage), the approach of considering the movement or deletion of objects as changes for themselves and not their parent is more advantageous because it allows to operate at a more granular (the advantage is that the parent object is not globally "frozen" when an object child of said parent is moved or deleted).

Therefore according to the case, the process will implement the slots or not. Enabling the option slot (not niche respectively) can be automatic depending on the case as explained above.

In the following we will use the terms "subject" and "grain" interchangeably except when the distinction between them is explicit.

A method of sorting objects by alternative scoring (rating)

When the user selects an alternative object over another object presented him 70 rating the owner of the resource containing said selected object is incremented 71 and the ratings of the owners of resources containing unselected objects are decremented.

To put this into effect, the scoring (rating) of the owner of the resource containing each object selected by the user e; TFSS maintained within the computing environment 72 These ratings are related to said user 73.

Thus the alternative objects can be further prioritized automatically.74 For reasons of coherence, it is preferable that when an alternative object is presented, alternative objects from the same owner are selected and that they are even

69 For since "powered" can replace "FWD" (in the context of "the first cars"), a priori it should also go with "old cars" which according the user goes even better with "to Front-wheel Drive ".

70 (Le., Rather than the original object in the resource or that the purpose of replacement or alternative presented another object)

71 Similarly, when the user derives a resource in which there is a replacement object (the replacement object persists in the derived default page) and the user does not replace, the owner of the resource of where does this replacement object incremented sees its rating.

72 These ratings are for example stored and maintained in a log server.

73 An aggregate rating for a group of users is also possible.

74 They can be sorted in their presentation to the user and the one that is best noted can be selected to be presented for example alone. alternative objects chosen from corn other objects that are in the same resource presented to the user.

A method of sorting objects by alternative contextual relevance

The history of access to objects (or grain) 75 user (called navigation) can be modeled using a "context stack," where in theory each object (which can be presented to the user) is assigned a relevance score (regardless of the method used for the calculation) for the user at each level of browsing, and when an object is non-existent in the context stack it is equated with a object whose score is equal to zero.

When the user navigates to access a new object, the system 76 adds a level to the context stack.77

For a given object, the contextual score is an average of 78 non-contextual scores at each level of the context stack, weighted according to the depth. To avoid having to recalculate all scores each time, an exponential weighting is used, so that the contextual score at a certain level is the weighted average non-contextual score at this level and the contextual score at the previous level.

In other words, for a given object, s is the non-contextual score at the last level and r the contextual score at the previous level, 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 more lambda is, the more the past is important). Insofar as is known object for each alternative non contextual score of each other known object in the collaboration server in relation to it, you can select the alternative purpose for which the non-contextual scores of other objects relative to it is closest to the navigation context (ie closest contextual score at the last level of the context stack). Note that instead of considering all other objects can be satisfied with a set (smaller) of representative objects, such as categories and select the closest alternative object objects representative of the context.79

A method of substituting co-identification

The resources that are an ERC • can be shared by a set of users (at least read-only, such resources can be web pages constituting a corporate intranet)

• or not be shared (eg files, not directories shared a personal computer) and are then not accessible by all users of the ERC.

A non-shared resource must be imported, for example received by email, to benefit from the automatic replacement feature. In this case, if it contains a newer object -and identified 80 co-with- an existing object, then replace it. Indeed, the co-identified imported object is placed in the modified object tree and becomes more elaborate the meaning of Rule 5.

75 Alternatively, this procedure will apply to the granularity of resources rather than the granularity of grains.

76 (preferably this is the information manipulation tool)

77 However, when for example he clicks the command "Back" of its Web browser pops the system level.

78 (that is to say determined ignoring the context)

79 per select sort is also understood according to said selection criterion.

80 By co-identified objects are included objects having the same discriminant description, the meaning of Articles Guha obtained by semantic negotiation. A newly created object plays the MEM jjet imported in respect of his co-identified objects.

To be co-identifiable object must at least be characterized, in other words: the metadata that characterize must be filled. Here we propose a novel method analogous to the "brush-style" (to reproduce the layout) of a tool such as Microsoft Word, to spread information standard object description between different objects, characterized in that each object associated descriptive meta data, and in that the method comprises the steps of:

- entry into a mode of propagation to the initiative of the user, - the selection of an object of which is to borrow the description of metadata,

- the selection of at least one other object to assign the same description of metadata.

The user interface is adapted to mask the user with the description of metadata.

The same process is used to propagate publishing constraint meta-data, as described later in "spreading constraint Meta Data" section.

A method of transcluding

In the implementation that is described herein, the content of each resource derived under Rule 0 (see above "Resource Creation derivative" section) is transcluded from said accessed resource to be modified. Let us first recall that the transclusion, in the usual sense of the term, is the inclusion by reference. A classic example is the application of the tag "img" HTML that can include an image by reference. Transcluding is to create a view (the "result") of at least one object ( "source") and placing this order into another object ( "container").81 '82 transcluding technology which is described here to change the result of the transclusion. Indeed, the user must be able to change the content of a derived page (as heretofore described).

The user can define the changes to make by acting directly on the result of the transclusion, using a common tool for handling content such tool that allows him to manipulate the container (and its local content) or the tool he would use if he wanted to change the source. When the user and modifies directly the result of a transclusion, the results of the actions it performs (such item is deleted, the content of such other changes, yet another is moved and modified ...) are saved to can find these changes automatically the next time the object is updated. For example if the user exchange two parts of an object transcluded, when the content of this object changes to the source, the two sides will keep their new position but their content will always match that of the source.

81 For convenience, it arrives in a result that we write "transclusion" instead of "transclusion result." On the other hand, "transcluded object" means "object resulting from transclusion" (as opposed to source object) except where the context otherwise understand.

82 Objects sources can be remote. They are either identified directly or implicitly as a result of a search query. For example, it may include in a Word document, the result of a query to a database. To below as "the source (a transclusion)" means "the source object or all of the source objects (said transclusion)". When container is viewed by following a presentation of the source will be displayed at the location of the transclusion. In other words, every time the containing object will be opened or updated manually or automatically, the current version (that is to say the most recent) of the source will be presented at this site. To modify the result of trance] ven as if we were to change a local copy of the source 83, but without loss of connection to the source, is the primary characteristic of transcluding the technology described herein.

We will now describe some concepts that will be needed to understand the implementation of the process and describe the algorithms that will update each transclusion of the current version (that is to say, to update the resource in question derived ).

login

Each object has an ID. Objects created locally possess atomic identifier, which is a unique number in the system.

Similarly, each transclusion has an atomic username, also single.

Objects seen through a transclusion have a composite identifier, denoted A: B, where A (head of this identifier) ​​is the identifier of the transclusion, and B (the tail of this identifier) ​​is the identifier of the object to the source of the transclusion. Brackets are used to clearly delineate the head and tail when needed. In the absence of parentheses, the sub-identifiers extend the rightmost possible. For example, 1: 2: 3: 4 should be read 1: (2: (3: 4)). Another example, if A = I: 2 and B = 3: 4 then ArB = (1: 2): 3: 4.

Transclusion In this section presenting the algorithms, a transclusion A is considered one hand a set of objects "seen through" A, and also a set of changes (differences) on these objects.

Specifying a transclusion consists of the following two parts:

1. the result stored in the suite called "current version" 84, of the transclusion built after the latest version accessed from the source;

2. specification changes (hereinafter called "differences" 85) applied to the result of the transclusion.

The current version of the result of a transclusion is the result of the transclusion as it was presented last time the page was posted. This current version is retained, and is typically updated by the system each time the user accesses it.

It may be worth only store in the current version that the parties created locally, and the rest to keep only references where it can be obtained.

The differences, in turn, indicate the source or sources of the transclusion, and changes to apply them. In the approach described here, the differences are based on the current version 6 and thus not need to contain "verbatim" content and positions of objects to change.

Typically, once the changes made by the user (in the derived page) to the result of transclusion content have been detected and stored in said differences,

83 (the remaining results still maintained relative to the source, but changes made to the result precedence over changes occurred at source)

84 (or "content of the derived resource")

85 (or "changes")

86 The differences refer to objects of the current version (that is to say their respective identifiers) to define their transformations are applied. the next time said de page: idea (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) for content and positions of changed objects. These changes include

• modification or deletion of an object seen through A (therefore whose ID begins with "A:")

• movement of an object viewed through A, whose parent before and after displacement is also an object seen through A. • creating an object (locally created or viewed through a different transclusion A) as a child of an object seen through A.

• movement of an object viewed through A as a child of an object created or viewed through a different transclusion A. A special case is: 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 available (because no object seen through transclusion this is still placed as a child of an accessible object.) the second step is then nothing but a movement of one of these inaccessible objects as children of an accessible object.

Note that in case of moving an object from a transclusion to another or create a transclusion in another transclusion, this change will be "shared" by two transclusions.

Also note that when a falling result transcluding is moved out of this result, it is necessary to create (in addition to the displacement information in the differences of the transclusion) a second item "Result transcluding". In XML terminology described below, it means that there will be two nodes "Transclude" with the same identifier transclusion ( "id" attribute).

By convention, we say that implicit transclusion contains no changes. Indeed, we say that such changes will be handled by the transclusion in which this implicit transclusion came. For example, if an object ((1: 2): 3): 4 is changed, this change will be associated with the transclusion 1.

The differences can be in XML format as illustrated by the following example:

<Differences id = "8">

<FirstSentences id = "8" ^ count "3" keepChildren = "true" />

<Modify id = "8: 2" /> <Move id = "8: 3" />

<Modify id = "8: 6: 4: 3" />

<Move id = "8: 6: 4: 3" />

<Create id = "9" />

<Delete id = "8: 5" /> <Transclude id = "10" ref = "document7 # 7" />

</ Differences>

In this example, the node Differences indicates the identifier of the transclusion, which is then referenced in a Transclude node at the location of the result.

Then all the children nodes of this node Differences indicate changes to be applied to the source of the transclusion to construct the result. The "id" identifiers refer to the current version of the transclusion. In the example above, FirstSentences ir which selects the first sentences of a content object (see below under "Transclusions with transformations").

In the case of objects created (Create), modified (Modify) or moved 87 (Move), new content and / or position are obtained in the current version and thus not specified in the differences.

Transclude indicates a new transclusion within the transclusion in question and thus refers to another object of the differences (the id = "10" being the identifier of the transclusion, which is associated with another object Differences and the ref . source transclusion in this example, the identifier of the result of this transcluding will be 10: 7. note that the source can be identified by a reference or query)..88

This example also shows that to move and modify the same object (8: 6: 4: 3) placing two operators in the subject differences.

All of these operators can be implemented in modules so that new types of operators can be added to the system to extend its capabilities. In this example, FirstSentences has been selected by the user in a list (expandable) operators at the time of or after transclusion by associating them.

Recall that changes Move, Modify and Create were created by the user by acting directly on objects, just as if it modified a local version.

The user can request that the content of the source of a transclusion is not included, but a simple hyperlink is placed as a result, pointing to the source or sources. Differences The object, in this case, would look like:

<Differences id = "18">

<HyperLink text ^ 'click wretch "/> </ Differences> The Differences object can usually be omitted since the presentation of the result depends more on the content of the source and should be updated. In fact we do not treat differently a hyperlink placed directly and transcluding presented as a link.

Similarly, a reference or relationship (unilateral) any one object to another is a transclusion whose result is neither built nor presented (or even contains a simple hyperlink).

If the information is in XML notation, an object is an XML element, and the content of the object is "InnerText" of the XML element. The attributes and children are both considered child objects, however, attributes the same attribute name from different sources must be merged.

87 In the approach of "niche" described above, there is no object moving operation as such because a child be traveling back to change (the InnerText of) his ( or) subject (s) the parent (s).

88 We have seen that the overall content of each resource is derived transcluded the overall content of the source resource. Transcluding but the method can also be used for transclure, in a derived page, any object in any page. Thus, a derived page can be used to assemble objects in external pages. Thus, the "differences" related to the result of transclusion constituting the content of a derived resource, can themselves include transclusions. These can then themselves get replacements and enhancements from replacements and enhancements of the source. Each result object of a manual transclusion enjoys major advantages described herein (ie replacements and enhancements), provided that the source is in a resource managed in the same ERC. Said object will thus be automatically replaced with a replacement object according to Rule 5 and enriched with alternative objects according to Rule 6, applied to said source. However, if for a given object are determined more replacement objects, additional objects obtained from the downstream branch out transclusions are considered alternative objects. implicit transclusion, transclusi

When the result (3: 2 in Figure 51) of a transcluding (3) is visible through a transclusion (4), we say that the image of the result (4: 3: 2) is the result of an implicit transclusion (4: 3) of the image (4: 2) of the source (2) of the first transcluding (3), and this first transcluding (3) is called internal transclusion second (4).

In this example, the image (4: 2) of the source (2) of the inner transcluding is also visible through the transcluding (4), but this is not always the case. Otherwise, the source of the internal transclusion will simply invisible. The example in Figure 51 gives a concrete result. In this example, we can say that 4: 3: 2 is an indirect transclusion 2 because the changes applied 2 will be indirectly transmitted to 4: 3: 2.

When this structure is viewed through the transclusion 5, indirect transclusion is maintained, although it passes through an invisible object (5: 3: 2). Thus, the changes applied to 5: 2 will be passed on 5: 4: 3: 2. Alternative identifiers

The existence of an object can sometimes be achieved by several routes, in the presence of implicit transclusions. In the example of Figure 52, 4: 3: 2 is both the object 3: 2 as seen through transclusion 4, and the object 4: 2 viewed through the transclusion 4: 3 (3: 2 4 and 2 are the two sources of the object 4: 3: 2). Considering the second way, we obtain the ID (4: 3): 4: 2 (parentheses are placed in order to clearly identify the head of this identifier).

In practice, we will consider these two identifiers as equivalent, and generally qquuee ttoo ttoouuss AA ,, BB ,, DC ,, ((AA :: BB)) :: :: AA CC eesst equivalent to A: B: C.89

Calculation of the sources of an object

Each object having a composite identifier has a set of sources 90 shown by different shapes (equivalent) Ti: Si of its identifier, where If is the source and the Ti transclusion through which it has passed. For example, sources of 4: 3: 2 are shown by 4: (3: 2) and (4: 3) :( 4: 2).

The calculation of this assembly is thus carried out: It begins with a form T 0: S 0 of the identifier. Either Ti ': If' the transclusion source S 0 pairs. All sources is represented by (T 0: Ti ') :( T 0: If') for each i, in addition to T 0 = S 0.

Origin of information

By calculating a structure we will combine two types of information are its location and its contents (except his children - that a child object A is an object B is stored as position A). Both for the position for the content we associate an origin of the form 91 P, O.

89 is described later the concept of density that will include determining the equivalence of identifiers.

90 A composite identifier formed only two atomic identifiers will have only one source. For all we included here the case of a set of one item.

91 (CheminlOrigine) Distance sources

An object can have several sources, it will be necessary to determine the importance of these sources so that when several of them are changed, it can be determined where the object must inherit information. The goal is a "close" provider has a stronger weight than a supplier "remote". Here "remote" means through a transclusion more "high" (inclusive); e.g., transcluding 4 is higher than the transcluding 4: 3.

Rule 8 If there are multiple candidates for the content sources (or position) of an object, it is preferred that whose proximity is the largest (or one whose distance is the smallest).

first method

A first method is based on the concept of "density" identifier. It is noted d (X) density of an identifier X.

A density is in the form ΣS x d x where x S is a polynomial in s and x is the atomic weight of the identifier x. S polynomial x above is called partial density of x in X.

The density is calculated recursively as follows (s is a symbol without numeric value):

The density d (n) of an atom is a n.

The density d (A: B) of a composite identifier A: B is (bs) d (A) + sd (B). As everyone knows, a polynomial simplification algorithm is to replace all the products are amounts by product and for each x to group terms of x.

For example: d (4: 3: 2) = (bs) d (4) + SD (3: 2)

= D4 - sd (4) + s ((I -s) d (3) + SD (2)) = (1-s) (4) + (ss 2) d (3) + s 2 d (2 )

Similarly, another form of the density of this identifier is: d ((4: 3): 4: 2) = (ls) of (4: 3) + sd (4: 2)

= (1-s) ((1-s) (4) + SD (3)) + s ((1-s) (4) + SD (2)) = (1-s) (4) + (ss 2) d (3) + s 2 d (2)

Calculating the proximity of an object relative to another

To calculate the proximity of an object relative to a P R object is replaced in d (P) each of x by the partial density of x in A. This gives a polynomial in s.

The algorithm for comparing such poynômes 92 is as follows:

1. Initialize j 0.

2. If a j <b j then A <B

3. If a j> b j then A> B 4. Otherwise increment j and return to 2.

Consider 92 as s approaches zero while remaining positive. For example, 2s 4 <4 s + 3 s <2 s 4 s 3 + <s.

We use the term proximity as more the value is more the object is close.

second method

When an object transclusion encompassing descendant objects of which is transcluded from each other must be defined for the transclusion between descendant objects from the object transcluded covering a shorter distance value to be decided between these objects.

Thus the "length" of a transclusion can be determined as follows. They give a length of 1 to non implicit transclusions (thus having one term in their identifier), a length a little smaller 1- δ (δ tends to 0) to implicit transclusions having two terms, even a little small (l-2δ) to transclusions having three terms, and so on. So given the value 1- (w-l) to δ transclusions having n terms (term means the atomic component identifiers transclusion, for example (1: 2): 3: 4 contains four terms).

To compare the respective distances from two sources, we sum the distances by which each transclusions passes and first comparing their terms without δ and if it is the same in comparing their terms with the most δ. The nearest source is and that for which the distance is the shortest.

We say that for a local change, the source is a zero distance. So when comparing a local change to a change from upstream, the same rule applies and the local modification and has priority over any other source of change propagation.

The process of transclusion in "pull"

We will now describe a first method (so-called "pull") to implement the transclusion. Further another section will present a variant (so-called "push"). firstly be described a "local algorithm" for determining the content and purpose of a position and a "global algorithm" which, by relying on the local algorithm to construct an object and all his descendants.

It will then be enough to update a current version, called the global algorithm on the root of the current version. Calculation of an object - local algorithm

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.

Bracketed noted step in the algorithm.

We calculate the two types of information, that is to say the position and content of an object independently but the algorithm is similar we will implement a generic algorithm to calculate so-called Y information (then specialize).

We first need to know if the information is produced by the object itself. In the case of an object created, this is always true. If the subject comes from a transclusion, it maintains a list of modified objects (in its differences), which allows to know if the information was produced by the object itself or not . [Locall]

93 can alternatively take the approach of slots, previously described, to consider that the movements are modifications of parents and avoid dealing movements differently modifications. If the information is generated by the object 1 is original! X (where X is the ID of the object). [Iocal2]

If the information is not produced by the object (X) itself:

Either Ti: If all pairs transclusion- source for this item and either Pi Oi all origins (original path!) For these sources 94!. [Iocal3]

the proximity of each Oi is calculated with respect to X. [Iocal4]

Is closest O j. The source of information for X is TJ PJ OJ [Iocal5] and the information is obtained for X TJ: S j [localό].

If Y calculated information is the content of the object, it will simply be copied Tj: Sj.

If that's his position, he will not be copied but the identifiers (parent predecessor F and B S j) will be extended with T j. The parent of TJ X is F. Information parent has priority over the information of the predecessor. So if TJ B is not a child of TJ F, X will be placed (by convention) as the last child of TJ F. Otherwise it will be (by convention) just after TJ: B. [Iocal7].

Calculating an object structure - global algorithm

Each object must remember that he has been treated by the local or global algorithm, respectively, so that each algorithm does not process any object more than once.

X refers to the object that is running the current passes from the global algorithm. When X is a locally created object (and thus has an atomic ID), its content and the list of her children are already known, so it just has to run the global algorithm on her children. The origin of the information (for its position and its contents) is of course right! X. [Globall]

If instead X comes from a transclusion, or Ti: If all sources. Then run the local algorithm on the following objects:

• X itself (for content) [global2]

• For each i, for each child ij Si, Ti: ij. [Global3]

• All objects transclusion moved or created [global4].

Then the overall algorithm is performed on children of X. The process of transclusion to "push"

The Lee pprrooccééddéé uu ttrraannsscclluussiioonn iinn "" ppuusshh »» 9955 ppeeuutt eêttre implemented through three tables managed in the collaboration server and in which the differences are stored 96:

94 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 always eventually reach, going up the transclusions, objects providing local content, ultimately reaching the objects not in a result of transclusion.

95 This approach can be used to update the results of persistent queries to a database. Take the case of an RDF database (see W3C Recommendation) (thus containing triplets {object property, object}) and a query language such as SPARQL (see W3C Recommendation). Can be modeled space triplets in the form of a tree structure where the nodes represent triplets

"Abstract" (each element of an abstract triplet represents the sets of possible objects or properties) and which leaves represent the existing data in the database.

Each persistent query is a subset of this space, that is to say a set of sub-shafts (represented by a set of abstract triplets). When a set of triplets concrete that is to say, • Table of Transclusions

• Table of Local Changes

• Table of changes (from) Upstream 97

This approach can propagate changes objects sources of transclusions, on the results of the transclusions, following the latter through the table of transclusions.

The idea is that any transclusion is indicated in the Table of Transclusions, and any outcome of transclusion, if it is directly modified itself, information about the existence of this change is shown in the Table of Local changes, while if it has to be updated due to a change made to the upstream, information about the existence of this change and the address of the modified object 98 are in the table of changes from Upstream.

To access a resource R, normally extending the information manipulation tool gets its current version from the server that hosts content. Meanwhile he asked the Upstream's Changes table if there have been changes to this resource (and for which objects there have been changes), in which case returns Table 99 addresses where the objects in question are. So the extension of the information manipulation tool obtains these objects and assemble them in the current version received for the resource in question to obtain a new current version 100.

When a change (local) is performed on an object O located in a result of transclusion in a resource R, the server hosting R is informed, the (or) entry corresponding to said change is inserted into the Changes Table local, and like any local change overrides any updates due to changes coming from upstream, the (or) entry is deleted in the Table of changes in upstream. Furthermore, in the case where in the Table of Transclusions is indicated a source transclusion taking as the object O itself or one of its ancestors, information regarding the change of the corresponding object resulting from this is added to transcluding Table of changes from Upstream. This information also contains the identifiers of all the ancestors of said corresponding object, so that if another transclusion indicated in the Table of Transclusions has as source said corresponding or item of its ancestors, another information is added in the Table of changes in the Upstream, and so on until there are no more corresponding transclusion in the Table of Transclusions. Each new change information of an object resulting from transcluding is added with the distance information between the source object and the result object. Thus, whenever a change is to be added in the Table of Changes from Upstream for the same result object, it is actually

leaves of this tree are changed, we will propagate this change in push, that is to say re-execute the relevant persistent queries that are simply the ancestors of the modified concrete triplets.

96 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 ...

97 Note that with Rule 8 (which provides for a zero distance for local modifications are made) table changes from upstream could suffice.

98 If one is not in the niche approach, it is a movement or removal of items you will store the credentials of the parent and predecessor (if any), and the algorithm will separately retain the source having the shortest path for the content and for the position.

9 If you are not in the approach of niches and that is a change of position, the parent and predecessor (if any) are returned.

100 Advantageously 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 included in the current release and therefore does not have to go get it back. Obviously, when a new change of the same upstream object is deleted this indication in the input in question. added only if the distance to the s transclusion considered is less than the distance information if any existing (in which case it replaces).

Note that in this approach, it is not necessary to store in the Table of Changes Upstream information concerning the change of an object from a new transclusion, since the change is already taken into account already in the current version, and when the nearest source will be modified if necessary again, an entry will be inserted in the Table of changes in Upstream.

However, if the objects are changed frequently it may be advantageous to insert information concerning the change of an object resulting from transcluding the first time, that is to say when the entry corresponding to the change is newly established in Table local changes. In this method, when a new transclusion is inserted in the Table of Transclusions, the information for all the objects in the result of the transclusion are inserted in the Upstream of Changes table with their creation date. Moreover, a change of date is stored (and maintained) with each entry in the table of the local changes. Every access to a resource, the date contained in the Table of Changes in Upstream is compared with the date of the change of the source in the Local Changes Table. If the modification of the source is newer then it is requested to the content server and the Upstream of Changes Table is updated with the new date. Note that during the execution of the algorithm, it is not only view the table of transclusions but all the movement information in the table of local changes. Figures 53 and 54 illustrate why this is necessary.

In the first of the two patterns in Figure 53, a transclusion (the object) is performed 1, then 10: 4 is moved in the result. Then, in the second scheme of Figures 53, 4 is moved to the source out of the tree 1. 10: 4 does not disappear with the result because its position was fixed during the movement. The content of 10: 4 must remain synchronized with that of 4 (for example, if children are created to 4 then the corresponding objects should be visible as a child of 10: 4).

When 4 is amended, 4 and all its ancestors are searched in transclusions table and in all trips listed in the table of local changes. Thus the entry recording the movement of 10: 4 will be found, which will propagate this change.

Figure 54 shows a second scenario.

This is a movement of 10: 4 out of the result of the transclusion. Again we want the synchronization between 4 is 10: 4 is ensured, and it works like in the above scenario if we also take into account the displacement of 10: 4 in the propagation of changes, so somehow 10: 4 is seen as the result of a transclusion (virtual) 4. 101

The composite structures push algorithm is interesting when changes upstream are less frequent than the access (or refreshments) downstream, especially when the source is within the system and therefore the latter can 102 automatically be informed when modified.

101 What the current version is updated or not, we can maintain (in the collaboration server) the whole structure of the results of transclusions so that the ancestors lists are always correct.

102 (it is the collaboration server) In some cases it may be mixed should wish structures where transclusions chains are partially and partially pull push (transclusion each can operate in either push or pull, independently of the others) .

No special work is necessary in the case "push-pull", ie when the transclusion in pull of a result of transclusion which it operates in push. Indeed, when the object is changed at the upstream, the intermediate object is notified (ie an entry is placed in the table changes from upstream). The object downstream is not notified, but, operating sweater, it will consult the intermediary object when it should be displayed, and will see the new content of the latter. This configuration can for example be useful when the object is rarely modified but upstream intermediate object often is.

Figure 55 shows the evolution of current versions when changing upstream. The first line shows the state before modification. In the second line in the upstream direction is changed, and the change is reflected on the intermediate object but not the object downstream. The last line shows that the change is observed in a request to the downstream (the content of the intermediate object is copied to the downstream).

If "pull-push" request against a particular treatment. Indeed, a change in the upstream will not spread to the intermediate object, by nature pull of the latter, and a request for the object to the downstream will not cause a request to the intermediate object, the changes upstream table was not changed. This situation is treated as follows:

By building the current version is downstream brand items that the content (or position) was obtained by the upstream, with direct references to the location of this content. When the object is displayed in the downstream, it performs an update of the parties, sending the request directly to the object to the upstream (and if it is itself the result of another transclusion sweater , the query may continue therefrom, in a cascade, in the normal operation of the pull algorithm).

This is useful if the differences applied through object does not change often, and instead subject to the upstream is frequently changed or can not send update notifications in change tables (by example in the case of an external object). The advantage of this approach is that it has the advantages of the "push" method (avoiding cascade queries while the user waits) and the advantages of the pull method (the object at the upstream is interviewed when necessary).

Figure 56 shows the same scenario as the previous figure. in the first line that the downstream object seen contains a reference to the object at the upstream, indicating that this content should be refreshed (sweater) for each request.

When changing upstream, it is not referenced by a transclusion push, no content is transferred. When the request for the object to the downstream, the content is updated, via the reference found in the current version. You can see the last line that bypasses through reference object, and that it is never updated or even questioned, in this scenario (indeed, any changes to the intermediary object is automatically sent to the object to the downstream by the push method).

We can obviously be arbitrarily complex structures such object that contains transclusions in push and transclusions sweater and an alternating push-pull-push -.... Apart from marking functionality (the "push" algorithm) sources obtained sweater, as the push algorithm (invoked in the downstream direction when modifications) that pull algorithm (invoked in the upstream direction during read access) must ignore transclusions in the opposite mode. Figure 57 shows an example a little] he three transclusions cascade in the push-pull situation. The objects in solid lines are changed locally, and not those in dotted lines. The dotted lines arrows indicate references to obtain sweater, and the dotted arrows indicate references to only check whether new children appeared (Finner-text being obtained in the current version in these cases).

centralized architecture or cascading

Both pull algorithm that push algorithm can be implemented either by a centralized architecture (with collaboration server) by a cascade architecture.

First is a description of the centralized method. The collaboration server manages tables transclusions and tables of local changes (describing the objects differences for transclusions).

In the case of the push method, it is the content servers or extending the information manipulation tool that informs the collaboration server for a change to be made in these tables, while in the case of pull method these tables work like a cache, the collaboration server up to every request, question content servers.

Thus, the algorithm entirely in the collaboration server and content servers do not communicate.

The cascade method works as follows. We no longer use collaboration server, and it is the content servers that each run their tables transclusions and local changes. For transclusions in push, the tables indicate transclusion 103 servers to contact if local change, while for transclusions sweater, the tables indicate the servers to query when a query. That is a content server knows the results of transclusions in push which contains the source, and sources of transclusions sweater which contains the result.

The centralized architecture has the advantage that if a content server is unreachable, the difference tables stored in the collaboration server are used and the algorithm still works at worst with a version that is not the newest or some with missing content. The advantage of the cascade architecture, on the other hand, is that the treatment is dispensed and can be more effective in the presence of complex structures transclusions.

One can also consider a mixed architecture, with several collaboration servers, each responsible for a number of objects. When transclusions which both the source that the result are managed by the same collaboration server, centralized method is used, and each collaboration server change, the cascading method is used.

Figure 58 shows an example with three collaboration servers. The rectangles are collaboration servers, and small circles are objects. The large circles consolidating servers to work with the objects they treat. The arrows show transclusions.

The continuous double lines represent the parts of the algorithm working centrally, while the broken double lines correspond to the cascade communication. The server in the middle gives an example collaboration server degenerated to that is an object, which is the case of an object that works only waterfall.

103 The data in question (references and differences) are not necessarily stored in tables but can also be in the contents themselves. Spreading branches contributions

We will now show how to integrate the system of replacement of objects and alternative contributions to a structure of objects containing transclusions.

For a given object is called "source created" the most distant object that is accessible via a transclusions chain (implicit or otherwise). An object created locally is its own source created.

Any replacement and alternative objects of an object will thus have all the same source that created the object.

We define an order relation (created) objects with the same source created. If these objects were not created simultaneously, it is the order of creation (creation mean the moment when the object began to be accessible, even if it had an existence implicit).

When several objects are created in the case of internal transclusions, order new items correspond to the order of their existing sources. Figure 59 gives an example. The numbers indicate the order of children's creation. This sequence was obtained as follows.

First only existed objects a and 1. Then was performed transclusion whose result is b. Implicitly this caused the creation of 2. Then was created transclusion 3 whose source is 1. This caused the implicit appearance 4. 3 and 4 are thus appeared simultaneously, and thus applies the rule that the child 1 existing before the child 2, the corresponding 1 is believed to have originated before the corresponding 2.

Then is performed transclusion whose result is c. This causes the simultaneous appearance of 5 and 6. Again, about 5 <6 is selected to match the order of their immediate sources 1 <3. This order is established, the operation of replacement of objects is the same explained above, that is to say, in a set of objects with the same source created, the most developed is one that was created the later, and provides local content. If an object is changed locally but at least one more elaborate object that created the source had been created later and is incompatible with the modified content 104, then the first most elaborate object (and the following in the same line) is (is) displaced (s) in a new branch (Rule 7).105

Variant

In this alternative method is not taken into account the order of creation of objects but rather the transclusions structure. First, it does not change branch of objects (or creates branch) as long as there is no explicit refusal (replacement item).

The replacement object for a given object is the latest content with 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).

104 See description of grains.

105 Another way of seeing: in all some objects explicitly specify in what branch they are, while others implicitly follow all movements of their predecessor. Thus, when an incompatible object must be placed in another class only it will be imposed an explicit selection branch and the following implicitly follow. When a user declines an object in two different situations may occur, depending on the way forward to achieve the object since replaced the replacement object, according to the relations transclusion, If the road goes towards the upstream of the replaced object, while the latter moves into a new branch. If instead the path going toward the downstream of the replaced item (so that the replacement object is a descendant of the replaced item), then this is the replacement object which is moved to a new plugged.

These changes course industry does not alter the existing relations transclusion. Figure 60 illustrates three cases. The tree structure represents the transclusion structure (each object is image transclusion one shown above it, and all the objects prior to refusal, are in the same branch).

Hatched circles represent the object that performs the refusal (the replaced object) and the dotted circles are refused the object (the replacement object). Dashed lines denote the region that will be moved to a new branch.

When an object thus moves into a new branch, all its children that do not explicitly specify the branch in which they wish to follow their parents in the same branch, and this continues recursively with their children.

Behavior of the grains in the presence of transclusions Now back to the previous approach. To see how the transclusion articulates with the previously described process of "Replacement / Grains Rich" 106, will now expand its data structure (grain modified trees), to also represent transclusions. We will illustrate that resources leads back to transclure all their content; we will also illustrate the case of manual transclusion performed in a resource that can drift.

Figure 63 extends the "Case 2" in the example in "Replacing / Grains Rich" section. The objects of this figure are introduced in Figures 61 and 62. Figure 61 shows that in the resource R, the grain is now contained in a subject and, within the latter, it is reproduced by transcluding (the grain is transcluded to the right in Figure 43).107

Figure 62 shows that R (it is the resource R of Figure 61) is derived by R2 and the latter is derived by R3. Both leads give rise respectively to transclusions "2" and "3". Thus the transclusion "2" of results in 2 d and the transclusion "3" 2 of itself results in 3: 2: d. Moreover, the same figure 62 shows the transclusion "1" of the grain in the subject, which gives rise to implicit transclusions "2: 1" and "3: 2: 1" in 2: d and 3: 2: d respectively.

The identifiers of objects in d, 2 d and 3: 2: d are prefixed according to the transclusion that gave them birth. As already described, the objects that are the result of several transclusions which at least one is implicit have several possible sources. It is always from the nearest source that can spread to other changes.

106 See above "Replacing / Grains Rich" section.

107 This will allow us to have implicit transclusions in the example. In Figure 63, hatched rep objects that have been modified locally (and therefore are identified in the table of the local changes). Assume the following steps:

1. d in R2 and C in the grain a3 (in R3) have been modified first - c thus takes the value c3, and thus takes the value d2. And d2 and a3 become more sophisticated 108. At this stage, c3 a3 grain propagates toward the grain 3: 2: l: a3. In addition, in Rl, s object (the InnerText al grain of the root node) is modified a4 and subject 1: al is modified by a5 in the grain l: al (the latter is the grain transcluded al, always in R). These changes will propagate respectively to a2 and a3 and about 2: l: a2 then 3: 2: l: a3.109 2. Then bl and cl in the grain a2 (in R2) are modified in b2 and c2, and in R3, d2 d3 is changed. Accordingly changes (b2 and c2) in the grain a2, as these changes are inconsistent with the change in the existing c3 a3 grain R3, the latter (a3) ​​is automatically refused (Rule 7) and finds herself in another class (pointing to the right in Figure 63). As a result, the grain a3 and a2 grain are both more elaborate (in their respective branches), which is shown in Figure 63 with a star. However, b2 and a2 c2 changes propagate well in grain 2: 1: a2, but from it they can not spread to 3: 2: l: a3 because c3 that already exists in 3 : 2: l: a3 (a3 by propagation in step 1) has a source closer than the source of c2. Moreover d3 is also the most developed (as shown with an asterisk).

3. R2 in the grain 2: 1: a2, c is changed locally to take the same value as in c3 a3. Accordingly c3 of 3: 2: l: a3 (and from a3) does not represent an obstacle to the propagation of b2 (representing a nearer source) grain 2: 1: a2 towards the grain 3: 2: l : a3. Note that, from the point of view of the shaft of the object changes (with respect to the marking of more elaborate objects) grain 3: 2: l: a3 is now implied and is the grain 3: 2: l: a3 which is the most developed (asterisked in Figure 63).

Figure 63 shows the situation after the final stage (that is to say after step 3 above). In Figure 63, the objects covered points represent objects that are in the table changes from upstream (and are therefore modified propagation of local changes result).

In Figure 63 the distance represented by each transcluding has been indicated in brackets.

As the collaboration server does not store the values ​​of the objects but only their identifiers in the collaboration server can be associated with these identifiers code (checksum) by the method Cyclic Redundancy Check (CRC) known per se or a similar method. Thus, in FIG 63, in step 3 of the example given above, the value of c3 in 2: l: a2 is used to propagate the values ​​of this grain to grain 3: 2: l: a3 through the fact that the checksum c3 2: 1: a2 is equal to c3 a3 grain. Counters of activity

To measure the "activity" 110 resources and some of the objects they contain, include counters associated with each (or some) node (s)

• representing an object in a modified object tree,

108 As explained above, one grain (or objects belonging to no grain) can be the "most developed".

109 These paths are taken because the spread will follow the shortest route, as explained below (distances of each transclusion are indicated in brackets in the figure).

110 Quantity or access by users frequency of diversions, transclusion, etc. • representing a resource in u vation of resources,

• additional associated with a resource, representing a non-editable object in this resource.

These counters are used in particular to measure "the number of times a given object created or transcluded in a resource is in a resource derived from the latter and / or

• the number of times a given object created or transcluded into a resource is presented in this resource or a resource derived from the latter and / or

• the number of times a given object is transcluded, or "the number of times a group of objects including a given object and all its descendants (downstream) in the modification of shaft objects corresponding to it, is transcluded by derivation or merely consulted,

• the number of times that a given resource is derived or simply consulted,

• etc. Objects container, TransClusion-merger, Automatic Placement

Figures 64-88 show transclusion operations through a file browser, in this case in Windows Explorer.

Recall that each object is potentially a container 111 in the sense that it can contain other objects (child objects). • Consider now 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 which may contain himself preexisting container objects; • and that each container can be specified constraints (or preferences) over properties of objects that can receive.

At a transclusion molten mode of a source object to a destination object, the value (InnerText) of the source object replaces that of the object (root node) recipient and children are automatically selectively placed in the container contents in which the recipient object and the associated constraints are consistent with the properties of said child objects. Optionally, if no recipient container object does not exist or can receive an object from the source 113, a "pick-rest" container is created and said object from the source is placed directly into it.

Figure 89 illustrates a directory transcluding-merger (objects typical containers) that are reorganized so that the contents of directories A and C, as well as the contents of the directories themselves contained in A, go to the directory A ' , the content of B goes into B 'and all other objects go in C. 114

111 ( "container" in the Anglo-Saxon terminology)

112 (depending on the mode of transcluding selected by the user who performs the transclusion)

113 (as with the constraints that are incompatible with it)

114 As this figure 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 date of creation or last modification can for example also represent such properties. FIG 90 shows an example where: place automatically, in a document containing container objects (such as cells of a spreadsheet worksheet), links to the documents contained in the source of a transclusion, depending the properties of the latter.115 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 to a destination container to another (within the constraints associated with the latter); and when a stress of a destination container is changed, its contents can be moved to another destination container. Hereinafter called "domain" of a container, the set of all possible objects having properties compatible with the set of constraints associated with this container. And called area of ​​an object all values ​​compatible with its properties.

A metric is automatically associated with the width of the area of ​​each container, and in the case where several containers can receive an object in question, the selected container is the one whose area is the smallest.

For example, a metric S can adopt defined as:

• S (p) = 0 where ψ <ψ <1, and 'p' is an atomic property

• S (~ P) = 1 - S (P) P, P 1, P 2 are set PROPERTIES

• S (P 1 HP 2) = S (P 1) S (P 2) • S (IPPU 2) = S (Pi) S + (P 2) - S (Pi) S (P 2)

• S (Pi-P 2) = S (Pi) (I - S (P 2))

Children containers inherit properties of their parents and in addition (D) their own properties.

At a transcluding molten mode, the method consists of transcluding 1. Search for each object 116 all the source destination container whose area is equal to or wider than that of the source object in question;

2. in the case where there are several, use a metric (described above) for measuring the magnitude of each field and determine the receiver container whose area is the smallest; 3. propagate the source object in said container and the smallest selected.

The objects children can be placed automatically in the recipient subject of transclusion.

Conversely, the domain of a container can be extended with the properties of objects that the user puts it "manually". This method will give container properties of objects that are inserted without explicitly mentioning these properties. So it's sort 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 area of ​​the object placed. Finally, if the object belongs to a "class" (the taxonomic sense) different from the class of the container, it can make the class of the object subclass of the class of container. The object placement thus becomes a tool to create a taxonomy.

Another way (or complementary) to proceed is to base learning on the content of inserted objects (eg by learning Bayesian naive). In the case where

115 This example further implement a transformation that replaces chaqe source document by linking to it.

116 In the case of a grain composed of several containers, they will be taken together. learning does not correspond IAU user, he may correct the learning by placing also an object placed automatically. Based learning content is complementary to learning based on the properties of the contents since the first will be used when the second can not be or when the second leads to ambiguity.

Finally, a third method is to retro-spread objects, that is to say, to propagate in opposite direction of the transclusion- fusion. This is necessary particularly when a change representing replacement or alternative object must be propagated upstream. This is done as follows: When the item placement, the method comprises an additional step of storing an association with the source container. When all objects in a destination container come from the same source container, every new object added to the destination container will automatically back-propagated to the source container. In other cases, select a source container that includes the domain of the destination object to rétropropager and / or has the largest intersection with the field of the destination object rétropropager. And if the area of ​​the container that has the largest intersection does not include the area of ​​the object destination rétropropager, expand so as to include it. Finally, one can also place the retro-spread object in a container pick-rest as mentioned above. Conditions associated with transclusions

The owner of an object (sub-objects included) may constrain the possible transclusions from this item. When the user tries to transclure a source object, conditions or options to choose from such as the following may be presented:

• The object can not be transcluded • The object (or one or some of its child objects) should not be changed

• The object can be transcluded, but should not be republished

• The object can be transcluded and modified but release republication should be addressed to the owner prior to republish and o II may be republished (pending response) as the answer is not an o II refusal can be republished only when a reply of acceptance will be reached - note that in this case the law allows in certain cases a short quotation is published; effort will be an automatic system for such a publication and its automatic replacement by the normal publication as soon as the acceptance happens if any.

• The object can be transcluded and modified, but the contributions made to the downstream should be automatically available to the owner and already it has the right to republish. o When a downstream contribution is well accepted, "the owner and downstream can publish

• only the downstream can publish

• only the upstream can publish. o When a downstream contribution is refused,

"Neither endorsed nor the owner can publish such contribution" only the owner idity contribution

• downstream may publish such contribution. Also the same conditions can or should be reproposed further downstream.

The owner downstream of the transclusion can compel publications upstream. Thus, when the modification of an object (sub-objects included) dates to be presented to the upstream, the upstream owner can see especially the offer or the conditions or options to choose from the following:

• The object can not be changed

• The modification presented may not be republished • Republication (without modification) allowed only after issuing a sense o request and receipt of acceptance o or pending and acceptance as a refusal is not received.

• The contribution of the downstream can be further modified upstream, but republished by the upstream only after transmission by the upstream of an acceptance request from the downstream O and after receiving the o acceptance or pending and acceptance as a refusal is not received.

• When re-modification is accepted by the upstream downstream, where upstream and downstream can publish only o upstream can publish o single downstream can publish

• When re-edited by the upstream is refused by the downstream downstream can still republish. Also the same conditions can (or should) be reproposed more upstream.

Architecture customization

The transformations and conditions described in previous sections, and other processes described so far (transclusion, replacement of objects, presentation of alternative objects ...) can go into a general "personalization" framework that can will now be described. We use the term "personalization" as these conditions and changes can be specified as 117 or function of (groups of) users to whom they cater.

Customization is defined as a function which on the basis of objects 118 (contained and position) and / or meta-data associated with them or other environmental data, as well as function groups 'targeted users, returns the contents and position of the same or other objects. Customization can also take as input the result of another customization.

117 (by the owner of a resource or default to a preset specification or by other means)

118 Each object can be identified by such an identifier or by its position in the resource structure. An encryption mechanism that allows the conditions part customizations are met. For example, if a resource can be derived we will ensure that a certain object (such as advertising) it contains can not be changed. We will also ensure that these conditions will be inherited from a transclusion to another.

Figure 91 shows the architecture of a system putting this out. One distinguishes a named Personalization Server, itself composed of the following servers:

• A Collaborative Server that manages the particular transclusions and other processes described herein; • A Key Server which stores all the keys for the encrypted content and is responsible for communicating with the Authentication Server to authenticate the user;

• An authentication server (which may be for example a server such as Active Directory Microsoft). Figure 91 also shows the client part (plug-in) which comprises

• A Client Customization. It is a component which is in particular responsible for submitting "credentials" (login / password) to the key server, to obtain from the collaboration server customizations and applying them to objects specified by the manipulation tool Extension; encrypt (in a publication) the desired objects, and decrypt encrypted objects transparently.

• The Manipulation Tool Extension which notably responsible for providing a user interface for selecting a customization to apply; take the user's credentials and report to the Customizing client; get the content from content servers; where content is published, transmit content and credentials of the user Key Server.

Note that the client part (plug-in) is authenticated by the key server and the collaboration server as a condition for their operation.119

In Figure 91, the process steps correspond to the numbers indicated:

1. Manipulation Tool Extension gets the content of the current version from the corresponding Content Server

2. Manipulation Tool Extension request to Customer Customization customization to be applied to the resource, passing it the content of the resource (to be customized / decrypted) and user credentials

119 To do this, for each installation of the client part a pair of public-private key is used. The public key is stored in the Keys Server and the private key is in the Client Customization. To ensure the security of the private key in the latter, one can use a code generated from the specifications of the essential hardware components of the machine (hard disk, processor, MAC, if possible, etc.) processed by a function hash (such as Blowfish). Surplus, during startup, the Personalization Server can verify the checksum (or other fingerprint) of the executable code of the client part. First, the client part obtains the registration information (such as the owner of the software, etc.) and uses the generated code (from the specifications of the essential hardware components of the machine) to read its private key and encrypts registration information with the private key and sends the key server for authentication in a session. The key server decrypts the information using the public key that it has in its database and verifies the checksum and registration data for that customer. If successful a secure channel is established between the client side and the server using a protocol such as SSL. 3. In the event of items: Client Customization requires the keys to the Keys Server

4. Key Server checks the credentials of the user by contacting the Authentication Server 5. In the case of successful authentication server transmits the keys to the keys

Client Customization

6. In the case of successful authentication Customizing the Client asks the Collaborative Server customizations to be applied to the resource 7. Customize Client application required objects (determined in step

6) of the respective content servers

8. The Client Customization then apply customizations, decrypting the encrypted content. The result is transmitted to the Manipulation Tool Extension that shows the result.

In the case where the content server, the content of a resource such as a document is dynamically generated from application (s) to a database (or other type of data organization), the method will implemented so that the user can manipulate and collaborate on the resource presented to it and the resulting changes are reflected in the database (transparently).

The difficulty lies in identifying such objects available to the user. If there is a relational database, we will consider each line of the data base and each field (each table column in question) as shown in Figure 92. For each line, the identifier the "object" (as defined herein) in question can for example be the primary key. Likewise the object identifier for the fields will be the composition of the primary key and the name of the table in question column.20

An additional component (plugin) is necessary to the Content Server level to inject, using "invisible" tags in the presentation (as in HTML <A>), information identifying the object corresponding to the data in the database. Thus any request to the content server (intended ultimately to the database) is actually addressed to that component, and it handles the query so that the result back in addition contains the object identifier of each data returned by the database.

Thus one can identify objects. For example, when an object O 'of a database is reused in a plurality of resources (the content is dynamically generated therefrom), when one of these resources will be derived in Rl R2 and object O 'changes, the tool in question Handling Expansion will inform the collaboration server this derivation and modification of O'. When one of the resources of said plurality of resources will be re-viewed by means of a manipulation tool, the extension 121 to ask the collaboration server replacements or enhancements to perform. The latter will then return it the identifier of the change (if it is still the most elaborate) O 'in R2. The extension will then get this modified version of O 'from the Content Server hosting R2.

120 The identification of objects in a relational database is known per se.

121 (using the steps described above) Rem / investment in e richisserru proposals acceptance

The owner of a resource can accept or reject the replacement items and alternative objects in this resource. If an object (replacement or alternative) is denied, all other objects of the branch in which this object is also implicitly rejected.

We will now present a user interface by implementing the process. The information handling tool illustrated here (by way of example) is a web browser with an extension able to assemble replacement and alternative objects in Web pages. The same principles can be implemented on any other information manipulation tool and handle other types of resources.

Figure 93 shows schematically the web browser with a toolbar (which represents the extension in question). The user can enter a URL "www.site.org/page" and click "Submit" to display on screen the Web page corresponding to this URL, through an ERC "El" (that it can select from a drop down list).122

Figure 94 presents the web page in question displayed in the context of the ERC, with substitute or alternative objects (schematically represented by rectangles) and an "Edit" button in the toolbar. Figure 95 shows schematically the browser after the user has clicked the "Edit" button and he made changes. This button is now replaced by a "Save" button. When the user clicks on it, if he is the owner of the page in question, the system gives the choice to save the changes either in the same file or as a new derived page to a file to indicate different; if the user is not the owner of the page in question, it must necessarily save it as a new derived page.123

Figure 96 shows schematically the user has the option to accept or refuse the replacement and alternative objects. The user can accept / reject such an object by positioning it and • by selecting it and clicking on "Accept" or "Reject" in the toolbar

• or by clicking one of the symbols "->" "" or "^ N" presented (displayed only when the mouse pointer is positioned on the object in question). Note that the arrows (triangles) toward the left and right are used to respectively present the next and previous alternative object (starting with the original objects and the replacement objects). These are presented by resource resource (ie objects from the same resource are presented together). Note that when an alternative object is changed, it may be considered "frozen", the other options then are no longer accessible via these arrows (but an "undo" operation to return to the previous state) or • again by selecting "Accept" or "Reject" in the context menu that appears when press the right mouse button.

122 Alternatively, the "Send" button is not required if the shipment is done in a conventional manner using the Web browser and whether or not to view the page through an ERC can for example select "no collaborative resources" drop-down list.

When 123 saves as new derived page, it is of course the owner of the latter. Alternatively (and advantageously), 1 an alternative object can be determined automatically when the user saves a derived resource in which the object in question has been replaced by said alternative object; and replayed a replacement object can be determined automatically when the latter has been replaced by the original object (e.g., using the arrow pointing to the left mentioned in the previous paragraph).

The user interface also allows to highlight objects (reifications) and grains, or to create them.

ERC use patterns The ERC use patterns affect their activation or not (to propagate updates to downstream through the transclusions and other contributions).

The user interface allows users to select first default ERC, then for each access to a resource to clarify the respective modes of ERC (however these modes persist default access to another). It provides the user with a screen comprising two parts as follows: Part I: 0D (check box can take one of two values: checked or not) -

Checked meaning "By default, the updates are fully propagated (from the upstream and downstream)" No ticked meaning "By default, the updates are received from upstream but not propagated to downstream "(mute)

Second part :

Each ERC mentioned by the user:

EZI IEI (check box can take one of two values: tick or cross) - Notch: full cooperation in this ERC

Cross: no communication in this ERC

We will now introduce the use of these modes using scenarios.

The Figure 97 shows a R.1 resource R2 in the ERC El and transclut (by transclusion T2) item 'c' of the Sl resource in CRFs E2 and E3. In Figure 98 the resource R2 is opened by the user in a "secret" mode for ERC E3, then T2: d is changed.

In Figure 99 the resource R2 is open in the ERC E2 and T2: d refused.

Thus the use of modes is useful to cooperate selectively 124. later a variant will be seen (in the section presenting the multi-versions objects).

Resources and Recommendation ERC was so far that the user can access a resource "through" the ERC. A question that may arise is whether, among the ERC that it has the right to use, choose from.

Another issue can be the user to know what the latest resources and / or relevant to him that others have seen in the ERC that it is currently using.

The two questions above can be combined: the user can ask the Collaborative Server to provide both relevant resources (and / or recent) and ERC among those he has the right to use that are relevant to visit said relevant resources. Finally, users may also want to uncover them (eg to meet or exchange information) from the resources / ERC they will visit or handle respectively (see also about the rating of approach users described in "a method of sorting objects by alternative scoring (rating)").

Insofar as the Collaborative Server know what user accesses has any resource in which set of collaborative resource (these triplets being stored), it can simply apply collaborative filtering methods to get the answers to the four types of questions above, including by performing counts to determine the proximity of users in terms of numbers of couples' resources / ERC they have visited / used jointly and exchange between users close their (good) experiences. The proximity of these users (in terms of number of couples' resources / ERC they have visited / used in common) can of course also be used in addition to the aforementioned rating approach, to sort objects based on alternative the proximity of the authors in relation to the user.

We will see later a variant based on the implementation of pipes spread of relevance scores.

Advantages

We can now offer benefits resulting from the processes described herein. We will also describe some new related processes.

124 The use of ERC in different modes is useful when contributions modification results of persistent requests to a database (as already described, a persistent query can be seen as a transclusion). When the user adds an item in the results of a query, the selection criteria contained in the persistent query in question are used to back-propagate in the database properties associated with the data. This is done exclusively in ERC concerned. Benefits tion processes

The ERC is an effective means of collaboration to write / compose a work with several contributors. Simply that all contributors share the same ERC 125 for each contributor can further develop the resources produced by others.

To publish, resource owners to be published or select accept (among alternative objects) contributions they wish to publish (and ignore or refuse the others). So the other contributions are not seen by users other than those who are members of that same ERC. Not only new pages can be published as well, but even pages created outside of the ERC can be derived and republished, subject to legal considerations described below.

Writing a collective future publication

An interesting application is the preparation of a future publication. The principle is illustrated in Figure 100. The rectangles (R, RI l, etc.) represent resources; the arrows represent the derivations; the shaped regions of "L" upside down, framed by Dashed lines represent CRF (El, E2 and E3).

This is the structure of the organization preparing the publication of a monthly magazine 126, the presentation template is the "Template" resource. For example, this review must be first published in April (R resource) and in May (resource R2) and then again in June (resource R3), etc.

The employees of the April issue are members of the ERC El; those of the release of May are members of E2; and those of June E3.

These sets of employees (respectively members of El, E2 and E3) may be distinct or not, and these sets of employees working in parallel to prepare the publications say 6 months in advance.

The publication of April (R) is derived from the resource "Template", in order to reuse this model. The employees responsible for producing the content of R2 (May) replicate the look of the publication of April. Those responsible for producing the release of R3 (June) replicate the contents of R2.

The advantage of this approach is twofold:

• (by the properties of the transclusion) any update made upstream affects downstream; For example, if the template model is improved, all publications benefit since they are in the downstream, and vice versa • any proposals submitted (downstream) by employees of a publication does will be seen collaborators of the subsequent publication (which form a further part downstream) if it is saved. Indeed, the employees of an R publication do not see the contributions of employees of IR release before they are accepted as they are not even members of the ERC.

Of course all kinds of other branches of the organizations can be considered to offer various benefits depending on the desired applications.

125 (are users)

126 (that is to say the structure of the "workflow" publication) Benefits to disseminate c ublicitaires

We will now describe how an editor or other organization, call "The newspaper" can advertise on the Internet using the methods described herein.

The paper creates a new ERC (The log can also use a pre-existing ERC). In its website, a clickable link allows to download an extension (plugin) to current information handling tools such as the popular browsers Internet Explorer or Firefox. Once the download and following the automatic extension of said installation, said ERC is activated automatically in the user information handling tool. If the extension is installed, the ERC is directly activated without need to download or install. All this is done by a simple click of the user.

A content (object) advertising is included in each resource (Web page) and a strain of non-changeability associated with it (see below sections "Web read-write" and "constraints to objects"). So each time a page of the site is derived by a user and that this page is republished in turn, visitors to this page derived see promotional said that, due to the constraint of non-modifiability, can not be removed or modified by using the information manipulation of tools with the extension (plug-in) in question.

In common cases where the advertisements are placed in <IFRAME> conventional counting methods may continue to operate. In any case, counters such as those mentioned in the "Global Implementation" section can be implemented to count the number of times that a new page is derived by including the advertising object, the number of times it is transcluded by other means, or the number of times the advertising object is simply seen in a page. This allows the newspaper to monetize these publications by charging advertisers based on these counters. Moreover, the supplier of the service rendered by the collaboration server (to manage the ERC which include advertising items in question) is paid by the newspaper or its advertiser or agency customer inserting advertisements, according to results given by these counters.

In addition, 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 obviously can be a function of the payment already made or planned to make the supplier of the service rendered by the collaboration server).

Benefits for "wikis" The "wikis" (cf. www.wikipedia.com) are sites in which visitors can change the desire to pages. Wikis are particularly suited for exchanging ideas and articulate and develop together. They are typically used to cooperate on joint projects, encourage contributions and accelerate the flow of information.

However, wikis, the parties' sensitive '(debatable) of content are usually changed and re-changed alternately by the "each side of users' until eventually a consensus (on what must have these information) emerges ... It is so hard to put information "not neutral" in wikis. Although wikis have the advantage of encouraging them to respect the opinions of others, the quest for neutrality inherent wikis seems too restrictive and sometimes tends to impoverish the information.

127 (and / or resources containing bypass) is proposed here a kind of new tyi unlike the current generation of wikis, not only allow but even encourages the contribution of non-neutral information (insert content from views divergent, different opinions, etc). The different mechanisms (derivation trees, transclusion, etc.) described so far can be presented updates as substitute objects (OR) and non-neutral information as alternative objects (OA).28

Web read-write

The changes made by each user on any web page are visible to every other user who visits as part of the same ERC. However, to meet the "copyright", it would be normal that only the changes authorized by the owners of the web pages may be republished through collaboration servers. However, as mentioned above, it is expected that web page owners have an interest in (and thus please) allow changes to their pages since they thus increase their audience and they may restrict pages so that some parts (eg advertisements they contain) can not be changed. To the extent that they do, the current Web that is read only will turn into a read-write Web.

Another key difference with existing wikis is here the same ERC resources are not necessarily in the same site. Also today wikis contain only Web pages, but here it is the collaboration of all kinds of resources available on a network.

In summary, the Web today is read only can become read-write. Also can be added to this new Web resources other than Web pages that are in the ERC.

backlinks

A link added by a user of an ERC, in a resource derived from a resource (such as a Web page) to start, can bring a user (or another) of the ERC to visit resource pointed to by the link added. Is placed in addition implement a method of automatically add, on a resource derived from said pointed item, a link ( "reverse link") which may lead to said resource from a user of the same ERC visiting said pointed resource.

All backlinks can for example be automatically presented to the user in a (sub) window, adjacent to the (sub) window showing the contents of the visited resource.

distribution constraint metadata

The fact that technically any available resource, such as any web page, may be republished incentive to implement aids to put in order, at least legally. The essential idea is that the information manipulation tool automates and facilitates the transmission of a request to request permission to (re) publish content and manages the publication process pending the response to such request.

128 (while avoiding redundancies in the information storage) Thus, the activation means of AUTOMATIC authorization can be triggered as soon as a resource is a 129 to be published, and publication will automatically start at the later when the permission arrives.

Pending permission to publish, a mechanism to publish only quotes (small excerpts) taken in reasonable limits (legally) permissible may be implemented.

For such a permit application process can be implemented, it is necessary that the owner of the original content, or decision-making authority (which can decide in its place), can be contacted. Is proposed and the resources include associate or contact data of a meta-decision making authority.

Other metadata can be associated with an object to selectively control the modification and / or its accessibility by third parties within the resources derived. In particular, meta-data distribution constraints can specify that (as already mentioned) given objects can be reproduced (with authorized or unauthorized modification) provided that the specified sub-parts are included without modification.

The resource containing -or that are associées- metadata can be structured as a tree of objects, so that in combination with at least some nodes of the tree, a meta-data distribution constraint is stored, and a metadata broadcast stress at a node applies to the child nodes of the node.

Advantage to circumvent censorship

When accessing a resource, if the user has not explicitly specified at least one ERC (and / or collaboration server) for this access, information manipulation tool sends a request to (x) server (s) collaborative) set (s) by default, to obtain the identifiers of the objects of replacement and alternative objects.

To respond to such a request, each collaboration server is able to search for other collaboration servers that can provide the required credentials, and return these identifiers 130 to the information manipulation tool.

The information handling tool is thus able to obtain the required password from any collaboration server, the latter serving as an intermediary if it can fulfill the requests itself. It is therefore not useful to block, especially for purposes of censorship, access to some 131 collaboration servers since others may relay.

Figure 101 illustrates this process: instead of receiving the identifiers of the objects of replacement and alternative objects from a collaboration server ESI, because the connection is cut with ESI (which is represented by the large X in Figure 101 ), the information handling tool obtained from a collaborative ES2 server to which the connection is possible. Indeed, when it receives the request of handling information tool ES2 asks collaboration servers it knows, they in turn relay the request to the servers they know themselves, and so on, in a conventional method in peer-to-peer known in itself and which is therefore not described further here. ES2 ends

129 See also "Conditions associated with transclusion" section.

The collaborative server 130 is ready to return the identifiers of objects replacement and alternative objects, as well as their respective ERC identifiers, so that the replacement object identifiers and alternative objects can be used selectively, that is to say only if the ERC which provide suitable for the user or he is a member)

131 (the IP addresses) and reach by ESI that provides iι replacement items and alternative objects for the accessed resource in question.

Moreover, it is not helpful either to block access to content sites (PCS or MCS) to the extent that not only the information they provide are reproduced in "caches" pages derived from of them, but also collaboration servers are adapted to provide page derived the nearest accessible (as defined in proximity of branching) of a requested page.

Extensions to existing syndication protocols Interoperability will now present two protocols (PSE and ASE) which are extensions to existing protocols "sharing" (or Syndication), such as RSS. These protocols have in principle the following characteristics:

• The contents are released in the form of channels ( "channel" or "feed" in the Anglo-Saxon terminology) • A channel comprises a plurality of "items" (pieces of information)

• Each item has a unique identifier

• Servers can subscribe to channels published by other servers

• Servers ( "re-publieurs") can aggregate multiple channels and republish

Some of these protocols (such as "RSS + SSE" specified by Microsoft) also allow:

• re-publieurs can change some items (that is to say, these servers allow users to modify the items they are not the original author)

• results of these changes are propagated to the (servers) subscribers and synchronize them in a decentralized manner. The PSE and ASE protocols that we will introduce and seek a network of servers that share content s' subscribing to channels published by other servers. In a heterogeneous environment, servers using different protocols. For example some use RSS 1, RSS 2.0 other with SSE extension (RSS + SES), others can still use other extensions, etc. The protocols described here are actually extensions to all existing and future protocols that have the characteristics set out above; they were designed to function as additional layers to them.

It expresses the existing sharing protocols using an abstract syntax 132 as follows:

• The <channel> for channels that publish server; "The <item> (in the <channel>) for each item in the published channel - it has the 'id' attribute giving it an identifier;

• The <content> (in the <item>) for the content - for example this tag match both <title> that <description> RSS 2.0;133

Each existing protocol that has an equivalent representation (that is to say, of tags and attributes similar) can interoperate with PSE and ASE 134. Any other tag as

132 tags and attributes (XML) 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 to be used and not those.

133 As this is an abstract syntax, in reality we will not have that tag <content> but <title> and / or <decription>, etc. or like beacons, according to the original protocol in question.

134 In the sequel to "PES" means "PSE and ASE" unless clear contrary. equivalent to those above are but nor are ignored (that is to say, are not interpreted) by the PES protocol.

The EMP implementation will typically include the implementation of the common existing protocols such as RSS 2.0, RSS 2.0 with SSE, etc. RSS 1.0 so that their tags (and attributes) respectively are interpreted in their respective home protocols. When the PSE implementation does not recognize a tag but she ignores the holding in order to avoid losing information channel for other servers that participate in the network.

The PES protocol first implements the specifications (or) protocol (s) of the source (or protocol selected by the default user if the server is the source itself) and then adds the PSE elements (such as brothers or children's items

"Item") and performs the associated treatments. PES elements are declared in a namespace ( "namespace" in English terminology) distinct, and it provides that they will simply be ignored by other servers that do not recognize (that is to say, which does not address the elements belonging to said namespace). In general, a copy of the source elements is preserved so that subscribers do not include servers that PES can still interpret the protocol of the source and interoperate well with PES. As already mentioned, the PES protocol performs specific treatments (x) protocol (s) source (s) 135 so that the server appears (to subscribers servers that include the source protocol) as a server source protocol .

Figure 102 presents different servers publishing content to different protocols. The server that implements PSE can interoperate with the various protocols and add the PES extension to the respective channels. For example it takes 'Channel' s of "Server 1" using RSS 2.0 with SSE extension adds the PES layer in 'Channel 1' and republish. It also publishes 'Channel 3' OPML 1.0 + SSE format (the format can be chosen by the user creating the channel) which subscribes "Server 4" which recognizes this protocol.

This figure also illustrates that in the ESP protocol, source protocol is selected so that those who are the source protocol can subscribe to republished channel. For example 'Channel' s is republished by "Server 3" using the same protocol as the source, namely RSS 2.0 with SSE, so that "Server 5" which includes the RSS 2.0 with SSE can subscribe to 'Channel' s. As for "Server 7" uses the ESA protocol and can subscribe to all channels published by "Server 3" but ignoring the elements in PES.

Of course, the aggregation of different channels is only possible for compatible protocols. For example RSS 1.0 (or 0.92) can be aggregated with RSS 2.0 RSS 2.0 to give a valid channel but this is unfortunately not possible in the other direction. A server implementing PES allows the aggregation of such compatible protocols. This is illustrated in Figure 102 where "Server 3" aggregates 'Channel' s and Channel 2 as a channel

RSS 2.0 + SSE. Other servers such as "Server 5" can then subscribe to see so many items 'Channel' s as Channel 2.

PES

Extending the PSE sharing protocols allows the transclure a source user an item or part (of the content) of an item. User can mark a portion 136 of an item as an object; it can then be transcluded in another channel or in the same channel. The characteristics described up to the transclusion remain valid. Thus,

135 protocol Here source means of the protocol of the source of the item republished or the protocol chosen by the user to the original items.

136 (which has the effect of making it to acquire an identifier; it is the objectification process described before) of items changes in the result clusion are stored during synchronization with the source; and closest sources are a priority for updates.

XML specification We just need a single tag that is defined in the namespace "weighs". It is as follows:

Element <pse: part> in <item> or <channel>

This element may be in the <item> or the <channei> flush <item>. When part of an item is reified 137, this element <pse: part> appears in the <item> to encapsulate the created object. When <item> is transcluded in another channel at the same level as a <item> then it is inserted into the <channei>. Note that the position of this element into account.

attributes:

• Tid: This is a required attribute that gives the identifier of the object at the PES protocol.

• src-tid: This is an optional attribute that gives Tid source modified nearest. During synchronization, the update mechanism of this attribute is: the src-tid is compared with (if any) the src-tid attribute of the source element to take its value if it is closer. If there is no src-tid attribute, it means that the source does not depend on itself another source.

• changetype: This is an optional attribute that is added when the object is modified locally. It can take its value from the following: CREATED, MODIFIED,

DELETED.

scenarios PES

The following scenarios cover different use cases of PES.

Item transcluded in a channel

Figure 103 has two streams (channels) RSS, Server 1 and Server 2, and the fact that Server 1 transcluded item is to be placed between two existing items of Server 2.

abstract XML representation

As already specified, the new <pse: part> tid has the attributes src-tid and changetype. The tid is the ID of the object in question, in this scenario, is the result of the transclusion. The 'src-tid is the identity of the source modified nearest. Only one of the src-tid changetype attributes and will be present for when the object is modified locally there is no source.

Server 1 (source):

<Item id = ll> <content>

</ Content> </ item> <item id = 12>

137 (to be considered an object) <content>

</ Content> </ item> <item id = 13>

<Content>

</ Content> </ item> <item id = 14>

<Content>

</ Content> </ item>

Note that there may be other elements (such as <sχ: sync>) in <item> (not mentioned for purposes of brevity), which are ignored in the PES protocol itself but retained for the use of original protocol.38

As a result of the transclusion, Server 2 includes the item '13' transcluded and an element <PSE: hand : I3 "src-tid =" i3 "/> (initially without content).

Server 2:

<Item id = 21>

<Content>

</ Content> </ item>

<PSE: hand tid = "T i: 13" src-tid = "13" /> <item id = 13> <content>

</ Content> </ item> <item id = 22> <content>

</ Content> </ item>

'13' is changed in Server 1 2 When Server synchronizes with Server 1, only the item '13' in Server 2 is updated with the new content from the source 139 and, as the content of the element ' T 1: 13 'has not been changed by the user (locally), the PSE element: hand implicitly reflects the content of the item' 13 '.

Ti: 13 'is modified in Server 2 When T 1: 13' in Server 2 is (locally) changed 140, its contents are explicitly added in <pse: part>, and the change is made in the item '13 'located in Server 2

The PSE Server 138 includes not only Pimplémentation PSE but the implementations of other protocols that includes (as for example RSS 2.0 and SSE). Thus, although these elements are ignored by the PES protocol, they are considered by Pimplémentation their respective original protocol in the PSE Server itself.

139 (using the original protocol)

140 Advantageously, the implementation of the method 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. Retaining the item '13' or not will then be linked. Here "context-dependent" essentially means that the change cites at least part of another item of the same channel. for using another protocol. Any m <have higher will be made in T 1: 13 'and' 13 '. Attribute 'changetype = "modified" is added and the attribute' src-tid 'is deleted:

Server 2: <item id = 21>

<Content>

</ Content> </ item> <item id = 13>

<Content>

... <- modified content </ content> </ item> <PSE: hand type = "modified">

... modified </ pse: part> <item id = 22>

<Content>

</ Content> </ item>

The item '13' will continue to sync with its source (by the original protocol), while the element T 1: 13 'will not receive updates from the source as it is locally modified.

Item transcluded in another item

Figure 104 shows a transclusion whose result is placed in the contents of another item.

abstract XML representation

The PSE element: hand is now placed in the item of content '22' (to represent the result of the transclusion in the exact spot where this result is placed). As in the previous example, a copy of the contents of the source item '13' is additionally added in Server 2. Server 1:

<Item id = ll>

<Content>

</ Content> </ item>

<Item id = 12>

<Content>

</ Content> </ item>

<Item id = 13>

<Content>

</ Content> </ item>

<Item id = 14>

<Content> </ content> </ item>

Server 2:

<Item id = 21> <content>

</ Content> </ item> <item id = 22> <content>

<PSE: hand src-tid = "13" />

</ Content> </ item>

<Item id = 13>

<Content>

</ Content> </ item>

<Item id = 23>

<Content>

</ Content> </ item>

'13' is changed in Server 1

Similar to the previous example, when Server 2 Server 1 synchronizes with the item '13' in Server 2 is updated with new content from its source and weighs element: hand (Ti: 13 ') refers to it. Ti: 13 'is changed in Server 2

When Ti: 13 'in Server 2 is changed locally, the modified content is put in the element pse: part and the change is made in the item element (for the use of other protocols). Any subsequent changes will be made in local 'Ti: 13' and '13'. An attribute changetype = "modified" is added and the attribute "src-tid 'is deleted from the PSE element: Proportion:

Server 2:

<Item id = 21>

<Content>

</ Content> </ item> <item id = 22>

<Content>

<PSE: hand : 13 "changetype =" modified "> <- modified content...

</ PSE: part> </ content>

</ Item> <item id = 13>

<Content>

... <- modified content </ content>

</ Item> <item id = 23> <content>

</ Content> </ item> Item Part transcluse within another item

Figure 105 shows the case of the transclusion only a portion of an item of content, this part ( '113') is now the source object to transclure within another item of content ( '22') .

abstract XML representation The only difference from the previous example is that the party in question in the source must be reified. This is done using the same PSE tag: unit used here to define the reified part and the attribute tid provides the ID of the object that results from this reification.

Server 1: <item id = ll>

<Content>

</ Content> </ item> <item id = 12>

<Content>

</ Content> </ item> <item id = 13>

<Content>

<PSE: hand tid = "113"> </ PSE: part>

</ Content> </ item> <item id = 14> <content>

</ Content> </ item>

Here the element pse: hand has no attribute 'src-tid' as its content does not depend on another source.

Obviously, what has been described so far is also valid for transclusion into one channel or between channels of the same server.

internal and implicit Transclusions

Figure 106 shows the case of an internal transclusion in Server 1 resulting in an implicit transclusion 141 in Server 2.

Server 1:

<Item id = ll>

<Content>

141 (for a description of these terms see especially the "implicit transclusion internal transclusion" earlier) </ content> </ item> <item id = 13>

<Content>

<PSE: hand tid = "112">

</ PSE: part>

<PSE: hand src-tid = "112"> </ PSE: part> </ content>

</ Item> <item id = 14>

<Content> </ content>

</ Item>

Server 2:

<Item id = 21>

<Content>

</ Content> </ item> <item id = 13>

<Content>

<PSE: hand tid = "T 2: 112" src-tid = "112"> </ pse: part> <PSE: hand src-tid = "112">

</ PSE: part>

</ Content> </ item>

<PSE: hand tid = "T 2: 13" src-tid = "13" /> <item id = 23>

<Content> </ content>

</ Item>

'112' is changed in Server 1

When Server 1 synchronizes with itself (which should normally be triggered directly), T 1 12 It is updated with the contents of 112, the modified source nearest (given by the attribute 'src- tid = "H2" '). Also, when two Server synchronizes with server 1, the content of T ^ A 12 'and' T2: T1: 112 'in Server 2 are updated with the new content item's' 112' Server 1, their modified source nearest being also given by the attribute 'src-tid = "H2"' 142.

142 The mechanisms for determining the closest sources have already been described further, especially in the "Algorithms in Push" section.6 T 1 Ilil 9 is changed in Server J

When T 1 The 12 'in Server 1 is amended, an attribute changetype = "modified" is added to the PSE element: either the attribute' src-tid 'is deleted in this element. When Server 2 Server 1 synchronizes with the content of T 2 T 1 The 12 'in Server 2, as long as it has not been modified locally, is updated with the new content of the item' ^ 1: 112 'Server 1, its source altered the closest being now' T 1 This 12 '.

4 T 2: 112 'is changed in Server 2

As in the previous examples, when T 2 He 12 'in Server 2 is changed, the changed contents are placed in both the PSE element: from T 2: 13' in the item '13' element. An attribute changetype = "modified" is added to the PSE element: from T 2 He 12 'and the attribute' src-tid 'is deleted.

When Server 2 is synchronized with itself 143, the content of T 2 IT 1 II n 'is updated with the source T 2: 112' because its distance is now shorter than T 1 It 12 .

ESA will now be presenting an extension ( "ESA") to sharing protocols that allows the user to see competing contributions (alternatives) from multiple RSS feeds he subscribes or from RSS feeds that are in the "chain" of subscriptions in which it is located. It will thus apply to existing sharing protocols, the idea of encouraging the different views (and not systematically replace each contribution when a newer 144 appears).

The objectives (additional to those of PES 145) are:

• To access the contributions (alternative objects) corresponding to points of view (branches) different, via the channels to which you subscribe (and which are thus upstream); • optionally present even the contributions that come from the downstream

(unlike existing protocols), and this even if there is no reciprocal subscriptions or 146 cycles in the subscription channels. For this, we will use a notification mechanism (whereby the changes made to the items that are communicated to the downstream to upstream). Of course, these notifications are not required in the case of mutual subscriptions.

Notifications are only made to the immediate sources, which themselves propagate their own sources and so on. It has not need to send notifications to all possible sources 147.

XML specification in the namespace "ase" XML tags 148 include the following:

143 (which should normally be triggered by the change)

144 RSS + SSE protocol still takes other factors into consideration, but always in the logic of systematic replacement.

145 (including the objective to keep the local changes (here referred to as "Original"), which is actually an own goal PSE)

146 There is reciprocal subscriptions when the source subscribes to the stream that subscribed to it.

147 (see also below the contribution of Collaborative Servers)

148 is not recalled here mechanisms replacement and objects enrichment. See especially sections method for creating the most elaborate objects and method of determining the replacement object and alternative objects and the following. Element <ase: Contributions> iel>

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.

Attributes: • ID: the identifier of the item whose contributions are included;

• Branch: the identifier of the active branch of the item;

• SEQID: sequence number of an item in a subscription channel.

Element <ase: contribution> in <ase: Contributions>

Attributes: • Kind: This attribute takes one of the following values: "Original", "Replacement"

(Replacement, that is to say the most elaborate object of its branch) or "Alternative" (from another branch);

• Branch: Name of the branch of the contribution in question;

• SEQ: the contribution in question sequence number; Element <ase: changes> in <ase: Contributions>

This element contains a list of the most recent changes to the item. It determines the most elaborate object in a branch when the most elaborate current object moves in a different branch.

Element <ase: changes> in <ase: changes s> element contains the information of the change of the item in question.

attributes:

• Branch: the ID of the branch of the modified item;

• SEQ: the sequence number of branch of the item changed.

Element <ase: movebranch> in <ase: Contributions> This tag is used to propagate the information of acceptance / replayed a contribution by a source.

attributes:

• Branch: the identifier of the new branch of the source.

Example The behavior of ASE protocol is illustrated in Figure 107, wherein:

• "(R)" means Substitution, "(A)" means Alternative and "(O)" means the original content;

• A hatched box represents a locally modified object; an indoor space of points shows a modified object following a change in the upstream direction; a white box (not covered pattern) represents an unmodified object;

• A solid arrow represents communication of an object by the upstream; a non-solid arrow (dashed) is the notification of a change in the upstream direction.

This figure illustrates the fomation of the legs 149 of an object "a" (the arms are shown vertical) by presenting the steps of:

149 branches are suites derivations items that constitute one alternative version, as described in detail later in this document. • Server 2 subscribes to Server 1 and Server 2 to If e

• Server 2 amends "a" a2

• Server 3 amends "a" a3

• Server 1 modifies "a" has the thus refusing a3 • Server 2 accepts the alternative a3

• Server 3 accepts the alternative al '

• Server 3 amends "a" s "

• Server 1 refuses al ".

These examples are consistent with the methods already described before in this document, except that, in order to promote compatibility with existing protocols, the first branch presented to the user is the one that contains objects such as would presented the existing protocols.

Contributions Transclusions and upstream (PES with ESA)

Typically in existing protocols, an item, even if it has been changed locally when it synchronizes with a source that has itself been updated, starts to date compared to that source. Thus, as already described in the PES protocol only weighs the item: hand keeps the local change (it is necessary to keep within the transclusion process) and not the item element (because we does not lose its compliance with existing protocols). Now in the ESA protocol, the original content is also stored in a <ase: contribution κind having attribute = "originai". This therefore represents a redundancy. But if we assume that the servers which include the PES also include the ESA protocol, we can avoid this redundancy by keeping the modified content in the tag of the ESA protocol. Note that in this approach, a server that includes only the ASE protocol (not the PES) PES server sees everything as if it were purely an ASE server.

We will now illustrate the joint operation of these protocols on the basis of the example of Figure 108 in which an item '13' of a Server 1 transcluded flow is within an item '22' which is in a flow Server 2 this item '22' being itself transcluded in server 3. the arrows in non-solid lines (traitilllés) represent the method of communication according to the upstream ASE protocol.

Example

abstract XML representation

Server 1: <item id = ll>

<Content>

</ Content> </ item> <item id = 12>

<Content>

</ Content> </ item> <item id = 13>

<Content>

</ Content> </ item> <item id = 14>

<Content>

</ Content> </ item> Server 2:

<Item id = 21>

<Content> </ content>

</ Item> <item id = 22>

<Content> <PSE: hand : 13 "src-tid =" 13 ">

</ PSE: part>

</ Content> </ item>

<Item id = 13>

<Content>

</ Content> </ item>

<Item id = 23>

<Content>

</ Content> </ item>

Server 3:

<Item id = 31>

<Content> </ content>

</ Item>

<PSE: hand tid = "T2: 22" src-tid = "22" /> <item id = 22>

<Content>

<PSE: hand tid = "T2: T1: 13" src-tid = "13">

</ PSE: part> </ content>

</ Item>

'Tl: 13' is modified

This change is notified to upstream to Server 1 so that it includes the contribution in question is in this case a replacement:

Server 1:

<Item id = ll>

<Content> </ content>

</ Item> <item id = 12>

<Content> </ content>

</ Item> <item id = 13>

<Content>

</ Content> </ item> <ase: id = 13 contributions branch = 0 SEQID = O>

<Ase: Contribution kind = "Replacement" branch = 0 = the SEQ>

<Ase: source url = "Server 2" id = Ti: 13 /> </ ns: contribution> </ ns: Contributions>

<Item id = 14>

<Content>

</ Content> </ item>

T2: T1: 13 'is modified

This change is in Server 3 is notified to the first upstream to Server 2, then from Server 2 to Server 1, so that each includes the contribution in question: Server 1:

<Item id = ll>

<Content>

</ Content> </ item>

<Item id = 12>

<Content>

</ Content> </ item>

<Item id = 13>

<Content>

</ Content> </ item>

<Ase: id = 13 contributions branch = 0 SEQID = O>

<Ase: Contribution kind = "Replacement" branch = 0 SEQ = 2>

<ase: source url = "Server 3" id = T 2: Tχ: 13 /> </ ns: contribution> </ ns: Contributions>

<Item id = 14>

<Content>

</ Content> </ item> Server 2:

<Item id = 21>

<Content> </ content>

</ Item> <item id = 22>

<Content> <PSE: hand changetype = "modified">

</ PSE: part>

</ Content> </ item> <item id = 13>

<Content>

</ Content> </ item> <ase: id = contributions "Ti: 13" branch = 0 = the SEQ>

<Ase: Contribution kind = "Replacement" branch = 0 SEQ = 2>

<ase: source url = "Server 3" id = T 2: Tχ: 13 /> </ ns: contribution> </ ns: Contributions>

<Item id = 23>

<Content>

</ Content> </ item> Server 3:

<Item id = 31>

<Content> </ content>

</ Item>

<PSE: hand tid = "T 2: 22" src-tid = "22" /> <item id = 22>

<Content>

<PSE: hand tid = "T2 IT 1: 13" changetype = "modified"> </ PSE: part> </ content>

</ Item>

It is so spread the nearest branch manipulations close when you sync the flow based on the following principles: • A contribution will attribute kind "Replacement" if it is in the active branch, or " alternative "otherwise.

• The object having the attribute kind "Replacement" is implicitly denied when another branch is changed by the user. He and all objects derived from them will then be moved to another branch. • In the case where for an object an alternative (which is therefore in a branch other than the active branch) is accepted, said object and the objects made thereof and that were in the branch that has been activated, are moved in the branch of the accepted alternative, except the object from which the accepted branch was created and objects that derive from it. Collaborative server PSE / ASE

Advantageously, the different Collaborative Server variants described before in this document can improve the performance of PES servers (and ESA). The idea is to avoid the propagation of changes from place to place (when you sync the completely decentralized servers) and use at least part of the collaboration servers as central intermediates which can exploit the efficient algorithms described before synchronization. In particular, the points to consider are:

1. If a server aggregates items from several sources located in different servers, then it must synchronize with each of them; 2. If more channels are subscribed <; source, so everyone should get the content from that source;

3. If a subscription channel one of the servers goes, the following servers no longer receive updates or this server or those who are there at the upstream; 4. Finally, in search of the nearest source when there are several, must avoid interviewing all sources.

Respectively, the answers provided by the approach of intermediation via one (or more) Server (s) Contributing) are:

1. Collaborative Server can subscribe to different sources and notify the server in question. If more said sources also use the Collaborative Server, then they will notify it directly of their possible updates which will prevent polling from the Collaborative Server.

2. Collaborative Server undertake to obtain the contents of the source in question (again by polling or receiving notifications) and notification of updates; 3. Subscribers no longer depend on the strength of "all links in the chain." Indeed, in the worst case only the falling stop providing server (except of course if a server falls Collaborative itself but one can imagine that it has the necessary means to ensure its reliability);

4. Collaborative server keeps track of all changes and spreads following the tranclusions the changes from the nearest sources

(See "Algorithm push").

In summary, the Collaborative Servers placed in a syndication network primary effect of saving the bandwidth and reliability of the network when nodes of this network are "weak links". In the figures 109 and 110, we take the approach (adopted throughout this description) that the Collaborative Servers do not have the content but only their identifiers.

Figure 109 shows the step of taking into account a change in a source. Its sub-steps are:

1. Information of change (without the content) is communicated to the Collaboration Server

2. Subscribers communicate the content to the Content Servers Figure 110 shows the step of updating subscribers. This step includes the sub-steps are as follows:

1. CSl Content Server periodically polls the source

2. CSl inform the changes Collaboration Server (if any)

3. The up-to-date / replacements / alternatives are transmitted to subscribers (for notifications) 4. subscribers get the content of up-to-date / replacements from

Content servers; in principle alternatives are available on request 150.

150 In the ESA protocol, the server contains the URL of the feed to which it has subscribed with the identifier of the object in question, so as to recover the alternatives on user request. Transcluding with transformer

Transcluding far described can be represented by a flow of information as follows. First of all the information from the source of the transclusion. Then this information is altered or reorganized as described by the differences of the transclusion. Finally the structure obtained is returned to the user.

The extension described in this section proposes to add a 151 processing this information flow. This is a function (e.g., a filter on the objects) attached to the transclusion. This transformation is performed on the objects from the source before applying the differences of the transclusion. Figure 111 illustrates this transfer of information.

The objects of the source are in the first step and before being subjected to an application differences, immediately subjected to a transformation in Figure 111 by processing an object has been deleted and another had its contents changed. The second box shows the source as seen by the differences applying algorithm (in "pull" or "push" as described above). These are pre-treated objects that are displaced in the second step, removed or changed as indicated by the differences in the example shown in Figure 111, consist of a deletion, creation and a displacement.

Implementation

Whatever the implementation chosen for the system ( "push" or "pull"), the principle of the method to be applied here is the same. A transformation is applied every time the system needs the contents of an object through a transclusion. For example, for the "push" method, when an attribute (such as content) of a modified object is sent to the result of the transclusion, it is immediately subjected to transformations before being integrated to the result (it can however be advantageous to first check if it will actually be used to prevent the implementation of the transformation to an object that is not visible in the result). Similarly, for the "pull" method, when an object is downloaded to be integrated to the result, it will be submitted for processing.

In other words, transcluding algorithm must operate as if the source of the object was the result of the transformation. For example if a transformation removes an object then the transclusion must operate as if this object does not exist at the source. Another example, if the transformation performs a sort on the objects from the source then the transclusion works as if the objects were already separated at source.

The transformation is the same for children and parents, for the same transclusion. However, we can provide two processing functions instead of one and alternately applying: one at the time of the creation of a transclusion, one in each update (it could as the case may require to know the previous state of the source object).

Finally, the nature of the processing carried out by a transclusion can be stored in the same way as the other information (attributes) of the objects ( "inner-text", position, etc.) in association with the results of transclusions 152. This allows to consider it similarly to other vis-a-vis attributes of Rule 8 "to determine the closest source when Uy several candidate sources and of Rule 9 which is described below.

151 When no processing is associated with the transclusion, we say that it is the transformation identity associated with it.

152 The transformation of a transclusion is treated as an attribute of the root object of the result (ie the single object part of the result of the transclusion, and containing all other objects as part of the result of the transclusion). Information flows in the case of transcli

He comes to know which path takes the flow of information, that is to say in which order the transformations are applied. As shown in Figure 112, we would like the innermost transclusions (internal) are followed first (outermost and last).

In this figure at the top left is an object containing an internal transclusion (r), then a transclusion (u) of the object is performed, placing the result on the right. Then the whole is transcluded (s) again, putting the result down. The arrows indicate the directions of flow of information, with a letter representing the processing carried out. The intuition is that the "u" of the transclusion done from left to right, is applied to all objects in the source of the transclusion, even if these are the results of internal transclusions. In the source of the transclusion "u", "r" transformation is performed before processing "u" that it is more external (and this transformation "r" is not performed on the object that is at the top to the right). Also seen in this figure that no implicit transclusion located in the lower half of the figure (in the income s) is followed. So we will have to devise rules that, in the upper half of the figure, to connect the upper left object to the lower right object, will pass through the lower left corner. And if you consider all of this figure, to connect the upper left object to the lowest object on the right, they will have to go through the corresponding object in the upper right instead of the bottom left.

It has already been described in Rule 8 for finding the nearest source of subject matter, from a set of candidate sources.

Rule 9 following to determine what the candidate sources of an object considered. The various attributes of an object (content, position 153, transcluding transformation, etc.) are obtained independently, according to this rule, and it may, for example, that an object gets its position from an object, and content from another.

Note first that each candidate source of the object must be considered a source (upstream) of the object under consideration, and therefore corresponding thereto with respect to a transcluding 154 or transclusions chain 155. This is an additional criterion which is added to each of the criteria set out below.

rule 9

Is a candidate source for an attribute of an object considered:

1. sources said subject object, the attribute in question has been modified;

2. sources -or object contained in a source- providing a transcluding its transformation locally 156 and the result is 157 or respectively includes - said subject matter;

3. any result 158 -or object contained in a result which does not include said object considéré- providing a transcluding its transformation locally;

153 (unless we adopt the approach of "Niche" already described that a position change is seen as a modification of the contents of the parent)

154 (said object or an ancestor)

155 (the latter will apply to Rule 9.1 and will be considered under Rule 9.4)

They say that 156 transcusion provides its transformation locally if it has been explicitly created or if the processing has been changed.

157 A A object includes an object B if A is the parent or ancestor of B.

158 (which is of course not said subject matter or an object which encompasses) 4. any result -or object cont < "UTCOME which does not include said considéré- subject of a transclusion whose source is a source candidate for said object 159 considered.

One source candidates for the content or the position being selected as the closest using rule 8 in the case where the transclusion which leads does not provide its locally processing (case of implicit transclusions) must also be found the source for the transformation to be applied there. This will be that which is closest candidate source, the latter being determined according to the same rules (9 and 8).

The inclusion or not of an attribute depends on the type of transformation. Examples of transformations

Introductory Examples: replacement and anti-duplicates

The example illustrated in FIG 113 uses two different functions, "r" making the replacement of all the 1 by 2, and "u" that removes all duplicates in the text objects (but not between objects). The top rectangle represents an object containing an internal transclusion whose transformation is "r". This object is the source of a second transclusion whose result is at the bottom. The transformation associated with this second transclusion is the "u."

In Figures 113 and 114, the lines in broken lines indicate the locations where a transformation is applied; the dotted arrows indicate the flow of information and the solid arrows indicate the transclusions; the content on the bottom rectangles of FIGS indicates what is shown to the user; the rule used to determine the candidate source that has been selected is indicated in brackets.

In this example, no local changes have been made in a result of transclusion, and the source for each object visible in the figure is the object in the upper left corner.

For the object 2: l: is the information flow through the a, not two: a. In fact the a is a candidate source (under rule 9.2) which is not the case of 2: a (Rule 9.3 does not apply because 2: a is the result of a transclusion that provides its transformation locally but this result includes the object in 2: l a). Thus in the figure there is no arrow from 2: a, which is never subjected to the transformation function.

With local changes

We see that now, under Rule 9.1 (a modified source is a candidate source) and Rule 8 (2 a is closer to that: a) information for the object 2: l: has come directly 2: a, and that it is first subjected to the "r" function before being propagated in 2: l a. And conversely, the "u" is no longer used in the object a to object 2: l a.

selection filters with respect to a criterion

As another example of function that may be used with a transclusion, may perform filtering of objects, allowing only those that meet a certain criterion. The filter being performed on the objects of the source it is possible for the user to add any object in the result of the transclusion, even if it does not meet the filter criterion. (Note however that if the object is accepted upstream it pass again on the other side of the filter and thus become invisible to the user).

159 This rule applies recursively. It has the effect that candidates have always distant sources one transclusion relationship. Replacing transformatio

The changes to be applied by a transclusion can be changed or transformed by transformation transclusions.

Figures 114 to 118 show what happens when transformations are changed. Again, the dotted arrows indicate the transfer of information and are annotated with the function that is applied to the passage. The rectangles represent objects and the underlined information indicates local changes (unstressed values ​​being obtained implicitly). Objects are appointed by the values ​​they are supposed to provide

(E.g. to the figure below the object more on the bottom right is called k (g (f (l)))). Between brackets is indicated the rule applied to select the candidate source.

We begin, in the figure the values ​​below when no change is made in a result of transclusion. Seen in the figure that the nearest candidate source of the object considered "k (g (i (l)))" is "g (f (l))." Indeed, "g (f (s))" is a source for the subject matter and it is for the transclusion that provides its transformation (k) locally, so rule 9.2 applies, while objects "k (g (l))" and "k (f (l))," which are also sources, are not a source of transcluding providing transformation locally (and therefore rule 9.2 does not apply), and are not a result of a transclusion which provides its transformation locally, this result does not encompassing the object "k (g (f (l)))" considered (so the rule 9.3 applies not ).160 In Figure 115 was replaced k (s) by maintaining the value 4. It will be described the application of rules 8 and 9 after the replacement.161

Pursuant to Rule 9.1 and 8, source 4 is the closest candidate to "k (f) (4)" and "k (g) (4)". (k (f) is the transformation f transformed where appropriate by k 162 k (g) is the transformation g transformed where appropriate by k.) As to the object rightmost bottom k (g) (k (f) (4)), 9.4 rule allows it to take k (f) (4) as a candidate source which is closer than g (f (l)). Note that k (g) (4) is not a candidate source because it is the result of the transclusion "k (g)" which includes k (g) (k (f) (4)), and therefore the rule 9.4 does not apply.

In Figure 116, three changes have been made in Figure 114 g (l) was replaced by the value 2, the processing k (f) was replaced by h in the top right and bottom left implicit transformation was replaced by t.

As top right transformation was amended in hours for the named object considered h (k (l)) in the figure, the source k (l) of the transclusion h is considered the nearest candidate source 163 under rules 9.2 and 8.

160 Finally, according to Rule 8, g (f (l)) is closer than the other sources candidates. The use of Rule 8 are usually obvious, we do not always mention.

161 Note here that one can also use the following method:

In the previous figure, f is an attribute of the object f (l); k is an attribute of objects k (l), k (f (l)), k (g (l)) and k (g (f (l))); g is an attribute of objects g (l) and g (f (l)).

Replace k (l) 4 means that the attribute k is deleted and the content changed 4. Then for k (f (l)) the nearest source for content is now 4; the nearest source for k is 4 when it is deleted; the nearest source is always f f (l); therefore k (f (l)) becomes f (4); for k (g (l)) by the nearest source for the content is 4; the nearest source is always g g (l); the nearest source for k is 4 when it is deleted; So k (g (l)) becomes g (4); for k (g (f (l))) to the nearest source for the content is 4; the nearest source for k is 4 when it is deleted; the nearest source is always g g (f (l)); the nearest source is always f g (f (l)) whose source is f (l), therefore, the nearest source is f (l); So k (g (f (l))) becomes g (f (4)).62 This depends on the nature of the transformation k. Note that this scenario is rare in general, the changes do not transform transformations but the content and / or positions ... When k does not become crazy g, we say that k (in k (f) or k (g)) is the identity function. Same reasoning for the other attributes ... 163 Thus h (k (l)) rises in via 1 k and h (not via f and k). For the considered object k (g) (h (k (l))), h ( 'are candidate sources under Rule 9.3, but h (k (l)) is closest (in line 8). 165

The figure 117 is the same example, with just a change in addition, k (2) having been replaced by the value 3. The object at the bottom right is interesting that the nearest candidate source is "2 "for the content (rules 9.1 and 8) and then 166 to the nearest candidate source is" h "for the transformation and the latter is itself transformed with k (g), so processing to be applied is k (g) (h) 167. thus observed obtained processing to be performed and the value on which this transformation of two places.168 The figures 118 and 119 further illustrate the use of these rules in the case of transformations transformations. We leave the last instance and the source I is now replaced by two sub-objects, "5" and "s" (5), the second being the result of the first transcluding, transcluding which is associated with the transformation s. the niche approach is here assumed that we adopt and that therefore the two new sub-objects are not propagated to the object that contains 2.

In Figure 119, the contents of the rightmost object above is replaced by the value 6. The object named "h (k (s)) (6)" is now the result of a transformation that is itself the result of the transformation by the transformation by h k s processing.169

Principles of integration to a spreadsheet such as Microsoft Excel is how the transclusions system can integrate with Excel 170:

An extension of Excel will provide the user with a function of creating and transcluding management. In following this extension is sometimes called "the system" or "interface".

To perform a transclusion, the user selects a set of cells (forming a "rectangle" 171), performs in drag and drop and when the "file" choose the context menu option "transclusion" 172 provided by the 'interface.

When this is done, the system creates an object for the rectangle of cells, including child objects are the rectangle cells. If some of these cells

164 For the source k (2) no rule applies since 1) this object is not altered, 2) is not a source transcluding which provides its transformation locally, 3) is not contained in a result which does not include the object written k (g) (h (k (l))) in figure ...

165 Thus, k (g) (h (k (l))) rises in 1 through k, h and g (and not via 2 t and k).

166 As transclusion from this "3" source does not provide its transformation locally, one must determine which take.

167 (which, as already explained, k (g) is here a function of transformation processing or the identity function)

168 Figure 117 and Figures 118 and 119 show that the transformation h is individually transformed into a transformation k (g) (h). However, as already mentioned, h can be implemented as an attribute of the result of the transclusion at which this transformation is associated.

169 Let us recall that each transformation will not necessarily transform the transformation that is upstream, it can indeed be content to transform the content and / or position (or even be the identity function that is to say no transform anything) but is described here the most general case.

170 For Excel is meant here any spreadsheet. Excel (Microsoft Excel) is a registered trademark of Microsoft.

171 can easily implement the same functionality for a set of cells that do not form a rectangle, see the approach presented below.

172 In applications there in general (especially when using the right mouse button) options "Move Here", "Copy Here", "Create a link here." add the option proposed "Transclure here." had already been grouped in a jet obje and not they who becomes a child of the new object 173.

We will now present an implementation for associating transformations to transclusions and manage.174 The changes are described here as "Excel Formulas" parameter.175

To handle correctly the system must analyze Excel formulas and are identified dependencies. It is said that a depends on b the formula defining a contains a reference to b.

The approach is as follows: Suppose (as shown in Figure 120) that the user has made a transcluding 1 of an object (the result being the object 1 a) with a function g (x) as processing . Say that the object contains a cell A2.

In this example, following the rule 9.2 (such as transcluding 1 provides its transformation g (x) locally), the formula entered in the corresponding cell B2 will initially = g (A2).

Suppose the cell A2 is defined by a formula f which depends an Al cell is also contained in the source of the transclusion (f may optionally depend on other cells as well).

Assume now that the cell Bl corresponding to Al with respect to the transcluding 1, be changed by the user, as shown in Figure 121. To apply the rule 9.1 and 8 for the considered object B2, the system must change the value in B2 to now to Bl (Bl has since become a candidate source by this rule 9.1 and that according to the rule 8 is closer than Al or A2). To do this, the system will simply reproduce the formula '= i (Al) "A2 by shifting the references therein (this amounts to programmatically perform copy and paste A2 in B2, so instead of = f ( al) which is the formula defining the cell A2, to set the cell B2 will Excel = f (B) in the latter). It is said that the new formula, which defines B2 is the formula 1 (Al) transposed.

Thus the image of a formula through a transclusion is seen as an implicit transclusion. When a source of such implicit transclusion is changed for the first time, the system changes the result of this implicit transclusion automatically to reflect said formula and formula Excel can perform this on the source in question (pursuant rules 9.1 and 8). Advantageously and Excel are allowed to apply the transformation associated with this implicit transclusion.

173 To the extent that an object may have more than one parent must refuse a transclusion which would result in an overlap of objects, that is to say whether the source or the result of a transcluding intersects the source or the result of possibly different transcluding, without one being contained in the other. Alternatively, we can consider that the objects with multiple parents are treated as if they were different objects (with different identifiers).

174 Implementation in Excel transclusion feature "without processing" can be as follows: during the creation of the transclusion, and each time a cell of the source changes, the result is automatically updated by running the copy and paste feature of Excel, copying the cells of the source cell of the result. Note that the cell contains a formula are not treated differently because the copy and paste function already can handle them properly, shifting the references 174 if necessary.

175 can also have as transclusions formulas to several parameters, then the approach is to consider a virtual object, which encompasses all cells represented by these parameters, as the source of the transclusion. But the same cell could then have multiple virtual parents. We have already mentioned (just above) the approach of treating objects with multiple parents (by treating them as if they were different objects while doing the act ultimately in the same object). In consideration of this advantage, in the transcluding, the system must monitor the cells in question (that is to say, the sources of said implicit transclusion) and a substitution of the formula where a change in the applied rule (Rules 9.1 9.4) requires. In particular, if the user cancels the modification of Bl, B2 in the above formula should be replaced.

To illustrate this process more concretely, here's another example. Suppose that cell A3 contains the value = A2 + 2, and an A2 and A3 transcluding is performed, by matching A3 to B3. If the transformation (x + l) * C8 is associated with this transcluding, where x is the source parameter, the registered transclusion = (A3 + 1) * C8 in the cell result B3, and = (A2 + 1) * 8 to the position B2. If the user then replaces the value of B2, for example to write 10, the definition of B3 is automatically changed to become B2 = + 2.

Thus, the system is designed so that if a cell reference to another behaves in the same way as if this reference is created using a transclusion, although there are some differences in treatment : • When the user registered in a cell a formula containing a reference to another, the system (that is to say the extension described here) is not involved (and let Excel do as if it there was no extension). However, as described above, the case of a transclusion whose source contains a cell having a reference to another cell of the source is specially treated (by analyzing the references in the formulas) to reproduce the behavior of internal transclusions .

• When the user transclut several cells at once, it does not need to specify the transformation to be done once. For example when changing this transformation all cells results are updated. • A conceptual difference is that a formula can contain references to several cells, unlike a transclusion that has a source.176

Thus the manipulation propagation method along the transclusions in Excel as follows:

Rule 10: 1. Let the item: a image of an object by a transclusion 1. Let Vo) all the references found in the formula giving the value of the object 77. For the object 1: considered ( "considered" under Rule 9), view all {b} and their corresponding s: {b} (when available), as sources. Applying Rule 9 to determine which of these sources are candidate sources. 2. Since (under Rule 8) for any b taken in {b}, the b is bound to be closer than a and b, if any 1: b 1: {b} is a candidate source, then the set 1: {b} is considered as a candidate source. The formula to indicate in a while is the transposition of a, containing references to the: {b}. Otherwise, that is f (a) to be placed in 1: a, f () being the processing associated with transcluding 1.

Note that in the case of cells {b} does not in the source of the transclusion, it may be preferable not to transpose their references, regarding them as absolute. This therefore reproduce the behavior in case of transclusions regardless of Excel.

176 As already said, the case of transclusion whose formula contains references to several sources can be taken into account by the system assimilating these sources to the descendants of a single virtual source.

177 {b} is an empty set if a is defined by a constant. The examples of FIGS 122-126 r lication rules seen so far. They illustrate how internal transclusion or not and references by formulas interact. The values ​​or formulas given in cells are those that are visible to the user, the actual calculation formulas is left to Excel. The values ​​provided by the user are underlined, others are implicitly obtained by the system.

Figure 122 shows the state of the cells in the absence of changes in the results of transclusion. All cells in a result of transclusion contain a reference to the corresponding cell to the source, to which is applied the transformation associated with the transclusion. The part of the rule 9 which justifies the formula in each cell is indicated in brackets.

Now here is what happens if the user makes two changes respectively in the BI and AI.

As A2 contains a reference to Al (without however being a transclusion) and the corresponding Al (B) is changed in the result of the transclusion 1, according to rule 10, B2 (which initially contained the value = A2 * 2) now contains A2 transposition.

AlO has not been modified locally, Blo always gets its content of Bl (modified nearest source, rule 9.1) transformed by 6 + x.

The nearest candidate source BI l is the AI. Formula BI l is obtained by applying the transformation x * 2 Al 1 (instead of the processing 6 + B2). Finally, in Figure 123, the initial sample is taken (shown in the penultimate figure) and it is assumed that instead of 6 + Al, AlO the cell contains the constant 100.

Accordingly, according to 10, rule as the source (A2) AI l depends on Al and the corresponding (AlO) of Al is now amended, AI l receives Now = A10 + 2, A2 transposition (rather instead of 6 + A2). The modified source closest to blo is now AlO. Formula BLO is thus obtained by applying the transformation x * 2 to AlO. Similarly, the nearest candidate source Bl 1 now Al 1 (under Rule 9.4).

We see that the references in formulas perform well as internal transclusions. multi-versions objects

Technology changes associated with transclusions can be used to manage objects transformed versions for different users.

Recall that ERC is seen as a group of users (independent of the concept in the corresponding operating system). This concept is used by the system to determine which objects make available to which users.178

A resource is always viewed through at least one (ERC and ERC can be selected said read-only 179).

For recording data specifying what or what ERC data should be visible (it is selected ERC write).

178 This access control can be placed above or after the test by the operating system.

179 For an ERC which the user has write access rights, the ERC can be opened in read-only (to receive contributions from other users of the ERC in question but help yourself in this nothing ERC). The interface allows to easily switch from Playback mode to read-write mode. Preferably, there is a default I r, named EO or "default ERC" to which everyone has access to at least read, which is used to produce data without restrictions.

The multi-versions objects are objects that are presented differently depending ERC used to obtain them.

They are defined by a base object and for each ERC, a transformation to be applied on this base object for the version corresponding to the ERC considered (it can also transform versions that have themselves been obtained by transformation of a base object to still get other versions).180 ERC for which no version is specified simply do not have any access to this object.

When a version of a multi-versions object (or one of his descendants in the structure of the resource) is used as a source of transclusion is a transclusion of the object Multi versions is performed.

Example of multi-version object The document "a" shown in Figure 125 contains a list of articles on various subjects. Consider three ERC El, E2 and E3.

By accessing the document by ERC El we see the entire content, so that by accessing by one of the other two only a subset (filtered by the transformations f ^ i and fε 3 for example depending topic posts) is displayed. Changes made via El have spread to two other versions (since filters let them pass). A change made with one of the two other ERC is visible only with ERC 182 in question.

Suppose that a user viewing the document by ERC E2, selects two items a2 and a3, and performs a transclusion in a new document n. Suppose that during the creation of the latter he had asked it to be visible to everyone (not limited to the ERC E2). To do this he selected EO writing.

The structure then obtained is shown in Figure 126. The dashed lines are the transformations leading to different versions, the dashed lines delimit frames multi-versions objects and for each version ERC concerned is shown at left. User interface

The interface allows the user to open (select) a number of ERC (of those where he has access) read-only or also in writing according to the rights of the user. ERC are arranged in order of preference of the user and the user can change that order.

For an ERC which the user has write access rights, the ERC can be opened in read-only (to receive contributions from other ERC users in question but contribute nothing oneself in this ERC ). The interface allows to easily switch from Playback mode to read-write mode.

180 As described below, the multi-version has child object corresponding each has a different ERC, interconnected by transclusions wearing transformations. The child corresponding to the current ERC is automatically selected in place of the multi-Version object.

181 That is, when transclusion a descendant of a version is carried out, the true source of the transclusion is the set of multi-release object, and the transclusion is provided with a transformation performing a selection the object in question.

182 (but can be contributed to the upstream, that is to say El) When viewing a multi-≥ur to object versions for which the ERC is open are accessible via the interface, and the first in the order of preference is displayed by default.

If none of the ERC for which there is a version is open, nothing is displayed as if the object does not exist.

The system provides the user two ways to change the version displayed. First, change the order of preference in the list of open ERC immediately affects the automatic selections. Furthermore, individually for each multi-version of this object on the screen the user a way to change the displayed version, for example using tabs, or a button that appears when the cursor is on the object or when the latter is selected.

Figure 127 shows how this is the default user interface when the user views the document "n" in the previous example, by having the ERC ElO, E3, E2, El, EO selected as open, in that order preference. Since there are versions of a2 in E2 and El, and E2 is preferred in El is the version of E2 is displayed, then that is the version of E3 that is displayed for the item a3 as there is one in E3 and that the ERC is preferred E2 and El. of course the tabs (allowing for each multi-object versions to select the version for a given ERC) are displayed only in active mode (that is to say that the tabs mode is switched on / off) by the user.

When the user manually selects a tab of a multi object versions, the system remembers this selection and restores the next time the user displays the resource.

We will now describe the user interface for the ERC selected for writing. Regarding the creation of objects, whether in a void or a result of transclusion, the interface can be placed in two modes, manual selection or automatic selection ERC.

In automatic mode, the added objects are placed in the same ERC as their parent.

In manual mode, the user chooses from the ERC opened read, write an ERC which by default will receive the items. If the user has chosen ERC El for new objects and creates an object in El version of an object, the new object is simply added directly. If (as in Figure 128) ERC-containing (ie E2 in the figure) is different from the ERC chose El, a new multi-Version object is automatically created, initially containing only a version for El . to create a multi-purpose version of the user first creates the basic version of this object 184 185, then after selecting request to create a new version 186. He can then choose for which ERC must create the new version (the interface should however help create two versions of the same object for the same ERC).

The interface also provides a transfer tool (copying, moving, transclusion, etc.) between versions of a multi-Version object. If, as in FIG 128, the El of the object version contains an object b (and is the first ancestor of b to be multi-view), the user

183 The configuration of selected versions (for resource) can be saved (in a server).

184 If the basic version is created in a different ERC from the parent, it will be created directly as a multi-purpose versions.

185 (or chooses an existing object that is not multi-view)

186 For example in the context menu. In the case where the object is already multi-version of this tool can be presented at the tabs, in the form of a button "Add a tab" selects b and then activates (e.g. \ mtextuel) the transfer function that he wants to use. The system allows him to choose from the list of versions is presented as a list of ERC, which serves as the destination of the operation. If there was already a corresponding object 187, the system displays both objects and proposes to replace the existing object.

Note that it is possible to open multiple "windows" simultaneously (which is shown schematically in Figure 129), which is useful for example if the user wants to simultaneously view multiple versions of the same object and perform transfer operations complex between descendants of these two versions, for example, transfers between two points separated by more than one multi purpose versions.

Implementation using transclusions

transcluding the process used to implement the multi-versions objects.

As already said the various versions of an object are obtained from the basic object using transformations. To achieve this it suffices that all versions are transclusions of this basic object, and that the desired changes are associated with transclusions. This gives us the structure shown in Figure 130.

The ID has * is given to the multi-version object. Now, when the user asks to see the object * is one of a, 2 a and 3 a is spontaneously showed him, according to the ERC used. This replacement is performed recursively, if the version displayed itself contains other multi-versions objects.

Now here is how the example of transclusion above. The left side of Figure 131 contains the structure of a * already seen above.

When the user makes a transclusion of any of these objects, the system actually a transclusion of a *. The following diagram shows the transclusion (10) 2: a2 (that is to say a2 seen through ERC E2) and transcluding (11) 2: a3.

We see that the multi-versions objects transclusions results are transclusions a * itself. The function associated with these transclusion is s (x), where x is the ID of the object transclu by the user, which means that in each version must only keep this item x and its different versions (with their descendants ). The result of multi-version object transclusion 10 contains no version for E3 3 because: a2 was filtered by f E3.

If the user had carried out 188 such copies instead of transclusions, the structure shown on the right was completely rebuilt instead of being implicitly described by relations of transclusion. multi-version nested objects

It may happen that it is necessary to place a multi-versions object in a particular version of a multi-version object.

For example in the above scenario, if the user who built the page n decides to place a personal annotation inside 10: 2: a2, if he wants to be the only one able to read requires that it is to CRF other than E2.

187 Several criteria can be used to establish the correspondence. As explained below, different versions being obtained by transclusion, examine the object identifiers is sufficient. It can also handle the case where the object had been copied transclu or explicitly, by checking if there is already a transclusion or copy of b in the version.

188 (or displacements) Suppose ElO is ERC particu lisateur, the annotation must be only visible in this ERC. To do this, create a multi-Putilisateur Version object with a single version for the ERC ElO containing its annotation.

Represented as a tree, the document n then have a structure as shown in Figure 132.

Implementation Approaches for access control

To be general enough considering that the structure of transclusions is stored separately from the content, the first being stored in collaborative servers and the latter in content servers 189 (as previously described). Normally, each of these servers performs access control and thus identifies the user 190 before read or modify any of these data. For each user a list of the ERC which it belongs, together for each access level (read or write) is stored in a server for this purpose.

When users share resources, one approach is to share what they actually references to the past, allowing multiple users to collaborate on a same resource by not seeing that the versions which they have access.

Another method is to encrypt objects with keys corresponding to the ERC allowed to see them. The user has a copy of the private key to the ERC which he belongs. When a user wants to read the resource it decrypts the stakeholders using the appropriate key, and when he wants to change it signs its modifications using the same key.

Advantageously, the method using encryption allows the user to have all the data locally, even those for which it has not access and exchange or copying by conventional means. ERC related to reading and writing

If one wishes to distinguish at this level read access and write permissions can use different key pairs for both types of access. As part of an encrypted resource for some ERC is encrypted with the key to reading "read" and signed with the write key "write". Thus, a user with the private key reading readpr v + readp Ub and only the public key pub write writing can read and verify that the author of the resource had many private key writing but can not edit. The following diagram illustrates the changes made to perform a read access or write to the encrypted document. See Figure 133.

server encryption / decryption A disadvantage of the method based on encryption is that it is difficult to remove a user from an ERC because the system can not force the user to delete the key. It may therefore be necessary to change the key of the ERC, but the previously encrypted versions will then be translated to the new key.

Another problem is that the risk of information disclosure is greater, because if a user discloses the key to ERC to another person it can decrypt the resources without the system noticing. For example if the user belongs to IU

189 Of course, they can also function as a single server or even be implemented on the computer of the user.

190 An authentication server here could be used to prevent the user from having to authenticate separately for each server. ERC El and E2 and the user U2 n '; El ι if IU provides the key E2 U2, the latter may, while s' normally authenticating as U2, access to parts of a document amounted to E2, which ought to have been inaccessible, and the server will see nothing as it is authenticated as a user with access to El and can therefore access this document. While in keeping everything on the server the only way to get U2 E2 data would be to use the identity Ul.

We can therefore consider an intermediate method, combining the advantages of both approaches:

Users do not have the private key of ERC, which are rather placed in a server encryption / decryption (which can be combined with authentication server). This server stores the private keys of all the ERC and, for each user, the list of ERC which they belong (with the access levels).

A user can then (after having proved his identity) submit to the decryption server any encrypted object, and the latter returns the version or versions that the user has access. The same server can also provide the inverse operation and digitally sign the amendments to the object, for authorized users.

So users can always store resources locally and exchange through traditional means (thus remaining independent of content and collaboration servers servers). The key revocation problem is more raises, as soon as a user is removed from a 191 ERC decryption server stops accepting requests for this decryption ERC.192

If this method is adopted, one single key pair by ERC enough for both read rights as rights in writing, as the decryption server checks the access rights before performing any operation.

However, this method has disadvantages related to resource exchanges between the client and the server encryption / decryption.

key storage in association with the contents

The cipher / decryption at the client offers the benefits of: • decentralized treatment (avoiding the bottleneck at the server)

• not having to use a remote server encryption / decryption resources (including savings and bandwidth)

• and above all be able to communicate to third parties encrypted resources with all existing versions, including those to which the user (the communicator) did himself no right of access 193 but that would be accessible by a recipient .

But such a method can have the disadvantage already mentioned key risk disclosure to third parties who do not (or more) law and thus enable them unauthorized access permanently.

191 (for a specified level of access)

192 (The user can of course be kept clear versions of old resources, but can not access resources produced after revocation).

193 1 (read or write) can limit the impact of such divulg ant reach key 194, and the extreme by having a specific key for each update: Day (of each version) content. To do an intermediate server is used with which the user communicates key 195 (rather than content). We will now describe this approach. When the user 196 encrypts a content to save it, it combines this content with the respective key pairs versions multi-versions objects (ERC 197) it has generated, and this association is stored in a server key 198.

When a user requests access to said content 199 (after authenticating) the key corresponding to its rights it is transmitted from the key server, parallel to the content (encrypted) that is provided. The user can decrypt versions of the content which it is entitled. (Architecture underlying work setting may actually involve other intermediate servers as described in the section with the overall architecture).

Advantageously, the user can transmit the encrypted content with (any key or part) of the key it received from the key server, to another user by traditional means (eg by email) without involving a content server. The other user may then request to the key server additional keys he wants and he is entitled and possibly then have access to versions of multi-versions objects to which the first user did not himself access. Encryption multi-versions objects

When a resource contains parts with different rights, here's how the encrypted resource is structured.

We call connected part of a resource a set of objects such that for any two objects together, said objects are connected to each other by a path consisting of parent-child relationships entirely contained in 'together.

If all objects of a related party are in the same ERC, it is called homogeneous part (from the perspective of rights). We talk about maximum homogeneous part if it is not contained in a homogeneous part greater.

Consider the set maximum homogeneous parts, and each is associated with the location in the resource, typically as the ID of the parent

194 can renew key to limit the impact of disclosures: (1) renew the key every time you remove a user the right to access (or following a decision of an administrator determines that a key has been disclosed); (2) rekey periodically, for example once a day; (3) rekey automatically each creation or updating of content (such content can be a resource, a part of resource, or a simple object) for the ERC in question. This is the approach (3) which will be described in detail. The approach (1) can be seen as an optimization approach (3).

195 More specifically, the user communicates the "associations key server (" key content-ERC ") between including key identifiers and content as the key used to decipher the key server knows which version content may be decrypted by any key and gives the information to which he is entitled.

196 The term "user" means well "(the extension of) the tool of manipulation of information that the user uses on the client."

197 Preferably, the content in question is partitioned into different parts (each part being homogeneous from the standpoint of access rights). Each part has an associated key pair. These keys are stored in a key server or with the content in the content server. When a user downloads content it receives the full content with the subset key corresponding to its rights.

The content server 198 may itself act as a key server, in this case one does not need a separate key server. The advantage is when the keys are stored directly with content. The disadvantage is that we must trust the content servers ...

199 Keys are required to key server (indicating the identifier of the desired content and the ERC used) in parallel with the request of the content itself to a content server (or opening the local content in the computer). root of this part (if any) and pr root (if it exists). In the following part by means maximum homogeneous part.

Then each part is encrypted and signed with key corresponding to the CRF, and the encrypted data are then placed in sequence to form the encrypted resource. The example in Figure 134 shows in Figure 132. The lines are interrupted at the ERC change location. It is assumed that two multi-versions are in the same ERC ERC that the root of the resource, while the Multi-Version object used to add an annotation (in ElO) is in the same ERC his unique version. The reason could be that the owner of the resource "n" created the Multi-Version object * in the ERC EO, to be sure that it is accessible to everyone, and has added versions for ERC El, E2 and E3. However when the user has added the note b, not having write access to the ERC E2 (or having off), both multi-versions object b * the annotation itself are in the same ERC (and thus in the same maximum homogeneous part). The numerical structure of the resource will be the one in Figure 135.

Each portion (represented by a rectangle with a name label ERC) is encrypted and signed with a key pair corresponding to this ERC.

To allow users to copy multiple versions of objects from one resource to another without risking conflicts of identifiers can partition the resources in several "areas of identifiers."

Each party is in exactly one space identifiers 200, 201 and references to other objects when they do not specify space identifiers, do not transgress limits. It is possible to cross these limits (the following example will show how) by explicitly naming another space identifier of the resource. This allows a user to copy a multi-versions object in another resource, even if the user has write access to the parent or the target resource or the versions of this multi-version object (see Figure 136 ). It simply creates a new space for IDs in the target resource, copy all the desired versions in this space, and adds (always in the same space of identifiers) a new multi-purpose versions of the same identifier as the source resource . To place this new multi-version object in the structure of the target resource, it shows the name of the space of identifiers containing the parent, in addition to the identifier of the latter.

In the example in Figure 136, the user wants to copy the El and E2 versions of the multi-version 2 * object, from the left of resource under object 3 to the right resource. A new space IS2 password is created in the target resource (and the space is called ISL), the two parts containing 3 and 11: 3 are copied without having to change the 202, and new part is placed in this space, serving as a connector between these versions and the object 3 ISL space.

This section therefore contains an object (multiple versions) Single, which specifies as the parent object 3 space ISL identifiers. The colon indicates that it must first get out of the space IS2 password before you can enter the ISL space (in the manner of a directory hierarchy).

200 (marked "SI" as "Identify Space" in English)

201 especially used references to indicate the source of a transclusion, and to indicate the parent and the predecessor to the root of a part, as will be explained later.

202 They therefore do not need to be decrypted. If the parties to copy couvi; identifier spaces, it is necessary, in the target resource, use nested identifiers spaces, that is to say, to create a new identifier space contain any part but containing the same areas as those used by the parties on the side of the source (see Figure 137). Transfer Opportunities

Here are the possible operations in the framework of the mechanisms described above.

• Add Objects (created or transcluded, multi-version or not) in a resource (even within a party that is not writable, but read-only). • Copy a multi-purpose versions of a resource to another (or the same)

• Copy one or more versions of a multi-versions object is a resource, either in a new multi-purpose versions, either in an existing multi-version object.

• To delete one or more versions of a multi-versions object.

We can consider two variants of an encrypted resource structure, depending on whether the parties indicate their position (ie parent and predecessor) in clear (ie only so signed), or if this position is encrypted.

The first variant allows, when handling (copying, moving or deleting) versions, to act on non-accessible versions in writing (because the position indicates what among other multi-version object such parties are). In particular, this variant allows, when copying a multi-purpose versions, all versions are copied, not just those readable (so that a user has read access to the other versions can see in the target resource).

The second variant has the advantage that if one has not read access to parts (such as annotations), one can not find out where they are in the resource. This variant is interesting in the case of annotations placed by a user.

It is possible to have in the same resource, even in a multi-versions object objects adopting the former approach and others adopting the second.

Note again that it is not possible (for a user not having write access) to perform these operations to a finer degree than the parts (eg only copy an object from one version of a multi-purpose versions), because that would imply to change the content of a part, which is not possible even after the copy operation.

Note that the transclusion operation of a multi-versions object or one of its descendants is not affected by these considerations, that the result object is built implicitly, and contains the reference to the source of the transclusion (unlike the copy does not keep this reference, and not following the changes to the source). Therefore, irrespective of the variant used transclusion will behave in the same way as a user who can access an object operating same according to the second variant will have its position in the source of the transclusion and can deduce (by applying 'transclusion algorithm) the position in the result.

Example

Figure 138 shows the result of a copy operation from one version of an object multi versions. We see that it was necessary to return the source of the transclusion relationship. Figures by dotted lines indicate parts c ι ERC which the user has read access.

This is possible even though the user has read access to the version for E3 (as part of the first alternative, where the position is public). Then, the annotation present in the original has disappeared, this happens if we assume that the annotation using the second alternative, that is to say its position is encrypted.

The example in Figure 139 shows the result of the same operation, the user has asked to copy the entire multi-versions object rather than a single release. We see that the structure has been reproduced identically in the target resource, including the parts that the user can read (again assume that these parties use the first variant).

Note therefore that in this case the source of the transclusion is transferred to the corresponding part (the one being in the ERC El) in the right resource.

Here, for the same reason as in the previous example, the annotation disappeared, assuming as before that his position is encrypted. replacement objects in multi-versions objects

We will now describe how to exploit the concept already described (see the contributions of propagation section in the branches) replacement items (and alternating items) in the context of multi-versions objects.

When a user wants to make a contribution to a resource, it can create a multi-versions object (or, if appropriate, add a version to an existing multi-version object), in the same ERC that the parent, or the same ERC an already existing version, but associated with its identity as that user.

From the perspective of the user interface, as shown in Figure 140, this means that in the presence of contributions, rather than a multi-version object has a number of versions indicated by a set of ERC, we will more versions labeled by ERC / user pairs. We can have a mixed situation where there ERC for an updated version collectively (El), as well as individual contributions versions (El / IU; E1 / U2) for the same ERC.

This association can be done by assigning each user a pair of keys, and by signing each user versions of multi-versions objects he produces.

The changes in contributed its release will therefore be propagated as replacement or objects in the other versions of the same object and the same ERC, created by other users. Several users can work together on a resource, and separate into different branches in case of refusal (forming several working groups for the same object in the same multi-versions object).

As already stated, the different versions are managed as transclusions contained in the multi-object versions, allowing replacement of objects to move between objects corresponding to the same source created and located in the different versions of an object multi-version. When a user adds a version (labeled ERC / user) can choose from which to work, and in the structure of the multi-purpose versions release added by the user is a transclusion of the selected basic version.

Figure 141 shows the structure of objects in case a milt change in a result of transclusion (l a) which was introduced as replacement at its source (a) was rejected by the latter, then resulting in a alternative object (2: 1: a) in the same ERC than its contributor and so labeled with his user identity (E2 / U1). The alternative subject (2: 1: a) is a result from the contribution denied, that if it evolves, the alternative object that comes from it can synchronize.

Managing time versions of objects

Alternatively you can implement a mechanism for the objects (classical) temporal versioning, successive contributions on the same object then being seen as its temporal versions. In the case where a contributor of a previous temporal version of an object refuses the current time release (more elaborate) of an object, he passed through a 203 labeled version of a pair composed of the same ERC and the user who contributed the denied release. Replacement items may well flow along transclusions particularly as already described in "contributions of propagation in the branches" section.

If the information handling tool has a version control functionality, take for example the case of Wikipedia, we can implement the following method: When the contributor of a previous version of a Wikipedia page visit the current version of a page, the system presents him as replacement items, the changes that have occurred on this page since the last version he himself had contributed.

The user can refuse some replacement items, and they are then in other areas, that is to say, they form other versions of multi-versions objects.

Advantageously, such a method may be implemented by a simple extension of the web browser (and of course we must also provide a collaboration server), irrespective of the Wikipedia server. In this case, only the contributions of members of ERC are presented as replacement items, and become alternative objects when they are rejected. The Wikipedia server itself (which provides temporal versions of Wikipedia pages) can act as a content server. Users who are not members of ERC (or who do not have the web browser extension) continue to use Wikipedia as before.

global architecture implementation Figures 142 and 143 have an architecture comprising the key server described above and a server processing that implements the transformations associated with transclusions as previously described.

First Figure 142 illustrates the update process of content by users.

In the example shown in this figure, a content, which is in a first content server, is transcluded by Tl transcluding to give the result is T a that is stored in a second content server, then it is itself transcluded by transclusion T2 to give T2: Tl: has in a third content server. A is also transcluded by the transclusion T3 T3 to generate the result: a.

Note that the results of transclusions which are presented here as being stored in different content servers, may as well be in one content server 204 and may be versions of a multi-versions object, it would not change nothing in the principles of operations presented herein. It is thus described by an implementation architecture including the case of multi-versions objects.

203 (as of versions of a multi-purpose versions)

204 (or for that matter even on the client user) Note also that all this content is content servers are encrypted as described in the previous section.

The arrows labeled (1) indicates the user access to modify respectively a, Q3 a and Tl: a. The method comprises a step, represented by the arrows (1 '), which involves providing the transformation server changes, as well as the keys generated following these changes (and allowed to encrypt the modified contents in question).

Next, (2), the processing server communicates

• the collaboration server identifiers modified contents, and • the key server key associations - modified content identifier.

To prevent the collaboration server propagates transclusions which actually will not happen 205 in (3), the collaboration server communicates to the processing server identifiers of potential new results of transclusions 206 and it returns him filtered set of results. Indeed, the transformation server is able to apply the transformations associated with transclusions (which may be in particular filters applied to sources) when they do not involve other objects that the modified content that was available to it, and determine if they are filtered by these transformations.

Figure 143 presents the content of consultation process.

(1), the user 207 obtains the content T2: Tl: a processing server. In (2), the latter gets Collaboration Server addresses the contents of which provide updates to perform on T2: Tel: 208 is here so this content is, Tl a T3 and a who were changed as shown in Figure 142.

In (3) processing the server obtains the content key from said key server.

In (4), the processing server applies the changes on modified sources it gets respective content servers.

In (5), the user saves the content T2: Tl: updated and processed in the content server.

We can implement several methods to save the modified content. First of all the changes can be saved in a structure containing only the modified contents and references to sources. Then, and this becomes advantageous when the amount of change exceeds a certain threshold, you can record all the current version of the content in question.

In (4), if only T2 changes: Tel: has recorded the transformation server obtains all the content from the source "a" from the first content server (as well as changes in other sources ). However, if the current version of T2: Tel: has been recorded completely, instead of the entire contents of a, only not yet taken account of changes in a are obtained first content server.

205 This can be seen as an optimization because these transclusions would anyhow filtered when providing results contained in the consultation process, as described below.

206 Using the "algorithm push"

207 (that is to say the extension of the information handling tool)

These 208-to-day updates include changes to the upstream and contributions (replacement and alternative objects) that can also come from downstream. In addition, in the case where the couπ version had been recorded completely, alternatively the item (1), the user can obtenu- the third content server the last current version of the content T2: Tl: a key and the corresponding the key server, and then obtain independent processing server updates to apply it. Measurement contributions

credit calculation that a user has

It involves measuring how much a given user contributes to ERC and how its contributions are valued or otherwise rejected by other users.

therefore assigns each user a credit, initially neutral. Various user actions will alter these credits.

clean credit

The own credit of a user is increased when making a contribution.

When a user changes branch (either because of a replacement subject to rejection or explicit change), the latest revisions of each part constituting the previously displayed object sees his own credit decrease, and the last of each contributor part constituting the selected object sees his increase the. Also a branch change due to a refusal must bring a clean credit variation greater than a manual shift arm (because the latter operation does not necessarily mean that the content is deselected poor quality). To obtain more precise results are weighted the own credit changes by the magnitude of the content in question (a small contribution thus less influenced own credit its author).

Moreover, it can give greater weight to user actions with credit (total) higher. We must avoid, however there are methods for a user to arbitrarily increase its own credit (alone or with accomplices). In particular, if simply to contribute content to allow a user to increase his own credit, users could simply produce a large amount of empty data direction and increase their credit. Here solution approaches: If the contributed content is denied by many users, the penalty is greater than the own credit obtained by it.

The credit earned at the time of creation of content depends on the estimated number of users who will see it (to prevent a user to get credit by producing content that no one will read and therefore refuse) . One way to estimate this value is the number of users for whom the branch containing this item is selected. One can also consider having transclusions this object or its parent as a source to count users who will see a picture of the new content in a result of transclusion.

Finally, (always depending on the number of users that can access this content) fixing a maximum limit to the credit obtainable by adding content. Beyond this limit, contribute new content has no effect on the author's credit. Credit approval

Users contribute content in a domain followed by few other users should not be penalized too, as this is the area that is unpopular and not specifically the contributions of these users. The method described below shows how users can increase the credit users they approve.

day is taken for any user pair the "approval factor" of the first to the second. To avoid that this has an exaggerated effect it also limits the amount of credit a user can create to another, limiting the factor between 0 and 1 / n, where n gives an order of magnitude the number of users going to see A resource. When a user shows interest in a contribution (the clearest way is by making a transclusion, simply select the corresponding branch is also an indication of interest, as well as simply visiting the resource containing the object concerned), the approval of the visitor factor for the author of the contribution increases. In order to regulate the approval of factors, one can for example decrease regularly, so that when a user showed great interest in the contributions of another, its approval for the latter factor will gradually decline.

So let x own credit a user, et al, a2, a3, etc. factors approval from users with xl, x2, x3, etc. as credit. Suppose xl <x2 <x3 <etc. When calculating the effective credit of the user is performed as follows.

The initial credit is K = x.

the following operation is carried out successively for i = l, i = 2, etc.

If K <x then is replaced by K + K (xi-K) * have.

Thus, if the credit exceeds visitor to credit the author of the contribution, the second credit is increased (avoiding of course to make the increase more than once for a visitor and a contribution).

Application of the process conduits propagation relevance scores

Can adapt the process conduits propagation relevance scores as described in WO05045698A2 transclusions a structure as follows.

The basic idea is that the score of an object is related to what is present (visible, audible, ...) in this item (and possibly within the meaning of that content). So we will place pipes (all the same size) along the transclusions, propagating the score from an object source in the direction of its image in the result of the transclusion. In the presence of internal transclusions, ducts are placed along the flow of information, that is to say, for a result of transclusion is placed a conduit that since the nearest candidate source.

When the source and the result of transclusion are not in the same line, the size of the conduit is reduced, for example, is set at half the size of a pipe branch does not change, to reflect the fact that replacement items do not change branch.

To properly handle the changes in result of transclusion, it also places the ducts propagating the score of all the objects in the direction of their parents. This will mean that parents will have a score taking into account the average score of their children. Thus, if in a result of transclusion objects are added, modified or deleted, the score of the result of transclusion will be affected accordingly. Three applications are:

When an object receives a lot of alternative contributions, the system can sort by relevance (and keep only the first), by calculating the proximity of each contribution with the container 209, and possibly based on credit contributor. Second, one can selectively place the contents (such as advertisements) in an object, according to their relevance vis-à-vis the containing object (possibly also based on the contributor's credit).

Third, one can also use the method described in WO-03 057648 to select annotations made on nearby resources. Note that in this latter application, can benefit from the structure of the 'positions' maximum homogeneous parts (described above) for the placement of information to determine how to present in a resource annotations contained in a nearby resource .

Preliminary definitions 10

Object, Resource 10

ERC, collaborative server. 11

user 11

Description 12 Introduction 12

Illustration of the principle of the method 12

Versions of a collaborative resource, 13 branches

Watch alternative versions of a collaborative resource 15

Bypass 16 Categorization of versions of collaborative resources 17

Structural changes, slots 17

Inconsistency management 19

Merger of branches 20

Case's unique collaborative resource Transclusions 20 21

Implementation 21

architecture 21

data structures 22

Constraints 23 Algorithms 23

Construction of the present structure for a version of the collaborative resource 23

Change of the active branch 24

Reaction to a change 24 Treatment of object creation 24

Treatment of a refusal 25

Managing concurrent operations 26

propagation restrictions 26

Read protection Write protection 26 26

Unidirectional propagation 27

Variation: resources versions as Transclusions 27

Illustration of the principle of the method 27

209 (possibly taking into account the user's browser session in context). The process of creating the most el 28 items

Creating resource derived 28

The amendments are proposed to the upstream 29

Example 30 Background of Example 30

A method of determining the replacement object and alternative objects 31

Ignorance or acceptance (Fig. 26) 32

Rejection (Fig. 27-32) 32

multiple derivations of the same resource (Fig. 33 through 44) 33 Description of Rule 3 (fig. 45) 34

Substitution / Grain Enrichment (fig. 46-49) 34

Slots (Fig. 50) 37

A method of sorting objects by alternative scoring (rating) 38

A method of sorting objects by contextual relevance alternative method of substituting 39 co-identification 39

A method of transcluding 40

iD 41

41 transclusion

implicit transclusion internal transcluding 44 Alternative identifiers 44

Calculation of the sources of an object 44

Original information 44

Distance sources 45

First method 45 Calculation of the proximity of an object relative to another 45

Second method 46

A method of transcluding in "pull" 46

Calculation of an object - local algorithm 46

Calculating an object structure - global algorithm 47 Method for transclusion into "push" 47

Composite structures 49

centralized architecture or cascade 51

Contributions spread in branches 52

Description 52 Behavior of grains in the presence of 53 transclusions

Counters of activity 54

Objects container, Transclusion- iusion, Automatic Placement 55

Conditions associated with transclusions 57

Customization Architecture 58 Replacements / Enhancements such proposals for acceptance 61

Use patterns ERC 62

Resources and Recommendation ERC 63

benefits 63

Benefits for publication processes 64 Collective Writing a future publication 64

Benefits to distribute advertising content 65

Benefits for "wikis" 65

Web read-write 66

backlinks 66 broadcast stress Metadata 66

Advantage to circumvent censorship 67

Extensions to existing syndication protocols Interoperability 68 68

PES 69

XML specification 70

Element <pse: part> in <item> or <channel> 70 Scenarios PSE 70

Item transcluded in a channel 70

abstract XML representation 70

Item transcluded within another item 72

abstract XML representation of item 72 Part transcluse within another item 74

abstract XML representation 74

internal and implicit Transclusions 74

ASE 76

XML Specification Example 76 77

Contributions Transclusions and upstream (PES with ESA) 78

example 78

abstract XML representation 78

Collaborative server to PES / ASE 81 TransClusion with transformations 83

Examples of transformations 85

Introductory Examples: replacement and anti-duplicates 85

With 85 local changes

selection filters with respect to a criterion 85 Substitution of transformations 86

Principles of integration to a spreadsheet such as Microsoft Excel 87

Objects multi versions 90

Example of object versions multi- 91

91 User Interface Implementation Using transclusions 93

Multi nested objects versions 93

Implementation Approaches Access Control 94

ERC related to reading and writing 94

server encryption / decryption 94 Encryption multi-versions objects 96

transfer Actions 98

example 98

replacement of objects in the multi-version 99 items

Managing time versions of objects 100 Global Architecture Implementation 100

Measuring 102 contributions

Determining credit enjoyed by a user 102

own credit 102

Credit approval 103 Application of the process conduits propagation relevance scores 103

Claims

RE \ 5S
1. A method for accessing a resource in a computer environment, the resource comprising a set of objects, characterized in that the computing environment is adapted to store in association with at least one object of said at least one modified resource object, in that said computing environment includes means for storing in association with such an object degree information developed, and in that the method comprises the steps of:
- identify, for each object of the resource which corresponds to at least a modified object, from the information of degree of elaboration, at least the more elaborate version of the object,
- assemble the objects thus identified for their display in the resource.
2. The method of claim 1, characterized in that the degree information of an object development derived from the chronology of changes in the object, in that it is provided in the modification of an object by a step for a user to other users refuse the modified object, and that the assembly step is carried out with a version of the object chosen based on whether or not to refuse.
3 A method according to claim 2, characterized in that it comprises, when a modified version of an item is rejected, the creation of two branches containing two alternative versions of the object, namely the modified version and the non changed.
4. A method according to claim 3, characterized in that the assembly step of a resource including a certain version of the object in question is effected by indicating the existence of a version or alternative versions of said object.
5. A method according to claim 4, characterized in that it further comprises a step of selecting, by a user accessing a version of the resource, in some alternative version of the object.
6. A method according to claim 5, characterized in that more elaborate versions of the objects are formed independently for different alternative objects in each of the branches.
7. A method according to one of claims 3 to 6, characterized in that it further comprises the implementation of means for calculating saliency scores of the various alternative versions of the objects for selectively presenting the most relevant versions.
8. A method according to claim 2, characterized in that multiple versions of a resource may be generated by users, and in that in the assembly step, default proposed version of the object according to the version of the resource.
9. The method of claim 1, characterized in that there is provided a step of inhibiting the use of an object in the assembly of a resource if a given condition for that object or to another object resource assembling is not met.
10. The method of claim 9, characterized in that the content of an object whose use may be inhibited is encrypted, and in that the inhibiting step comprises the inaccessibility to a decryption key.
11. The method of claim 9 corseted in that the given condition is a condition of presence of at least one object to another resource.
12. The method of claim 9 or 10, characterized in that the given condition is a non-changing condition of the object present.
13. The method of claim 1, characterized in that it is implemented in a computing environment comprising:
- at least one content server adapted to provide content items can be assembled to form resources,
- a collaborative manager capable of managing versions of resources and the versions of the objects they contain,
- at at least one user station, an extension (plug-in) of a tool for handling objects and resources capable of communicating with the working manager, and in that it comprises a step of verification of the authenticity of the extension of the cooperation manager.
14. The method of claim 1, characterized in that the information of degree of elaboration is adapted to take one of two values, namely "most developed" or not.
15. The method of claim 14, characterized in that the identifying step comprises searching for objects (OR; OA) whose degree of elaboration has the value "most developed" among the downstream objects successively modified from the object in question from the accessed resource.
16. The method of claim 1, characterized in that the identifying step comprises searching for objects of higher degree of development at a boundary among the objects downstream successively changed from the object in question of the resource accessed.
17. A method according to one of claims 1 to 16, characterized in that the search includes search level of objects (s) of the preparation (s) higher (s) by browsing through the upstream objects by changing which the object in question was obtained.
18. A method according to one of claims 1 to 17, characterized in that, in the case where the identifying step has identified several more elaborate objects there is provided in the assembly step of objects an addition sub-step to the resource of information indicating the existence of such multiple objects (OA).
19. The method of claim 18, characterized in that the selected object to the assembly in the resource is more elaborate closest downstream object in succession.
20. The method of claim 18 or 19, characterized in that in response to object change instructions received from the user, the assembly step is adapted to be used successively for the assembly of the objects developed sorted by another criterion such as a notation.
21. A method according to one of claims 18 to 20, characterized in that it is adapted, in response to a selection instruction by a user, to be used for assembling an object designated by said instruction.
22. Process according to \ claim in combination, characterized in that it further comprises a step of scoring the adjustment of the object in accordance with a selection instruction of this object by the user.
23. The method of claim 18 or 19, characterized in that the assembly step is adapted to use for assembling a selected object according to another criterion such as a rating among all the more sophisticated objects.
24. A method according to one of claims 1 to 23, characterized in that it is implemented in combination with a pre-existing content server with time management means of versions of objects and in that the step of identification of the most elaborate version of an object is implemented in versions from information provided by said time management means and a user input information accessing the resource to different versions, and in further comprising a step of presenting the current version of the object in the content server.
25. A method implemented in combination with storage means accessible in a computer environment to maintain updated graphs of objects that may be assembled to form resources available in the environment, characterized in that the storage means are able to store in association with these objects information of degree of elaboration, in that the method comprises the following steps:
- detecting the change of an object by a user,
- identify resource owners containing the corresponding objects in the upstream - towards these owners a proposal for acceptance or rejection of the amendment,
- waiting for a response of the owners,
- based on the contents of at least the first response, adjust the information of degree of elaboration of the objects.
26. The method of claim 25, characterized in that the information of degree of elaboration is adapted to take one of two values, namely "most developed" or not.
27. A method according to one of claims 25 and 26, characterized in that it further comprises a step of, in response to detecting the change of an object, to temporarily adjust the information of degree of elaboration of objects, this adjustment can be upset or confirmed after at least the first response from the owners.
28. A method according to one of claims 25 to 27, characterized in that, during a first acceptance response from owner, applying the change in the resource of said owner.
29. A method according to one of claims 25 to 28, characterized in that, during a response refusal of an owner, then the adjusting step provides the object immediately upstream of the modified object a highest degree of elaboration.
30. The method of claim 29, characterized in that it further comprises, during a refusal response, to the graph the addition of a branch containing an alternative version of the object formed by the object including modification.
31. The method of claim 29 or 30, characterized in that it further comprises, during a denial response of a change made to an object that is not the most elaborate and in case of incompatibility of modif i least more elaborate object, adding to the graph of a branch containing an alternative version of the object consisting of the object including the modification or containing the incompatible objects and modified objects from them.
32. A method of creating a new resource from an existing resource that was accessed within a computing environment, characterized in that it comprises the following steps:
- detecting the change of an object from the existing resource by a user, - in response to this detection, create a new resource with the same content as the existing resource,
- apply the changes to the object from said another resource that corresponds to the subject of the existing resource for which the change has been detected.
33. The method of claim 32, characterized in that the step of creating a new resource is performed by transclusion from information associated with the existing resource.
34. A method implemented in combination with storage means accessible in a computer environment to maintain updated graphs of objects that may be assembled to form resources available in the environment, characterized in that the storage means are suitable for storing in association with each of the objects information of degree of elaboration, in that the method comprises the following steps: - detecting the modification of an object by a user,
- in response to this detection, create a new resource with the same content as the existing resource,
- apply the changes to the subject of the other resource that is the subject of the existing resource for which the modification was detected, - identify resource owners containing the corresponding objects in the upstream,
- towards these owners a proposal for acceptance or rejection of the amendment,
- waiting for a response of the owners, - based on the contents of at least the first response, adjust the information of degree of elaboration of the objects.
35. A method for propagating information of standard object description between different objects may be assembled to form viewable resources in a user interface within a computing environment, characterized in that each object is associated meta -data description, and in that the method comprises the steps of:
- entry in a propagation mode in the initiative of the user,
- the selection of an object of which is to borrow the description of metadata, - the selection of at least one other object to assign the same description of metadata.
36. The method of claim 35, characterized in that the user interface is adapted to hide to the user description metadata.
37. A method for making available è within a computer environment a resource containing at least one derivative object of another resource, characterized in that it comprises the following steps:
- detect a request from a user to change the subject - in response to the detection result in the computing environment a request from an owner of said another resource to authorize the accessibility of the modified object,
- depending on the response received from the owner, selectively allow or accessibility.
38. The method of claim 37, characterized in that a joint request is generated for a plurality of objects derived from resources belonging to the same owner.
39. IT resource capable of permitting implementation of the method according to claim 37 or 38, comprising a set of objects and accessible through a computing environment, characterized in that in association with at least some of the objects is stored broadcast constraint metadata from the content of the object, to selectively control its modification and / or its accessibility by third parties within the resources derived.
40. Resource according to claim 39, characterized in that the diffusion constraints metadata comprise at least one metadata selected from the group comprising meta-data authorization / prohibition modification, metadata of enabling / disabling of access to third unmodified or modified objects, and metadata contact a decision-making authority.
41. Resource according to claim 39 or 40, characterized in that it is structured as a tree of objects, that in association with at least some nodes of the tree structure, a metadata stress broadcast is stored, and in that a metadata broadcast stress at a node applies to the child nodes of the node.
42. A method for making it available to third parties in a computing environment a resource containing at least one derivative object of another resource, characterized in that at the objects are likely to be associated to stored way in the computing environment, diffusion constraint metadata and the metadata being capable of containing an identification of an owner of an object from which the above object is to be derived, and in that the method comprises the steps following:
- detecting whether an object contained in a resource that a user wants to access is derived from another resource,
- detection of the existence in the IT environment diffusion constraint meta-data of the object in question,
- if so, reading said metadata,
- detection of the existence in those metadata of an identification of a decision-making authority,
- if so, sending said well recognized authority of access authorization request to third parties, and
- in the event that an acceptance of said request is received, provision of resources such third parties.
43. The method of claim 42, characterized in that the availability of the resource is published.
44. The method of claim 42 or 43, characterized in that it comprises the intermediate step, between sending the query and receiving an authorization or a refusal, a preliminary assembly step of the resource with an object formed of a sample of the object that is to be derived.
45. The method of claim 44, characterized in that, when the object is a text object, said extract is prepared in accordance with legal criteria citation right.
46. ​​A method for quantitatively estimating the activity of an object in a computer environment, this environment allowing access to resources performed by assembly of objects, at least some of the objects can be generated by derivation from existing objects and modification of objects and derivatives, characterized in that it comprises the following steps: - identifying the most upstream objects to be derived, so that this identification is propagated to the derived objects thereof,
- counting the numbers of derivations of the most upstream objects and objects that were derived.
47. The method of claim 46, characterized in that it further comprises a counting step grouped consultations of the most upstream and objects which have been derived objects.
48. The method of claim 46 or 47, characterized in that the most upstream objects are advertising purposes.
49. A method according to one of claims 46 to 48, characterized in that the most upstream objects are able to be derived without being changed.
50. The computing environment for implementing a method according to one of claims 1 to 38 or 42 to 49, characterized in that it comprises a plurality of servers connected in mesh, adapted to contain branch information between objects and labeling degrees of development, each server being adapted to receive a request for indicating identifiers of objects on the basis of said information, and being adapted to redirect such request to another server in the case where n ' is not responsive to said request.
51. A method for managing variable content resources in an IT environment, each resource comprising a set of objects and at least some of these objects are presented in a resource at an object transcluded individually or as part of an object transcluded greater from a source object, via the appropriate one or more intermediate transcluded objects, such that a change in the source object can propagate to said transcluded object, the method being characterized:
- in that the computing environment is adapted to store information transclusion based on object identifiers, information from which source objects are able to be presented in transcluded objects, and
- in that the method comprises the step of, when the modification of an object, to generate or update, for each object transcluded from said object, a source object identifier to be taken into account for this transcluded object, based on distance information between the modified object and said object transcluded.
52. A method for managing variable content resources in an IT environment, each resource comprising a set of objects and at least some of these objects are presented in a resource object transcluded individually or as part of a larger object transcluded from a source object, via the appropriate one or more intermediate transcluded objects, such that a change in the source object can propagate up to said object transcluded, the method being characterized: - in that the computing environment is adapted to store information transclusion based on object identifiers, information from which source objects are able to be presented in transcluded objects, and
- in that the method comprises the step of, during the presentation of an object, determining, for each object transcluded from said object, a source object identifier to be considered for this object transcluded, depending a distance information between the modified object and said transcluded object.
53. The method of claim 51, characterized in that said step, when the modification of an object, identifies the object as its own source with zero distance.
54. A method according to one of claims 51 to 53, characterized in that the resources include tree structures of objects, and in that it further comprises a step of, for a transclusion of an object including object descendants of which is transcluded from each other, to define for the transclusion between descendant objects of the object including transcluded, a distance value between the shortest objects.
55. A method according to one of claims 51 to 54, characterized in that said changes may relate to different attributes of said objects, and in that the step of generating or source object update is performed separately for each attributes, so an object that can have different source objects according to the considered attribute.
56. The method of claim 55, characterized in that the different attributes comprise at least two attributes among attributes of the content, meta-data, and position processing.
57. A method for managing variable content resources in an IT environment, each resource comprising a set of objects and at least some of these objects are presented in a resource at an object transcluded individually or as part of an object transcluded greater from a source object, via the appropriate one or more intermediate transcluded objects, such that a change in the source object can propagate to said transcluded object, characterized in that comprises, according to the frequency of changes to objects and presentation objects, the implementation or the method according to claim 51 or the method according to claim 52.
58. A method according to claim 57, characterized in that the selection of the method according to Claim 46 is automatically selected when the environment of the source object is not adapted to generate said source object identifier.
59. The method of claim 57 or 58, characterized in that the selection of the implemented method is performed transclusion by transclusion.
60. A method according to one of claims 51 to 59, characterized in that it is implemented in centralized server means capable of providing the object identifiers of sources.
61. A method according to one of claims 51 to 59, characterized in that it is implemented in a cascade of processing means capable of providing the object identifiers sources close path in close as transclusions.
62. A method according to one of claims 51 to 61, characterized in that at least some transclusions are associated with the object processing information, the information designating each of a predetermined transform function to apply to the object as initial transclusion a step.
63. The method of claim 62, characterized in that a transformation is adapted to be applied to object attributes such as content attributes, position, meta data and transformations concerning internal transclusions objects .
64. A method according to one of claims 51 to 63, characterized in that resources are spreadsheets and in that the objects are cells or groups of cells of the leaf.
65. The method of claim 64, characterized in that the formulas associated with the cells of a group of cells are considered transcluded internal transclusions group.
66. A method according to claim 65, characterized in that obtaining an internal transclusion in a group of cells transcluded comprises applying to the spreadsheet program instructions to copy / paste from an inner transcluding data in the source cell group.
67. A method for managing a set of information objects in a computer environment, certain objects being container objects may contain other objects, and the computing environment comprising a first structure object and a second structure transcluse objects from the first, characterized in that:
- at least some objects of the first structure have properties;
- at least some tubs of the second structure have constraints, and in that the method comprises the step of, when transclusion operation of the first structure to the first structure, to present the objects of the first structure in container objects of the second structure according to the adequacy of object properties of the first structure with the constraints of the second structure objects containers.
68. The method of claim 67, characterized in that it further comprises the step of, when change in a property of an object of the first structure, to verify the appropriateness of the changed property with constraints objects the second structure of containers and moving the appropriate corresponding object presented in the second structure.
69. The method of claim 67 or 68, characterized in that it further comprises the step of, upon modifying a constraint of a container object of the second structure, to check the suitability of the properties of objects presented in this container object to the modified strain of it, and move it if necessary or considered objects.
70. A method for modifying the contents consist of marked data stream which are accessed according to a syndication protocol, each content being accessible as a channel that includes plural items of information each having a unique identifier, characterized in that it comprises the steps of: - delineating an information element ine part of an element to change,
- application of the modification to the information element or the element portion,
- development of a content containing one hand the piece of information or some element of change defined by specific tags, and also the original of information delimited by its original tags so as to avoid loss of information when the stream is treated according to a protocol that does not support said specific tags.
71. The method of claim 70, characterized in that the modified information element or part element has an associated information indicating whether it replaces the information or part of original equipment or element if there is an alternative to the information or part of original item element, and in that it comprises in this case a step of signaling the existence of the alternative.
72. Method according to one of claims 70 and 71, characterized in that it further comprises a step of, in response to the modification of a piece of information or part of element, this signal modification to a server where data streaming from.
73. A method according to one of claims 1 to 38, 42 to 49 and from 51 to 72, characterized in that the resources are marked data stream which are accessed according to a syndication protocol, and in that the objects of said resources are pieces of information resources or said portions of said information elements.
74. A method for transforming a first resource comprising a tree structure of objects in 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 processor under a certain object including at least one descendant item, and a second transformation on said downward object, the second processing is primarily executed in the first transformation.
75. A method for access by a user of the object information generated by a collaborative system where different user groups can contribute to forming respectively different versions of objects from common starting objects, characterized in that the user is likely to belong to different groups simultaneously, and in that it comprises the steps of:
- as a function of an identifier of one of the groups with which the user performs access, present the corresponding versions of the objects from the input objects,
- based on a contributory access mode information / non-contributory by the user, taking into account or not in the collaborative system at group level considered subsequent amending user actions on the versions of objects that it accessed.
76. The method of claim 75, characterized in that, in non-contributory access mode when accessing in a given group, the Modifier actions can be taken into account by default in other groups.
77. A process for access by users to items of information generated by a collaborative system where different users can contribute to form respectively different versions of objects, and where users can selectively accept or reject versions, wherein it includes contributions accounting means users and ace by other users of versions of objects containing these contributions.
- based on a contributory access mode information / non-contributory by the user, taking into account or not in the collaborative system at group level considered subsequent amending user actions on the versions of objects that it accessed.
78. A method for making available to a group of users in a computer environment a resource containing a plurality of objects may be modified by users to obtain different versions of said objects, characterized in that it comprises:
- at least some of the objects, assign to different versions of the objects encryption keys / decryption different,
- provide versions of said objects encrypted with respective keys - when accessing the resource by a user, perform the decryption of encrypted versions of objects belonging to the resource using the respective decryption keys,
- When changing a particular object by a user, create a new version of the object, when a new key is assigned.
79. The method of claim 78, characterized in that it comprises a step of selectively providing key decryption of the objects to users as a function of enabling said user information.
80. A method according to claim 79, characterized in that the clearances are processed by groups of users, two users of the same group having the same rights.
81. Method according to one of claims 78 to 80 characterized in that the versions of an object are formed by successive updates of said object at endpoints of the computing environment, and in that the step of creating a new key when creating a new version of the object is performed at the client terminal, a subsequent step of transmitting the new key to a key server being provided.
82. Method according to one of claims 78-81, characterized in that the versions of an object are formed by different content versions of said object, coexisting simultaneously, reserved for different user groups, and in that a communication of such an object by a user of a first group to a user of a second group comprises:
- providing the user with the second group, by any appropriate channel, multi versions of an object containing the contents of the object reserved for the second group, the encrypted state, and - the independent supply by a server keys, with the second group of user, a decryption key for decrypting said content item reserved in the second group.
83. The method of claim 82, characterized in that it comprises a step of cutting the multi-version object into homogeneous parts of the point of view of access rights, each part containing positioning information allowing its replacement in the structure, such that manipulations can be performed on the multi-versions object even in the absence of access to all of its versions.
84. A method for making it available to different groups of users (ERC) in a computer environment a resource containing a plurality of objects may be modified by users to obtain different versions of said objects, characterized in that each object is likely to exi erent versions corresponding to different user groups and descendants of a multi-versions object the encompassing, and in that it comprises, during access by a user to an object, the presentation thereto versions of the object corresponding to the groups to which it belongs, each object version being obtained by transformation from a different version of said object.
85. The method of claim 84, characterized in that it is implemented using a method of managing of claim 62, specific predetermined processing for obtaining each of the versions of the object.
86. The method of claim 85, characterized in that a transclusion action by an item user belonging to a multi-object causes a transclusion versions of the entire multi-object versions.
87. Method according to one of claims 84-86, characterized in that 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 at access to the object by users of the group.
88. A method according to claim 87, characterized in that it further comprises the implementation of means for calculating saliency scores different versions corresponding to different groups and / or different users to selectively present the most relevant versions .
EP06725740A 2005-04-12 2006-04-12 Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefor Withdrawn EP1920358A2 (en)

Priority Applications (5)

Application Number Priority Date Filing Date Title
FR0503612 2005-04-12
FR0507016 2005-07-01
FR0509001 2005-09-02
FR0600213 2006-01-10
PCT/EP2006/061567 WO2006108865A2 (en) 2005-04-12 2006-04-12 Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefor

Publications (1)

Publication Number Publication Date
EP1920358A2 true EP1920358A2 (en) 2008-05-14

Family

ID=36587242

Family Applications (1)

Application Number Title Priority Date Filing Date
EP06725740A Withdrawn EP1920358A2 (en) 2005-04-12 2006-04-12 Methods for granting access to resources modifiable by users in a computer environment, and resources structured therefor

Country Status (3)

Country Link
US (2) US8442996B2 (en)
EP (1) EP1920358A2 (en)
WO (1) WO2006108865A2 (en)

Families Citing this family (39)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8370423B2 (en) 2006-06-16 2013-02-05 Microsoft Corporation Data synchronization and sharing relationships
US20080005472A1 (en) * 2006-06-30 2008-01-03 Microsoft Corporation Running applications from removable media
US8266131B2 (en) * 2006-07-25 2012-09-11 Pankaj Jain Method and a system for searching information using information device
US8869020B2 (en) * 2006-12-27 2014-10-21 Sap Ag Method and system for generating relational spreadsheets
US8930331B2 (en) 2007-02-21 2015-01-06 Palantir Technologies Providing unique views of data based on changes or rules
US7900203B2 (en) * 2007-04-24 2011-03-01 Microsoft Corporation Data sharing and synchronization with relay endpoint and sync data element
CA2720897C (en) 2008-04-28 2015-06-30 Salesforce.Com, Inc. Object-oriented system for creating and managing websites and their content
US8429194B2 (en) 2008-09-15 2013-04-23 Palantir Technologies, Inc. Document-based workflows
US20100088270A1 (en) * 2008-10-03 2010-04-08 Carsten Ziegler Data versioning concept including time dependency and active and inactive states
US8260823B2 (en) * 2008-10-09 2012-09-04 International Business Machines Corporation Dissemination, acquisition, discovery and use of people-oriented folksonomies
AU2010202782B1 (en) * 2010-07-01 2010-11-25 Brightcove Inc. Cloud data persistence engine
US8412718B1 (en) * 2010-09-20 2013-04-02 Amazon Technologies, Inc. System and method for determining originality of data content
US8935360B2 (en) * 2010-12-03 2015-01-13 Salesforce.Com, Inc. Techniques for metadata-driven dynamic content serving
US9141983B2 (en) 2011-02-01 2015-09-22 Salesforce.Com, Inc. Shared data sets combined with user-specific purchased data sets
US9275082B2 (en) 2011-02-01 2016-03-01 Salesforce.Com, Inc. User-extensible common schema in a shared database
US20130138668A1 (en) * 2011-02-01 2013-05-30 Salesforce.Com, Inc. Shared data set with user-specific changes
US8407203B2 (en) * 2011-05-02 2013-03-26 Elsevier Inc. Computer system for enhanced taxonomy management
AU2012327168B2 (en) * 2011-11-18 2013-10-24 Evado Holdings Pty Ltd Amethod and structure for managing multiple electronic forms and their records using a static database
US9766906B2 (en) * 2011-12-29 2017-09-19 International Business Machines Corporation Efficient sharing of artifacts between collaboration applications
WO2013102506A2 (en) * 2012-01-02 2013-07-11 International Business Machines Corporation Method and system for backup and recovery
US9628438B2 (en) * 2012-04-06 2017-04-18 Exablox Consistent ring namespaces facilitating data storage and organization in network infrastructures
US8504519B1 (en) 2012-06-27 2013-08-06 Dropbox, Inc. Determining a preferred modified version from among multiple modified versions for synchronized files
EP2939104A4 (en) * 2012-12-28 2016-09-07 Xsb Inc Systems and methods for creating, editing, storing and retrieving knowledge contained in specification documents
US9552382B2 (en) 2013-04-23 2017-01-24 Exablox Corporation Reference counter integrity checking
RU2580468C9 (en) * 2013-04-24 2017-03-24 Общество С Ограниченной Ответственностью "Э-Студио" Method of controlling access to multiple computer resources
EP3008647A4 (en) 2013-06-12 2017-01-25 Exablox Corporation Hybrid garbage collection
WO2014205286A1 (en) 2013-06-19 2014-12-24 Exablox Corporation Data scrubbing in cluster-based storage systems
US9934242B2 (en) 2013-07-10 2018-04-03 Exablox Corporation Replication of data between mirrored data sites
US10248556B2 (en) 2013-10-16 2019-04-02 Exablox Corporation Forward-only paged data storage management where virtual cursor moves in only one direction from header of a session to data field of the session
US20150143103A1 (en) * 2013-11-18 2015-05-21 Life of Two Messaging and networking keepsakes
US9985829B2 (en) 2013-12-12 2018-05-29 Exablox Corporation Management and provisioning of cloud connected devices
US9774582B2 (en) 2014-02-03 2017-09-26 Exablox Corporation Private cloud connected device cluster architecture
JP2017504924A (en) 2014-02-04 2017-02-09 エグザブロックス・コーポレーション Content-based organization of the file system
US9720991B2 (en) * 2014-03-04 2017-08-01 Microsoft Technology Licensing, Llc Seamless data migration across databases
US9417869B2 (en) 2014-11-10 2016-08-16 International Business Machines Corporation Visualizing a congruency of versions of an application across phases of a release pipeline
US9736169B2 (en) 2015-07-02 2017-08-15 International Business Machines Corporation Managing user authentication in association with application access
US10175955B2 (en) * 2016-01-13 2019-01-08 Hamilton Sundstrand Space Systems International, Inc. Spreadsheet tool manager for collaborative modeling
US9846553B2 (en) 2016-05-04 2017-12-19 Exablox Corporation Organization and management of key-value stores
US10263877B1 (en) * 2016-08-12 2019-04-16 Pinterest, Inc. Generating collections of sets based on user provided annotations

Family Cites Families (20)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5295256A (en) * 1990-12-14 1994-03-15 Racal-Datacom, Inc. Automatic storage of persistent objects in a relational schema
US5878427A (en) * 1995-05-31 1999-03-02 Texas Instruments Incorporated Method and system for assembling complex objects
US5920867A (en) * 1996-12-06 1999-07-06 International Business Machines Corporation Data management system having data management configuration
US6230159B1 (en) * 1997-04-30 2001-05-08 Microsoft Corporation Method for creating object inheritance
US6202066B1 (en) * 1997-11-19 2001-03-13 The United States Of America As Represented By The Secretary Of Commerce Implementation of role/group permission association using object access type
US7383228B2 (en) * 1998-08-13 2008-06-03 International Business Machines Corporation Method and system for preventing unauthorized rerecording of multimedia content
US6631497B1 (en) * 1999-07-19 2003-10-07 International Business Machines Corporation Binding data from data source to cells in a spreadsheet
FR2806184A1 (en) 1999-11-10 2001-09-14 Enrico Maim Navigation in an information system to access pages provided by servers in a computer network, uses storage of link information to allow inverse linking
WO2001095146A2 (en) 2000-06-06 2001-12-13 Maim Enrico System for semi-automatic import of fragments of information resources
JP2002024211A (en) * 2000-06-30 2002-01-25 Hitachi Ltd Method and system for document management and storage medium having processing program stored thereon
US7178098B2 (en) * 2000-07-13 2007-02-13 International Business Machines Corporation Method and system in an electronic spreadsheet for handling user-defined options in a copy/cut—paste operation
US7299502B2 (en) * 2001-02-14 2007-11-20 Hewlett-Packard Development Company, L.P. System and method for providing customized secure access to shared documents
GB2378539B (en) * 2001-09-05 2003-07-02 Data Encryption Systems Ltd Apparatus for and method of controlling propagation of decryption keys
US7380120B1 (en) * 2001-12-12 2008-05-27 Guardian Data Storage, Llc Secured data format for access control
US7130874B2 (en) * 2002-03-12 2006-10-31 International Business Machines Corporation Method, system, and program for maintaining data in a distributed computing environment for processing transaction requests
US20040194027A1 (en) * 2002-12-27 2004-09-30 Akira Suzuki Computerized electronic document producing, editing and accessing system for maintaining high-security
US8627489B2 (en) * 2003-10-31 2014-01-07 Adobe Systems Incorporated Distributed document version control
US7596585B2 (en) * 2004-11-03 2009-09-29 Honeywell International Inc. Object replication using information quality of service
US20070150299A1 (en) * 2005-12-22 2007-06-28 Flory Clive F Method, system, and apparatus for the management of the electronic files
US20120185759A1 (en) * 2011-01-13 2012-07-19 Helen Balinsky System and method for collaboratively editing a composite document

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See references of WO2006108865A2 *

Also Published As

Publication number Publication date
US8442996B2 (en) 2013-05-14
WO2006108865A2 (en) 2006-10-19
WO2006108865A9 (en) 2008-07-03
US20110106795A1 (en) 2011-05-05
WO2006108865A3 (en) 2007-06-28
US20140143857A1 (en) 2014-05-22
US9076015B2 (en) 2015-07-07

Similar Documents

Publication Publication Date Title
Ahn et al. Utilizing knowledge context in virtual collaborative work
Bentley et al. The World Wide Web as enabling technology for CSCW: The case of BSCW
Dieberger et al. Social navigation: Techniques for building more usable systems
US8103691B2 (en) System and method for dynamically generating a survey result(s) and utilizing survey data for customization, personalization and configuration of human operating system (HOS)
US8453052B1 (en) Real-time document sharing and editing
US8073811B2 (en) Online content collaboration model
US8756221B2 (en) Social files
US7860852B2 (en) Systems and apparatuses for seamless integration of user, contextual, and socially aware search utilizing layered approach
US7930316B2 (en) Method, system, and computer program product for dynamic field-level access control in shared documents
Groth et al. An architecture for provenance systems
De Bra et al. The next big thing: Adaptive web-based systems
US8495099B2 (en) Method of manipulating information objects and of accessing such objects in a computer environment
US6804674B2 (en) Scalable Content management system and method of using the same
Bosak XML, Java, and the future of the Web
US20090106234A1 (en) Apparatus and methods for web marketing tools and digital archives - web portal advertising arts
US20070081197A1 (en) System and method for semantic knowledge retrieval, management, capture, sharing, discovery, delivery and presentation
US8612380B2 (en) Web-based collaboration for editing electronic documents
CA2406713C (en) Method and apparatus for relaying session information from a portal server
US20150006582A1 (en) Method and apparatus for collecting and disseminating information over a computer network
US6591278B1 (en) Project data management system and method
CA2528583C (en) An automated publishing system that facilitates collaborative editing and accountability through virtual document architecture
US20080250333A1 (en) Collaborative workspace
US20070100829A1 (en) Content manager system and method
US8464164B2 (en) System and method to create a collaborative web-based multimedia contextual dialogue
US20150163206A1 (en) Customizable secure data exchange environment

Legal Events

Date Code Title Description
17P Request for examination filed

Effective date: 20080228

AK Designated contracting states

Kind code of ref document: A2

Designated state(s): AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HU IE IS IT LI LT LU LV MC NL PL PT RO SE SI SK TR

DAX Request for extension of the european patent (to any country) (deleted)
R17P Request for examination filed (corrected)

Effective date: 20080228

17Q First examination report despatched

Effective date: 20120120

18D Application deemed to be withdrawn

Effective date: 20151103