GB2469452A - Apparatus and method for transporting and manipulating data content - Google Patents

Abstract

A method of transporting data content between locations, such as websites, comprising: selecting at least one of a plurality of tagged data content entities at a first location; storing the content corresponding to the data content entity at a data storage location; and upon applying the tag at a second location, accessing the data from the data storage location and applying it at the second location.

Description

APPARATUS AND METHOD FOR TRANSPORT[NG AND

MANIPULATING DATA CONTENT

The invention relates to an apparatus and method for transporting and manipulating data content.

A problem with data content for example on the Internet is that locating and tracking content of interest, and sharing content can be problematic.

Known approaches include iGoogle which is a method of personalising a web page and including modules on a web page. The modules are essentially web applications that can be placed onto the page and shared among other users.

The concept is that the system holds a central repository of applications that can then be accessed by users. Google have also developed methods of programming web applications so that they can be shared (open social) and provide programmers with a platform for Ajax based applications (GWT -.

Google web toolkit). However such a system effectively simply provides a portal to the content requiring additional functionality.

A further known system is the Microsoft "webclip", concept whereby, for example, calendar items can be tagged and shifted between different applications.

The problem with known systems is that content is not provided in a fully removable, editable and sharable manner.

The invention is as set out in the claims.

Embodiments of the invention will now be described, by way of example, with reference to the drawings of which: Fig 1 is a flow diagram illustrating a content transportation ("GrabMe") process; Fig 2 is an architectural diagram illustrating a system on which the content transportation process can be implemented; Fig 3 is a flow diagram illustrating a content manipulation ("Creative Desk") process; Fig 4 is an architectural diagram illustrating a system on which the content manipulation process can be implemented; Fig 5 is a screen shot illustrating a content manipulation process step; Fig 6 is a screen shot illustrating a further content transportation process step; Fig 7 is a screen shot illustrating a further content transport process step; Fig 8 is a diagram illustrating a further aspect of the process; Fig 9 is a diagram illustrating data flow in a further aspect of the process.

In overview, according to a first aspect a content transportation (referred to herein as to the ("GrabMe") process is described in which webpage content are divided into segments called chunks or entities which are referred to as Grabs herein.

Referring to the flow diagram of Fig 1, at step 100, content entities are identified. This could be, for example, a document, an image, an application such as a game, an HTML segment or a gallery or collection of items; in fact any data on the web page can constitute an entity as discussed in more detail below.

At step 102 a "GrabMe" tag or icon is applied to the chunk of data. This is a visible icon on the item which can be clicked on at step 104 to "Grab" the contents of the unit of data and add it to the "Grab tray" or clipboard at step 106. This allows the user to import or manage or share the entity using a single click interface. At step 108 the user can hover the cursor over an icon in the tray to show the associated entity. At step 110 when the user moves to another web page such as a social network site or any other manipulable webpage, the tray remains displayed and the user can click on the respective icon to deposit it on that page.

Referring to Fig 2 the architecture of the system is shown in overview including a user computer 200 connected via an appropriate link to update a network such as the Internet 202 which can have associated with it a database or data repository 204. When a user accesses web content from the Internet and views it on the computer 200 it is possible to grab content entities using the icon which is then displayed in the icon tray. The content is also stored, for example, at the remote data base 204. Then when the user accesses another page, simply by clicking on the relevant GrabMe icon, the content can be accessed from the remote database 204 and uploaded into the existing webpage. As a result the system provides a manner of searching, organising and transporting data and providing a customised webpage where the full grabbed content is stored and accessed ensuring that the content itself remains unchanged in contrast, for example, to capturing links which are dependent upon the website data to which they link. Yet further user profiles can be customised to create a "feed" so that GrabMe content entities meeting the user profile can be automatically forwarded to the user based on the user profile.

According to a further aspect of the invention which can be used in conjunction with or independently of the content transport process described above, a content manipulation process (referred to herein as "Creative Desk") is provided. Content manipulation as described below can be implemented in relation to content entities obtained using the content transport process as described above or content obtained in any other appropriate manner.

In one basic embodiment described with reference to Fig 3, users can download at their respective stations common content such as a common image from the Internet and at step 302 the users can upload the content to a common site such as a website. The documents can be grouped in any appropriate manner for example on a "filmstrip" as shown in the screenshot of Fig 5. As can be seen, multiple user workstations 500 show three versions of the same image. At step 304 the various versions are named and shown as can be seen once again in Fig 5 and it is noted in that in more complex arrangements different users can upload different content to a common filmstrip. As discussed in more detail below the system further allows a sophisticated versioning process such that changes by different users to common content can be tracked.

Referring to Fig 4 the architectural systems supporting the content manipulation approach can be seen in more detail. In particular multiple user workstations 400 are connected via a network such as the Internet 402 to a remote server computer 404 (although any computer including one of the user computers can host the application). The users download the content from the Internet (arrows 406) and then upload the identifiable and manipulable content 408 via the Internet 402 to the host 404.

Turning now in more detail firstly to the content transport or "GrabMe" process, the interaction between the user and entity (data item) and the manner in which entities can be grouped using hierarchies and in which permissions can be added to entities or groups of entities can be further understood.

Overview The system is designed for large numbers of users and a large number of entities which these users may be authorized to perform actions upon.

Therefore the system must have provision for complex relationships to be formed between users, items of data and permission of actions.

Basic concepts It is first necessary to strictly define the components of the system and the security model imposed upon them. This model is define below as a comparatively formal discrete mathematical model to ensure consistency and clarity.

We will refer to items in the system as "entities". An entity may be anything, from a data item such as a photograph or video, an individual user themselves, or a collection of other entities.

The system itself may be thought of as an entity, which contains all other entities. Therefore the system can be thought of as J a set containing all existent entities, including.

Entities have a distinct set of actions which any individual user could possibly perform on them (e.g. delete, modify), and this list of actions will depend upon an entity's type. For example if an entitiy is a collection of other entities (e.g. a photo album which contains photos), then it will have the additional actions of add, remove, rename album etc. A permission can be thought of as a triple (e, A, L) where "e" represents the entity which is the subject of the permission and "A" represents the set of actions which are allowed upon the entity e. "L" represents the "lease" for this permission. This is a period of time for which the permission is valid. The permission may be perpetual, in which case L contains all the times from 0 to infinity, otherwise L is constrained to some subset of all times.

A role is a set of permissions.

A role and a permission are themselves entities. This is to retain consistency in our data model.

A user is also an entity, which may be represented as a pair (D, R). D is an entity containing the details relating to the user (e.g. user name and other details), R is a set of the roles which are associated with this user.

If a user u has a role r in it's set of roles, when that user may perform any actions on any data items defined in the permissions of r, provided only that the current time t is within L, the lease for that permission.

The leasing of data is a key concept within the system which will be referred to later in this document.

While roles are not strictly necessary in a simple system with few data items, in a system of the complexity proposed, they represent an invaluable way of grouping users and permissions.

Practical considerations When employing such a model in a practical system, it is generally easier to express permissions as a list of access controls upon an entity itself-a so called "Access control list" or ACL.

Each entity has an ACL associated with it. This simply lists each role which can perform actions on the entity, and which actions they can perform, and any leases associated with those actions. Therefore an ACL is a set of triples (r, A, L) where r is a role, A is a set of actions and L is a lease.

It is also common practice to create the roles "any" which every user has in their set of roles, and a role specific to the user, e.g. for a user "phil" create a role "phil.self'. This is useful when expressing permissions that apply to a single user only.

The ACL for any entity itself will always contain the role "administrator" -and this role will be allowed to perform any relevant actions on the item. Any systems admin will have this role in their set of roles. Thus any user with the "administrator" role will have permissions to do any action on any data item within the system.

Hierarchical items When the number of entities becomes large, it will make sense to construct entities which are groups of other entities (e.g. a user group, a photo album, a desktop etc.). When permissions are changed on these groups of items, a choice needs to be taken as to whether the permissions are propagated to all items within the group. For example we could add the permission to the role "any" to view a photo album, which would allow all users to view the list of contents of that album, but without the view permission on each item in the album, any user would not be able to view the contents. In terms of ACLs, we would have changed the ACL of the album, but not any of the contents.

In examples where we want to group permissions of entities, it may make sense for the entities themselves to inherit their ACLs (and therefore the permissions) from their containing entities. The child entities only need break this pattern if the a user explicitly sets different permissions for a child item.

When storing ACLs in a practical system this will result in a significant reduction in the quantity of storage required.

The manner in which the content transport process is operated will now be described in more detail.

In GrabMe all data is organised into blocks -these blocks could be thought of as a Dlv' in html or an)(ML entity. GrabMe uses DIVs in order to identify entities only because this reflects the way in which a web page is currently put together.

The premise on which GrabMe is built is that all data is tagged in a coherent way and all data is moveable to and from the user's home page which they construct themselves.

It is best visualised as a series of steps or stages.

There are two ways by which data can be grabbed each will be examined in depth below: A. When the user clicks the icon it disappears, and is moved either to an icon tray at the top of the page, the user then navigates to the page on his/her own site and lays out the data by clicking the icons in the target page; B. The user selects a target symbol in the page to hold the data, and then the user browses the web clicking on required data. The data is moved instantly to the required position.

Method A 1. The user selects the block of data they want to move onto their web page by clicking a distinctive icon.

2. The icon then disappears from the grab, to visually cue the idea that the data is grabbed.

3. The grabbed data is copied into the grab tray which is a place where grabs can be collected and viewed and is located at the top of a page on a GrabMe enabled site.

4. The user navigates to the page into which the grab is to be deposited.

A page on which the user has write access.

5. Using the grab tray the user clicks the grab icon of the data they wish to deposit.

6. The data is copied into the target page 7. The icon is removed from the grab tray Method B The second method has fewer stages and is therefore easier and more useful when large amounts of data need to be grabbed quickly.

1. The user selects the target icon in the destination page -to tell the system to move all new grabs to this page.

2. The user clicks on the grabs they wish acquire.

3. The data is immediately copied to the destination page.

GrabMe provides a method for moving and sharing data that replaces large collections of static data with identifiable and tagged data that can easily be moved to the correct community.

This represents a modal shift in the way web sites work, by providing a method by which users can be given far greater control over the data they access on the web.

Method A and method B are examined in more depth below.

What is a grab? This section looks at the exact composition of a grab and then goes on to examine Method A and Method B in more depth.

A grab is a piece of copyable HTML it two parts Part a) HTML wrapper Part b) Module content One way of looking at GrabMe is to regard the content by its weight in terms of data density.

A grab is more than a subdivision of a page; it is a discrete bit of moveable content. Another way of looking at a grab is a reverse hyperlink; the content is brought to you from a remote server rather than you going to it.

The surrounding HTML is light and therefore small in size The module -for example an image or a document is heavy and tending to be larger in size.

When the grab is captured or "grabbed" the light content is copied, but the heavier modular content is passed by reference.

If a user creates a new version of the modular content and uploads it, a new version of the module is created in effect a new module. The system has two ways of dealing with the update of modular content: a) The user can update an existing module which has the effect of creating a new version of the module.

b) The users can create a new grab and attach the amended data to that.

Versioning is described in more detail below, but if versioning is involved then garbage collection takes place in the following scenario.

If all the users of version a) of the module delete their copies and upgrade to version b) then version a) can be garbage collected.

Core GrabMe technology -Methods A and B GrabMe regards every element of every web page as being independent and moveable. Each part is tagged with a simple colour coded icon.

Method A -use of GrabMe tray Stage 1: The user selects the block of data they want to move onto their web page by clicking a distinctive icon.

The Figures 6 and 7 illustrate the first of these GrabMe methods: The page is laid out in a grid each element of the grid contains a GrabMe icon and potentially the wrapping element also contains a GrabMe icon.

There are two scenarios: I. The page is laid out entirely in Grabs 2. The page is made up of containers or filmstrips as shown.

In order for a user to grab some data they must first select the data to be grabbed from the possible grabs on the page. Visual data always contains a thumbnail of the actual graphic held in the grab. Document data contains a description of the encapsulated document. Each grab has a distinctive border making it obvious what is to be grabbed.

Clicking on the Grab Icon submits the GrabID to the system, this ID is then inserted into the clipboard table and an icon is shown in the system clipboard.

Stage 2: The icon then disappears from the grab, to visually cue the idea that the data is grabbed.

The word disappear' indicates that the Grab Icon is no longer visible in the grab on the page corresponding to the one held on the clipboard. This can be implemented by a number of different methods but in all likelihood the code for the grab icon remains unchanged but the display attribute of the element (DIV) is changed from block' to none' within the system stylesheet.

As each page is navigated the system compares the IDs of the grabs held in the system to the ones on the page, if the IDs match then the icon on the grab on the page is not displayed. This means that you can leave a page and navigate elsewhere on the web but when you return to the page in question the icon of the grabbed element will remain hidden.

The grab or icon tray is shown in Figure 7.

Stage 3: The grabbed data is copied into the grab tray which is a place where grabs can be collected and viewed and is located at the top of a page on a GrabMe enabled site.

As mentioned the clipboard simply needs to contain a reference to the Grab using the GrabID. This can then be referenced behind the scenes to the Grab in questioned which can be displayed in a div on mouseover.

By GrabMe enabled we simply mean that the site has been divided into Grabs with distinctive GrablDs and GrabSetlDs. The Set IDs are the only things that need to be controlled from a central server; the grabs can exist independently of each other and without knowledge of each other.

The grab icons can be placed anywhere within the boundaries of the target grab. The icons can contain any symbols to make their purpose clear.

The grab icon always disappears once grabbed in order to flag to the user that the current piece of data has been grabbed.

Stage 4 The user navigates to the page into which the grab is to be deposited. A page on which they have write access.

Generally on a GrabMe system each user will have a specific area or site' into which they can paste grabbed data. For convenience we have named this as the user's home page, but in fact any page can grant a user write access' as access is controlled by a simple ACL method.

If the user drops the Grab into any page owned by a different user the Grab is placed into that users Visual Intray'. The concept of the Visual Intray is explained separately.

Laying out grabbed data In order to lay out data the user navigates back to their own home page and selects the page in which they wish to deposit the data.

Stage S Using the grab tray the user clicks the grab icon of the data they wish to deposit.

Each icon is tagged with its content, so the user can discover which grab is which by hovering the mouse over the icon concerned. The data will be shown as a pop up layer, additionally any key words can be placed in the browser's status bar. When the user clicks the icon concerned the data is deposited sequentially in the current page. This methodology gives the user the ability to select the correct page to place the selected text.

Stage 6 The data is copied into the target page.

When the data is deposited into the users home page' a copy of the original grab is taken. The resulting Grab has a new GrabID and the ParentGrablD of the grab that was copied. This is more fully explained below in the section on the life cycle of a grab. Currently we are copying the data via a select insert statement on a database (explained below).

Stage 7 The icon is removed from the grab tray To remove the icon from the Grab Tray is simply a question of deleting the entry from the clipboard table. Clicking the grab icon and depositing the data causes the item to be deleted and the Grab Tray to be refreshed.

Method B -use of target page The second method of grabbing data is even easier than the first. It is suitable for users who know in advance where particular data will be filed.

For this scenario a target symbol is clicked allocating one page as the recipient of data.

This target icon will then appear in the users grab tray, symbolising that a recipient page has been chosen. The icon can be removed by clicking it and selecting -remove target page.

Once the target page is allocated the user grabs data which then appears instantly in the target page and is placed sequentially.

The advantage of this second method is that it is far quicker than the first, cutting out the organisation stage.

Managing own data Users can also grab their own data and place it or a copy of it in a different location using either method A or method B. Deleting a grab Each piece of GrabMe data also has a cross placed at the top right of the block of data. This allows the user to remove any piece of data from a page and place it in the users recycle bin.

When a grab is deleted from the recycle bin it is permanently destroyed and the GrabID is also removed from the system. Items placed into the recycle bin are auto-deleted after 30 days.

Cutting and pasting grabs If the user is moving data within their own site' the data can be cut' rather than copied. In order to do this the user clicks on a distinctive cut icon to the left of the Grab Tray and then clicks onto grabs, these grabs will then instantly be cut from the source page and be pasted to target page.

How grabbed data is handled Grabbed data is copied between pages, the HTML wrapper is also copied -the advantage of this method is that each user actually possesses a copy which is independent of all other copies, and can be independently changed or recopied. The modular content however is passed by reference.

This method, however, is not suitable for all data. Some data shared within a group needs central control (see discussion about groups below). In these cases there is single copy of the data and all other data is simply a hyperlink to that copy. This data is distinguished by having a specific icon.

All grabbed data is tagged with a data specific string. This ensures that data can be removed from the system should this be necessary. The data is also tagged with the ID of the originator; this ensures that data can always be traced back to its point of origin.

A crude representation of the XML tagging system is given below: <GrabMe> <Grabld>Grab Id</Grabld> <ParentGrabld>Id of parent</ParentGrabld> <GroupSpecific> This identifies data that is only allowed within in one group.

<GrabSetld>Id for the set of data</GrabSetld> <DateTime>Date and time data -hidden</DateTime> <Originator>Id of originator</Originator> <Keywords>Keywords associated with the specific data. These are hidden from the user</Keywords> <Description>A simple description of the data</Description> <Data>The data concerned</data> </GroupSpecific> </GrabMe> Clicking a GrabMe icon triggers a form post -which posts the data to a page or piece of software that takes a copy -the user is then returned to the original page.

This method ensures that GrabMe data can be added to any website with existing technology.

At a database level the grab is copied with an insert select statement some illustrative SQL is set out below: Insert into Grab (PageID, Heading, URL, TemplateName, TemplatePath, HeadingClass, GrabClass, Text, Text2, DocumentlD, ImagelD, SortOrder, DateCreated, DateVisible, FromUserlD,ToUserID) select SPageID,Heading,URL,TemplateName,TemplatePath,HeadingClass,GrabClass Text, Text2,DocumentlD,ImagelD,$ Sort,nowO,now() ,CONSTANTUSERID SToUserID from Grab Where GrabID=$GrabID This is not the only method of propagating grabs but it is the one we are currently using. It is a simple and fast method and reasonably foolproof.

The items marked with a $ sign are variables within the system.

If a user creates a new version of the modular content and uploads it i.e. uploads a new document, a new version of the module is created -in effect a new module. If an existing grab is updated the GrabID of that grab will remain the same but the module id will change, this change will only affect one grab -related grabs are not amended. When a grab is grabbed by a user the system notes stores the id of the parent grab (while creating a new ID for the current grab), thus a generational hierarchy is created which can be used to find all grabs related to a particular topic or parent grab.

Grab life cycle and group collaboration The way in which grabs are created and amended provides a simple and intuitive method of use in collaborative projects. These real time collaborations can happen using either GrabMe technology or Creative Desk (where Creative Desk is an environment for the real-time exchange of grabs).

In order to keep track of where grabs are in the system 3 different IDs are used a) GrabID -a new ID is given each time a grab is grabbed e.g. each time a new copy is taken. Updating a grab does not in itself create a new Grab ID but it does create a new version number and sends an optional message to other users with versions of the grab.

b) GrabSetlD -because grabs can be amended by anyone who has grabbed them a Set ID is given so that all members of one grab set can be quickly discovered quickly.

c) ParentGrablD -the grab ID of the parent is recorded so that paths can be found and relationships traced, each grab stores the ID of its parent A fourth ID is also stored where the grab is a member of a set or filmstrip.

Film strips The filmstrip itself is essentially a grab that contains other grabs; the filmstrip has a filmstrip ID in order to identify it. Each grab within the set inherits this filmstrip ID.

When a user grabs the filmstrip they also grab all the individual grabs within that filmstrip. This allows users to move very large quantities of data (such as an entire photo album) at a single click. Technically a filmstrip is treated exactly the same as an individual grab and the methodology for cutting and pasting filmstrips is exactly the same.

Because each grab inherits the filmstrip ID -four or five grabs collected independently of each other could be grouped together by the system -the filmstrip relationship could be construed and potentially the filmstrip re-built.

This could come in useful if users were collecting members of a filmstrip released piecemeal over a period of time, and means that filmstrips can be built in instalments.

Grab duration Grabs have by default a start and end date; the end date is usually 20 years in the future but can be set to any date so that the grab can no longer be grabbed after this time. When a grab expires its grab icon is replaced by an expired icon.

Grabs are not visible to anyone apart from system administrators prior to the start date.

Viewing grabs GrabMe uses access control lists to decide on who can view an individual grab. Only grabs marked as having public access can be seen by everybody. Those marked as having private or group access can be seen by the individual or group respectively.

Unlike on other systems viewability is decided on a grab by grab basis.

This means that a page can appear very differently to different audiences.

Grab Life Cycle Figure 8 shows a typical chain of events with a grab: 1. In the diagram Grab One is created by User A. It has a Grab ID of 1 and aGrabSetiDofi 2. The grab is then grabbed by User B, the system does this by taking a copy of the grab (apart from any digital content such as an image which is passed by reference). Because the copy is independent of Grab ID 1 it gets a new Grab ID 2 but the grab is still in the same set as the previous grab therefore it retains a Grab Set ID of 1. The parent Grab ID is obviously 1.

3. User A amends the grab which causes a message to be sent to User B, giving user B the choice of getting the updated grab. Because the grab is still the original grab owned and amended by User A it retains its original Grab ID and Grab group ID 4. User C now grabs the amended grab, this grab is given the new unique id of 3. The GrabSetlD is 1 and the parent GrabID is also 1.

5. User C amends the Grab and this sends a message out to User A and User B, because the grab is an amended version of Grab ID 3 it retains its ID (i.e. 3). The Grab ID is only incremented if the Grab is Grabbed (by a user).

6. User A and User B now grab this new amended grab (v3) and both users delete the original grab, the new GrablDs are 4 and 5 respectively.

7. Now Grab ID 1 and Grab ID 2 are orphans (i.e. they have been deleted by all the owners) and can be garbage collected Grab Patterns and inheritance As well as other information held by a grab, grabs can be tagged on subject and content and users can grab data or create grabs. Over a period of time users will acquire grab patterns which reflect a user's interests and their usage of the system.

Because grabs have a mathematical relationship to each other these patterns can be used to calculate many things about a users interests and preferences whether they are an originator or an editor.

These grab patterns can be used both in matching possible collaborative groups -and for this you could calculate an optimum collaborative group on a given project, and for advertising and promotion. The Grab pattern can also be used for searches and feeds.

The simplest way of collecting this data is to put weightings into the users profile; by watching the behaviour of groups it is possible to use this data to construe an ideal group for working on any one collaborative topic.

For the weightings a matrix system will be used, this is essentially the same as the matrix system used in a search engine; however for our analysis we are not using hits or search terms we are using behavioural patterns. Thus we are mapping behavioural patterns, this provides a far more scientific way of matching users (in terms of their interests etc) and thereby grouping individuals than can be achieved through the mapping of search terms or web usage.

This is because a grab is a smaller and far more precise unit than a web page, it carries with it exact information about who the originator was and the exact stages of development.

A second matrix that is available on the system is a matrix for originators or authors. Most users browse the web looking for data but a smaller set of users originate data, some of these data originators are very prolific, but it is often difficult to judge the quality and reliability of data as there is no way of peer reviewing data.

This is not the same with grabs.

The author measurements that are easy to get from the system are a) number of grabs e.g. popularity b) geographic distribution of grabs i.e. number of different users that have this grab c) number of first generation amendments d) number of second and subsequent generation amendments e) longevity in terms of a ratio of number of grabs over time f) longevity in terms of total generations g) number of times this author has contributed to this subject h) grab ratings -approval ratings of individual grabs from users These scales provide an exact set which can be used to calculate the profile of a user and that can be fed back into the system to help form collaborations and also to help define which new grabs a user may be interested in. This is an iterative process that can be used to refine, match and update user profiles both with grabs and with the profiles of other users.

User rights and Levels GrabMe currently has two levels of users on the system, users and system administrators. A system administrator can copy and paste grabs from any page to any other page on the system. They can set up global restrictions such as banning users or restricting data. They can also delete groups and remove content. Thus on GrabMe system administrators have a policing role.

Groups and communities One of the key innovations of GrabMe as a concept is the way in which it looks and groups and communities. A group or community can be formed in two ways: i) Any GrabMe member can create a group and then get others to join -this would be used for an open community. Group specific data is contained within the group but can be released to the wider world by the group master or originator. We have conceived of this as a group of fishermen holding a net, the fish represent data. Data tagged as belonging to that group cannot move outside the net, whereas data that is untagged can move freely. In this first scenario only the group master can de-tag data. The tag defining data as group specific is held within the XML.

j) A formal group can be created at system level which operates using secure internet protocol (https). Group specific data can only be released to the wider world if a defined number of delegated individuals agree.

This may be used for a group of doctors or teachers sharing patient details or teaching grades.

Discussion groups By default discussion groups are private, discussions can be expanded by the creator posting the discussion group into a different user's Visual Intray, or by adding the discussion group to the public list.

If a user deletes a discussion group that has been posted into his/her Visual Intray then they are removed from the group's access table. In this way it is very easy for members of GrabMe to collaborate or share in discussions and also to leave a discussion they no longer wish to participate in.

GrabMe Feeds In a GrabMe system the data is tagged, identifiable and continually moving; searching for data is, therefore, much easier.

GrabMe feeds provide a second way of looking at web content. Out of the millions of grabs happening on a GrabMe network there will be material to suit all interests. The problem, just as it is on the web today, is finding this data and even more finding content that really interests the user. Users spend hours of time doing exactly this, using search engines such as Google or MSN.

GrabMe feeds seek to offer an alternative to searching for data in which the data comes to the user rather than the user going to it.

Complex mathematical models and algorithms are not needed in order to implement a GrabMe feed.

There are two ways such feeds can be created a) the user inputs interests as categories and sub categories within the system to create a feed matrix; b) the system construes the categories and sub categories by tracing the users grab history This information can then be used to create an individualised feed for the user. The easiest and most efficient way of doing this is through a standard matrix search which runs every time the user logs onto GrabMe.

However the advantage of GrabMe is that our subset of data we are searching is far more definable than on a search engine that relies on a spider trawling across static IPs. With GrabMe, cataloguing is done as the grabs are created which helps ensure both equity and exactness in searching for data. E.g.

a search of grabs created between two dates will be exactly that a user cannot manipulate grabs to try to get to the top of the tree which is currently the case with search engine technology.

We are not trawling a static universe; rather we are creating a mesh that will filter out the correct data -that is moving towards it.

Further more this process can be automated by using the users grab pattern' to determine which grabs they may be interested in.

Visual Intray Visual Intray is a supplementary idea which adds to the GrabMe concept that allows users to drop Grabs into user's in-trays -where they can be reviewed, dropped or stored.

The point of Visual Intray is that a user can pass a grab to a different user, where the Grab can be a bulletin board or other interactive resource or just an image or document.

The visual Intray provides a key method of dissemination for collaborative projects, so discussions for example can be privately dropped into a user's Intray.

Once data has been dropped into an Intray it can be filed by the user in question. This involves the following stages: 1. The information is dropped into the user's Intray by either: a. Navigating to the users Intray and clicking the grab icon b. Clicking the grab icon on any page under the user's control; this will (on confirmation) place the grab in the user's Intray 2. The user is informed by email that a new grab has been deposited in his/her Intray 3. The user navigates to the Intray and clicks the grab for filing.

4. The grab disappears from the Intray and appears in the grab tray.

5. The user navigates to the page on which they wish to deposit the grab 6. The user then clicks the grab icon and the item is deposited in the target page using the same methodology as a standard grab.

Unlike on a standard grab a new GrabID is not created when the user pastes the grab into the target page. The GrabiD is created when the originating user deposits the grab into another user's Intray. Thereafter the same GrabID is used. Visual Intray is shown below: Items can be deleted from the Visual Intray by clicking the cross at the top of each item. This moves the item into the user's recycle bin.

Selling/using Grabs Since grabs can be exchanged between friends it makes them the ideal vehicle for selling. Our concept is that grabs with paying content are marked with a red icon. Once the grab has been pasted into the user's area a fee is payable to release the data encapsulated in the grab -e.g. �0.99 for music tracks. There are a numbers of ways that this fee can be levied a) through a subscription system which allows a fixed number of tracks to be grabbed monthly for a fixed fee b) Through a pay per grab method where the user goes to a shop to pay for the grab.

Currently for our practical application we are looking at developing method a.

For a practical e-commerce system some constraints are needed otherwise users could spend unwisely or end up paying for data clicked accidentally or never played.

Any piece of digital data can be traded using grabs. This means that software or videos or music tracks could potentially be traded between friends.

If method b above is used for the selling of third party products, this can take place without the need for the buyer to visit a third party website, so selling can happen in a viral' way, making everybody a potential trader.

The way this would work with films, for example, would be that each user could grab the film from any other user but only view once a licence key was purchased, the licence key having only a one user scope.

A list of films that the user has a right to watch is then held centrally by the system.

Turning now to the content manipulation process it will firstly be appreciated that this is described in the context of the content transport process described above but could equally well be applied to content obtained, downloaded, uploaded or stored in any appropriate manner. Versioning, identifying "live data", and searching and filtering the data, as well as notification to users of entities of interest are all aspects of the approach as will now be described.

Data items, referencing and versioning model Overview Data items themselves are a specific subset of all entities. Data items, may be composite items, which contain other data items, or may be a "leaf' data item which contains specific content e.g. images, video, text or other dynamic information.

Data items will change over time, and may be referenced from other composite data items. Therefore it is necessary to keep a strict record of which data items are "live within the system". A "live" data item is defined as a data item which is references by some other "live" composite data item. Any non-live data items may be removed from the system periodically.

Versioning and referencing A data item d may be revised. A composite data item referencing d might choose to reference a specific revision of d, or may always be interested in referencing the most recent revision of d.

We may therefore define d as a set of pairs (n, e) where n is a revision number, and e is an entity representing the content of d at revision n.

When a data item d is altered, we simply create a new pair, containing a new revision number and a copy of the data, with the applicable modifications.

This is an example of so-called "copy on write" semantics.

A reference is itself a pair (d, n) where d is the data item referenced and n is the specific revision of d which is referenced. Therefore using a reference it is always possible to retrieve the entity in the system which represented the content of that data item at a specific revision. If we always wish to reference the head revision of a data item, then we may leave n unspecified. Naturally a reference is an entity.

We will refer to references which contain a specific revision as "absolute references". References of the most recently (head) revision of a data item we will refer to as "relative references".

The system only needs to store the entities within d which are live, as per the above definition (referenced from other live entities).

A composite data item is at it's most simple a set of references. A composite data item may also have other meta-data associated with the references (E.g. display location, comments etc.) but is at it's most basic a simple set.

Practical considerations Root set To prevent all data items being defined as "not live" -one must define a "root set" -a set of data items which are always defined as live. This may be your set of system users. A user will reference, their home page for example, which may then reference other data items in the system. Therefore the concept of "live-ness" propagates from the user as the root. If a user is deleted then any data items referenced by them only become non-live and eligible for deletion from the system.

Imperfect copy on write If everyone who references a data item x is only interested in the head revision, and data item x changes, there is no need to copy the contents of x, and leave the older revision of x to be removed with all other non-live items.

We can simply directly update the content of x and increment the revision number. In order to do this, each data item must keep a record of how many specific version references it has (a simple counter of specific version references will be sufficient). If this counter is greater than zero, then the copy-on-write semantics mentioned earlier must be employed, otherwise, we can modify the item and increment the revision number.

In a practical system, for the vast majority of data items, there will be no specific version references -therefore copy on write semantics are not necessary. Therefore this scheme can greatly decrease the quantity of replication and computation required to manage versions.

Determining "live-ness" by "marking" There is only one way to ensure which data items are live in a system.

This is to use a simple graph traversal algorithm, starting from data items in the root set, and visiting each data item referenced. This will enable you to build a "transitive closure" representing all live data items within the system. It is typical to mark any data items visited as "live" as the traversal algorithm executes. Therefore this process is typically referred to as "marking".

Any data items outside of this transitive closure are not live, and data items within the transitive closure are live. Any non-live items can be removed.

The process of removing data items which are no longer referenced is typically referred to as "sweeping".

In practice for a large system with a large number of users, running such a graph traversal would be extremely time consuming. Ultimately periodic runs of such an algorithm may be required, but should be infrequent. To ensure that the algorithm works correctly, all modification of items during the period the algorithm was running should be prevented. In a 24/7 system, such overhead In order to practically solve the problem, we propose two imperfect algorithms which can be run more easily and quickly and will keep the number of entities stored in the system manageable.

Reference counting If each data item keeps a count of the absolute and relative references it has (incrementing when a new reference is added, and decrernenting when a reference is removed), then we will know it is not live when the reference count reaches zero.

This approach is not computationally intensive, but does not work for cyclic references. Since most of the data items in the system will not contain cyclic references, this imperfect algorithm should be sufficient to keep the number of entities under control.

Sector based marking We can divide data items in the system into sectors -a new data item can be arbitrarily assigned to a specific sector. To perform a sector based marking you must keep a track of any cross-sector references (i.e. references which go from data items in one sector to data items in a different sector).

Periodically a marking can take place on any individual sector. You start your traversal algorithm from any root set item within the sector, and additionally from any incoming cross-sector references. You then proceed to mark any reachable items in your sector as live.

The advantage of this algorithm is that during the time the mark is running, you only need to suspend modifications to references on the sector, and not to the entire system. Therefore this gives the capacity to split up the overhead of marking, and reduce markings which lock out all users.

Unfortunately if there are a large number of cross sector references, then this algorithm becomes less effective. Sectors must be chosen in a sensible manner in order to reduce this effect.

A generational scheme would define sectors in terms of the age of the data items, and perform markings on the younger sectors more frequently.

While this is a good idea in virtual machines, it may not make so much sense in the proposed system -as there is no guarantee of the "high infant mortality" which is present in object-oriented runtime environments such as the java virtual machine.

It may be more effective to define sectors in terms of how recently a data item was viewed. The sectors containing data items not recently viewed can be marked more regularly and are more likely to contain non-live data items. Unfortunately this incurs an extra expense of having to migrate items between sectors, and keep track of cross-sector dependencies which could become problematic.

Conclusion

Maintaining the live-ness of revisions of data items in a large system, is in general a non-trivial problem. However we propose that an imperfect scheme such as reference counting, combined with imperfect copy on write semantics should keep the storage growth of such a system under control.

Infrequently, the generating and sweeping of a "sector" containing only data items not recently viewed should ultimately be performed, although is probably not strictly required for an initial version. We believe this will be sufficient as we feel that cyclic references will ultimately be rare in this system. A degree of graceful growth of footprint is inevitable on such a system, and it may be ultimately necessary to crudely implement a "delete I archive everything not viewed for 3 years" to clear out garbage. This will be acceptable if users do not see the system as a secure storage location.

Data item feature vectors Overview Any data item will require some feature vector which succinctly distils the essence of the content of the item. This feature vector is then used for filtering, searching and so-forth which is mentioned later in this document.

One method is to think of the primary features of the data item as being representable in some form of large, sparse vector. In many cases it may be possible to generate this feature vector automatically when a data item is added into the system (for example in the case of a text document a feature vector may be generated from the words in the document). In other cases, the system must rely on meta-tagging of data when the user uploads the data into the system, or inferring the feature vector from the references to or from that data item.

General Feature vectors We must first define the concept of an "atomic category". An atomic category is a category which a day item may be classified within. An atomic category is not sub-divisible into any more specific categories for the purposes of data representation in the system.

A feature vector may be defined as an R column or row vector (where R is the set of real numbers and n is the number of atomic categories possible in our system).

Each of the elements in the feature vector represents an atomic category weighting, this is a representation of the degree to which the data item falls into a category.

The concept is most easily represented as an example: Assume that our system only has 3 atomic categories: Gardening, Cinema and Technology.

Let X be a data item, with a feature vector (wl,w2,w3) wi represents the category weighting for Gardening, w2 represents the category weighting for Cinema, w3 represents the category weighting for technology.

Let us assume that X is an article solely about gardening, in this case wl=1, w2=0, w3=0. If we were storing this vector, we may well just store the non-zero items in the vector, rather than the entire vector.

Now let Y be another data item, with feature vector (ul, u2,u3) Let us assume that Y is an article about future directions in cinematography. It therefore occupies both the atomic category Technology and the atomic category cinema.

In this case u10, u2-0.5, u3=0.5 Naturally in any practical system, any feature vector will be extremely large, due to the large number of true atomic categories. Therefore it is worth re-iterating the point that in any practical system, one should not attempt to store every value in the feature vector, but rather only the non-zero weightings, possibly in the following form (as a set of key-value pairs) { (Cinema,0.5) , (Technology, 0.5) } It is helpful to think of a feature vector as a point in a high-dimension space. Each atomic category represents an orthogonal axis. This concept will be useful when thinking about grouping data items, and considering which data items are similar. Additionally one can use spatial indexing algorithms to make searching / navigating data items more rapid. A treatment of spatial indexing is not given here.

Defining a similarity measure for feature vectors There are numerous ways in which similarity can be defined for vectors.

We will only consider Minkowski distance measures here.

Take two data items, with feature vectors (x1, x2.... x) and (y, Y2** y) respectively, the p-norm Minkowski distance between these data items can be defined as: n i/p = (>ii The Euclidian distance is the 2-norm Minkowski distance (i.e. p=2 in the above equation), the Manhattan distance is the 1-norm Minkowski distance (i.e. p=l).

The easiest way to define distance in a high dimensional space is to use a distance measure such as Euclidian distance, or Manhattan distance. Due to the very high dimensionality of the space in any practical system, a Euclidian distance measure is not recommended. Manhattan distance is easily computable and may be suitable for most practical concerns. Since the system need not be perfect in it's definition of similarity (it is not likely the feature vectors will be precise distillations of the content of entities), a simplistic, practical measure such as Manhattan distance is preferable. It is also not recommended to use Chebyshev distance (infinity norm Minkowski distance), although undoubtedly entities with short Chebyshev distance will be similar, it is possibly too restrictive.

With our distance measure defined, it is easy to work out which entities in the system are similar to a displayed item, and group / suggest items applicably to any user of the system. The problem of finding items "close" to the currently displayed item can be made more tractable by using spatial indices, and becomes the only practical manner as the number of entities in the system becomes large. If a simple indexing scheme such as "R-trees" is used, then a simple algorithm could find all items in the same r-tree node, and maybe some sibling r-tree nodes, apply our distance measure, and sort in terms of distance. In a practical setting, this approach is likely to be acceptable, although admittedly it may not be perfect -depending upon the choice of distance measure and the exact structure of the R-tree.

Hierarchical features While atomic categories are reasonable for defining data items, the number of atomic categories will become very large, very quickly. We therefore propose the following way of defining hierarchical categories.

Imagine the following structure of categories: Technology Computer technology Personal computers Future directions in computing Games consoles Communication technology Networking Telecoms Satellite Aerospace technology Aerodynamic systems Control systems In the above example we have 8 atomic categories (Personal computers, Future directions in computing, Games consoles, Networking, Telecoms, Satellite, Aerodynamic systems, Control systems). All data item feature vectors will be expressed as 8-element vectors.

Now assume we have a data item under the personal computer section of the category hierarchy, it is more similar to other articles in the Computer technology section, than it is to the other articles in the Communications technology section. Therefore there is some inherent dependency which must be expressed between the atomic categories of Personal computers, future directions in computing and games consoles.

Let a data item X's feature vector be defined as (xl,x2,x3,x4,x5,x6,x7,x8) where xl is the category weighting for "Personal computers" x2 is the category weighting for "Future directions in computing" x8 is the category weighting for "Control systems" Now define a "Computer tecimology support vector" V=( 1, 1, 1,0,0,0,0,0,0) Thus the weighting for Personal computers, future directions in computing and games consoles are all 1, whereas the other weightings are zero.

Now say a new data item X is entered into the system, it is an article about Personal computers, and it has been decided that the category weighting for personal computers is 0.5. We define the feature vector for X as: FxV+I Where I(0.5, 0, 0, 0, 0, 0, 0, 0, 0) Thus the vector we represents features which are specific to X, and V represents a "boost" to the other atomic categories which comes from the fact that X is a technology article. Therefore X's feature vector is: (1.5,1,1,0,0,0,0,0,0) This means that X will be closer to other computer technology articles than it will be to Aerospace articles.

Now imagine we add a new data item Y which is an article about aerospace control systems.

We must define a "Aerospace technology support vector": U = (0,0,0,0,0,0,1,1) And we can define the feature vector for Y: F=U+(0,0,0,0,0,0,0,0.5) Thus: F=(0,0,0,0,0,0,1,1.5) We could, on top of this define a Technology support vector which might be: W = (0.2,0.2,0.2,0.2,0.2,0.2,0.2,0.2) All data items in technology would need this added on to their feature vectors.

Note the following points: * All support vectors can be thought of as pointing in directions in our 8-dimensional space.

* The Computer technology support vector U and the Aerospace support vector V are orthogonal -i.e. distinct categories in the hierarchy are always represented in terms of Orthogonal support vectors.

* Any subjects in our hierarchy which are not distinct can be defined by support vectors which are not orthogonal, which represents an improvement over a traditional hierarchical category tree, which does not model subject crossover. E.g. If we had a category Computational aerospace control systems, it might have the vector (1,1,1,0,0,0,0,1) which is not orthogonal to U or V. Generating feature vectors Overview The generation of feature vectors from content is broadly speaking not a simple problem. In this document we will propose that the only truly reliable way of categorising multimedia data, currently, is through user tagging I annotation of the data when the data is inserted in the system (effectively the user is generating the feature vector, though some user friendly GUI).

However, there are a few simplistic methods which may make it possible to improve the accuracy of such feature vectors.

Referential support Let us say we have a data item X whose feature vector is defined as Fx = (xl,x2,x3) A number of other authors reference X from their data items Y and Z. Many users navigate the reference from Y to X and even more users navigate the reference from Z to X. Let: Fy = (yl,y2,y3) Fz = (zl,z2,z3) We can re-enforce the vector Fx, Fx' =(xl +k*yl +j*zl,x2+k*y2 +j*z2, x3+k*y3 +j*z3) i.e. Fx'Fx+k* Fy+j * Fz Where Fx' represents the new feature vector for X k, j are constants proportional to the popularity of navigating the reference between Y and X and Z and X respectively.

Effectively this moves the point Fx closer to the points Fy and Fz depending upon how popular navigating from Y to X and Z to X is.

We may re-enforce Fx simply because it has a reference from Y to X and Z to X even though it is not navigated (i.e. k andj are never zero).

TemporaL browsing support Say that X is viewed shortly after viewing A and B, even though there may be no specific reference between A and B. This implies that users interested in A and B also find X. Fx can be modified as in the above scheme to reflect this.

Keywording Each atomic category, or each category in the hierarchy may have a list of keywords associated with it. Parts of the vector can be incremented if the data item contains these keywords in any way.

Events, feeds and filtering model Overvi ew Events are a key component of the system, as users of the system will need to be notified when entities important to them are added to the system, modified or deleted. They may also need to be notified when leases on permissions are coming in or out of effect.

Formally an event can be defined as a tuple: (t, e, f, d) where t the timestamp the event is generated e the entity the event refers to (most likely a data item) f = the feature vector associated with this event (most likely from the data item itself) d an entity representing any miscellaneous details of the event.

A user will define a set of events they are interested in, or such a set will be implicitly defined. This may be in the form of a set of entities which the user is interested in, as a specific filter applied to the feature vector, or some other criteria.

Expressing interests I filters The interests of a user can be defined in terms of a set of filters. An event filter can be expressed in terms of a feature vector of atomic category weightings, as described in section 0 Data item feature vectors.

When comparing a user event filter to a data item's feature vector, rather than using Manhattan distance we propose instead the following method: Say a user U has a filter defined: Q = (ql,q2,q3) Where qi..q3 represent filter weightings for each of 3 atomic categories. The feature weightings indicate how interested a user is in each of those atomic categories. Any atomic categories the user U is not interested in will have a filter weighting of zero.

Therefore in practice Q will be a large, sparse vector, and should be stored as such, as illustrated in section 0 General Feature vectors.

Now assume we want to compare an event X to Q, and the feature vector of X is Fx (xl,x2,x3) The overall relevance can be defined as: R(Q, Fx) = (ql*xl + q2*x2 + q3*x3) * popularity(X) + advertising weighting(X) Where popularity(X) is a function of the number of hits / references X is receiving advertising_weighting(X) is some paid for advertising weighting for X. If X is not a commercial posting, then advertising_weighting(X) 0 We may then define a partial ordering upon events by looking at the magnitude of R for a user's filter Q. Issues with generation and dissemination Overview Conceptually we may think that when an action is performed upon an entity (e.g. editing a page), and event is generated. This event is compared to filters a user has individually set, to rank it for relevance, and if appropriate is delivered to some inbox or event queue for that user, or the user is alerted via some means.

In a practical system, the number of events generated when the number of users is large would be enormous, and it would be extremely computationally intensive for the system to compare each user's filters with the events generated.

Therefore it is not possible for the system to generate an event each time an action is performed in the system. We propose two distinct classes of events: * Implicit events These are low importance events, for example a user may be interested in new data items in a certain category, or modifications to existing referenced data items. The user is probably not interested in being notified of these right away, or alerted about them. These events are not generated when actions occur, but rather are generated on the fly when the system receives demand for them.

* Explicit events When these events occur, users wish to be directly and instantly notified. Rather than generating the event, and checking it against filters, users register themselves with a data item, which must maintain a list of users interested in receiving explicit events. When an action is applied to that data item, the list of users interested in explicit events is consulted, and the relevant users are notified -the event is added into their inbox / event queue, ranked for relevance etc. Broadly speaking explicit events are those of high importance which users explicitly request. Implicit events represent those things of interest, which the user had not explicitly requested to hear.

Since permission leases can easily be related to users via roles, the expiration of leases can be thought of as explicit events, triggered by the system at pre-specified times.

The generation of explicit events is a relatively simple problem which can be solved easily by attaching a list of interested users to each data item.

The explicit events are generated by the system when actions occur. However, the vast majority of events in the system will be implicit events. These implicit events will probably be of general interest to most users, and represent a key feature of the system.

The lazy generation of implicit events Implicit events will be generated from some general filters and interests associated with a user. In general the user is only interested in seeing implicit events which have occurred recently, and which have a high relevant score with respect to their defined filters.

Therefore it is proposed that implicit events are only generated when the user looks at their inbox / event queue or chooses to refresh these views. The implicit events should be treated as the response to a query which is posed by their defined filters.

If we think of the user's filters as points in an n-dimensional space, then the data items most likely to produce useful events for the user will lie close to that point, by some distance measure (distance measures for data items is covered above). Using an R-tree spatial index we can locate all data items close to our filter vector. We can then filter these by a last modified time, and consult their revision history for recent actions applied. Usually a user will only be interested in modifications or additions of new data items which are close to their filter vector. We generate implicit events for each data item close to the user's feature vector, and rank them using our above defined relevance function R. These events (if any) can then be displayed to the user.

This methodology essentially inverts the generation of events, rather than thinking of events being generated by actions being applied, and then being filtered, we can think of the events being generated by the filter, then displayed to the user. By attacking the problem from this angle and using spatial indices, the computational cost is significantly reduced. While the approach is imperfect and could miss potentially interesting information, for a practical system of the kind proposed, it would be sufficient.

As a result, Creative Desk allows users to aggregate and share mixed media such as videos, html, images and documents over the web using filmstrip' versioning.

Any data can quickly and easily be added to a filmstrip' as a new frame. Frames are marked with the users name, document name and date.

Visual data appears as thumbnails. Creative Desk works like a visual chat room -making cooperative work on graphics projects easy and intuitive.

Any size or type of file can be included in a filmstrip. Research areas include web technologies, using web for blended/distance learning, aggregation of data, visual signposting.

Updates from other users can be seen in real-time a little like on a virtual whiteboard. Furthermore Creative Desk uses each participant's computer as a server so that if a file is amended the system immediately synchronises Creative Desk with each of the participant's files. This happens in background so that visual real-time versioning on very large files becomes possible.

Creative Desk can contain a purpose built server and client application.

The application is programmed in Java and can be made available on the web to any computer.

So the chief features of Creative Desk are: a) Real time updating of files on the web by a synchronise function which compares the file on the web with the one on the users computer and produces a new frame in the filmstrip if your version is newer than the one on the web.

b) Tree structures online to allow multiple users to work on the same file at the same time.

c) Real-time whiteboard capabilities that allow users to see' what others are doing on the desk.

d) Provides a bridge between the user's computer and the web, using grabs' based on images or files on the user's computer.

Creating a new item in Creative Desk 1) the user right clicks on the desktop area of Creative Desk, this produces a context menu.

2) from this the user selects a file to upload to Creative Desk.

3) the file is uploaded and a thumbnail created on Creative Desk. The system notes the size and date of the file and scans the user's computer for updates.

4) double clicking on the file will bring up a full size editable version of the file.

5) by right clicking on the item you can add a child item by selecting add item. This method allows the user to add any frame to a filmstrip.

6) editing the file with a third party software will cause Creative Desk to prompt the user to create a new version.

7) if two people are editing the same file at the same time -Creative Desk will produce parallel versions as in a standard concurrent versioning system. The two versions show up as two branches on the tree.

8) users can add post-it' notes to images to illustrate particular points.

these are simply objects within the system, but are useful for highlighting parts of images etc 9) the user can find any image or document tree on the system from a panel on the right which contains a list of contents of the desk, this is useful for those without a large monitor or with a large number of objects on the desk.

10) Clicking on an item in the right hand panel takes the user to that item on the visual interface of Creative Desk.

11) items can also be copied into Creative Desk directly from GrabMe and visa versa, objects held in Creative Desk have additional information to those held in GrabMe. But when items are grabbed' this additional information -for example the position and location of each of the frames in Creative Desk -is stored in the Grab.

Grouping in Creative Desk In GrabMe Grabs can be grouped together to make Filmstrips. In Creative Desk, grabs are grouped automatically because links between versions are created as new versions are produced and uploaded. This process produces version trees in a similar way to a concurrent versioning system. Furthermore grabs can be grouped by selecting a range of different images or grabs, right clicking and selecting group items' This process is shown below: 1) groups of items can be selected with the mouse using a bounding box: 2) the user selects group from the menu and names the group.

3) once named the items are selected into a group which is then highlighted.

4) the resulting group the user can also ungroup items by selecting the group, right clicking and selecting un-group.

It will be seen, as a result of the approaches described above, that a system is provided in which data is stored in a form that only users can vary and in a safe and retrievable manner allowing sharing, exchanging and updating data between multiple parties as well as providing a permanent place to store and share data on the web. All users can be both providers and depositories of data and all content can be grabbed, amended and then re-grabbed allowing significant ease of sharing and copying data. For example collecting data on a particular topic and arranging it in a coherent fashion can be performed by the user on their own homepage in real time but allowing moveable data that can be mixed and matched easily.

Furthermore by dividing all the web data into entities or modular chunks with the idea of sharing them and providing the data in a hierarchy of data relationships, a system providing far more than copy and paste is provided. In particular any user can amend and change the data contained in the grab and these changes are held coherently in a versioned set of stable relationships between grabs.

It will be appreciated that the approach as described above can be implemented on any appropriate computer system and can relate to any form of data, stored in any appropriate manner and tagged or identified by any appropriate tag or icon.

Claims (16)

1. CLAIMS1. A method of transporting data content between locations comprising: selecting at least one of a plurality of tagged data content entities at a first location; storing the content corresponding to the data content entity at a data storage location; and upon applying the tag at a second location, accessing the data from the data storage location and applying it at the second location.
2. 2. A method as claimed in claim 1 in which the first and second locations comprise web pages.
3. 3. A method as claimed in claim 2 in which the tag comprises a visual icon associated with the data content entity.
4. 4. A method as claimed in claim 3 in which the data content entity comprises at least one or a gallery of data, an image, an animation, a sound or a data file.
5. 5. A method as claimed in any preceding claim in which a selected tag is displayed in a tag tray.
6. 6. A method as claimed in any preceding claim in which the second location comprises a shared data display location accessible by multiple users.
7. 7. A method as claimed in claim 6 in which the second location displays data content entities from multiple users.
8. 8. A method as claimed in claim 7 in which a user can modify another user's data content entity.
9. 9. A method of manipulating data between multiple users comprising the step, at multiple user stations of uploading respective data content entities to a shared location and permitting a user to edit another user's data content entity at the shared location.
10. 10. A method as claimed in claim 9 in which the data content entity is obtained according to the method as claimed in any of claims 1 to 8.
11. 11. A method as claimed in claim 9 or claim 10 in which the data content entities are one of the same or different data content entities.
12. 12. A method as claimed in any of claims 9 to 11 in which a versioning identifier is applied at each edit of a data content entity.
13. 13. A method as claimed in any preceding claim in which a data content classification is associated with each data content entity.
14. 14. A method as claimed in claim 13 in which a user having a user profile is notified of data content entities having a classification corresponding to said user profile.
15. 15. A computer readable medium comprising a set of instructions implementable on a computer to implement the methods of any of claims 1 to 14.
16. 16. A computer system arranged to operate under the instructions of a computer readable media as claimed in claim 15.