Patent Application
20100153862
The invention is related to computer software and specifically to managing graphs of data objects which may be distributed and have changing schemas and which may be applied to application interoperability and to social networking on the Web.
In object oriented programming languages, objects exist each of which has attributes comprising name-value pairs where the value can optionally be a pointer at another object. Typically a “schema” exists comprising classes and associations which provide templates for objects; the classes are typically related by inheritance. The objects and the pointers/attributes/variables that connect between them are known as an object graph.
Distributed object graphs are incorporated in products available from, inter alia, Terracota Inc. of San Francisco, Calif., such as Terracotta DSO, which federates graphs in the Java programming language. Usually, distributed object graphs utilize consistent technologies such as Java or a neutral object format such as CORBA and these do not normally support a flexible schema.
The Semantic Web activity of the World Wide Web Consortium of Cambridge Mass. also provides standards known as RDF and OWL for creating distributed information models.
Extensible databases, where users can add new categories at runtime, such as Google Base from Google Inc., are available commercially, however these extensible databases are flat in that there are no structured links between objects based on their classes or types but only based on text and URLs. There is also no inheritance hierarchy of classes. Another more sophisticated extensible database, which went live after the priority date of this application, is Freebase by Metaweb Technologies of San Francisco, Calif., (www.freebase.com); however it is limited to one object graph with extensible schema and does not provide a distributed object graph.
Social Networking via the World Wide Web is well known from such services as FaceBook.com from Facebook Inc. of Palo Alto, Calif., myspace.com and LinkedIn from LinkedIn Corporation of Palo Alto, Calif. Currently such services allow a user to find other people via fixed attributes such as: name; address; via mutual acquaintances; via specific content like music playlists; and/or via keyword search, but not in other more structured and flexible ways.
What is needed, and not supplied by the prior art, is a general object graph arranged for sharing structured data between and users and between applications providing increased flexibility.
Certain embodiments of the present invention describes a General Object Graph for sharing structured data between users and between applications and for social networking between the users, an associated graphical user interface and application to a virtual file system with an associated authorization scheme. A distributed version of the General Object Graph is also presented known as a Federated General Object Graph.
In certain embodiments, the invention provides for a computer implemented system exhibiting persistence for a graph of objects where the schema of the objects is changeable at runtime, the system comprising: a server supporting a General Object Graph, the General Object Graph comprising: a plurality of Objects; and a plurality of Classes, a client application, wherein instances of the client application are operative on a plurality of computing platforms each in communication with the server to view and edit the General Object Graph.
In certain embodiments the invention independently provides for a social networking system comprising: a persistence server; an object graph including concepts of classes, associations, objects and attributes, stored on the persistence server, where some of the objects correspond to real world items; and a client software operative to enable a plurality of users to view the object graph, wherein at least one of the classes represents a class of people; and at least one of the associations has a source or type of a class which represents a class of people.
In certain embodiments the invention independently provides a system for data interoperability between applications comprising: a persistence server; an object graph including concepts of classes, associations, objects and attributes, stored on the persistence server, where some of the objects correspond to real world items; a graphical user interface including icons which correspond to the objects; and a graphical user interface for moving the icons between different applications.
In certain embodiments the invention independently provides a computer implemented method for persisting a graph of objects where the schema of the objects is changeable at runtime, the method comprising: providing a General Object Graph; and providing a client application, wherein the General Object Graph comprises: a plurality of Objects; and a plurality of Classes, wherein instances of the client application each provide for: viewing and editing the General Object Graph.
Additional features and advantages of the invention will become apparent from the following drawings and description.
For a better understanding of the invention and to show how the same may be carried into effect, reference will now be made, purely by way of example, to the accompanying drawings in which like numerals designate corresponding elements or sections throughout.
With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in the cause of providing what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice. In the accompanying drawings:
Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The invention is applicable to other embodiments or of being practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.
Unless the context determines otherwise, when the following terms appear with a leading capital herein, the following meaning is intended:
The concept of an Object Graph is known to those skilled in the art from Object Oriented programming languages such as Java from Sun Microsystems Inc., C++ from Microsoft Incorporated of Redwood Calif. and from object oriented relational databases such as those from Versant Corporation of Freemont, Calif. An Object Graph represents some real world entity or data entity. Classes within the Object Graph provide templates for groups of objects which are related. Classes have Associations which are templates for the Attributes of their Objects. The Attributes are named and relate Objects to other Objects or to data values.
A Class denoted C1 may be marked a Subclass of a Class denoted C2 meaning that every Object that is an instance of C1 is implicitly an Instance of C2 and every Association of C2 is implicitly Inherited by C1.
Object Graphs are usually limited in scope to specific business domains. Their Classes are usually determined at design time and change rarely. These rare changes typically occur only when a new product version comes out. Some aspects of an operating system such as the File System are generally outside the scope of any Object Graph, since the File System does not support links between Files and other Objects. In one embodiment, the present invention enables an Object Graph which exhibits additional flexibility to known Object Graphs and which is applied to a far broader range of tasks than traditional domain-specific object graphs. We there refer to this as a General Object Graph.
A General Object Graph may be a standalone system, or an infrastructure used by other applications or part of some broader “home application” which combines the General Object Graph with other functionality optionally including a file system and domain specific applications like a contact manager, calendar, customer relationship manager system, database of locations or other application program.
In one embodiment the General Object Graph is embedded in a Virtual Hosted Operating System which provides a desktop, applications and file system all in a Web browser. With some novel extensions the General Object Graph can play a key role in the Virtual Hosted Operating System. The idea is to have a single object graph telling us about concepts in the real world which are of common interest to multiple applications. The same single General Object Graph is to be accessed by many users, many applications and multiple infrastructure aspects. For example a Virtual Hosted Operating System can use it also for the file system and services directory. Even so, in one embodiment large volumes of Objects which are very specific to a single application are excluded for performance reasons.
Examples of the Classes of Objects that might be included in a General Object Graph are:
The same General Object Graph can address the following goals:
Multiple users interact with the system using “terminal” 105a, 105b, respectively, each capable of running software which may be a PC but also a mobile phone, set-top box or other device. The user interacts with the system respectively using a Client 111a, 111b, generally Client 111, which might be installed software but which is preferably an interactive web page downloaded from data center 100, or a different data center, and running in a Web browser 110 on terminal 105. Client 111 is in one embodiment coded as a sequence of HTML pages generated server-side, i.e. at data center 100, using one of Java Server Pages and Microsoft Active Server Pages, without limitation. In another embodiment Client 111 is constituted of software code that runs in browser 110 using, without limitation, Flash, Javascript+DHTML (known as AJAX), Java applets, ActiveX or a higher level Web programming language such as OpenLaszlo.
A General Object Graph 114 is persisted in database 113 which may be a relational database, object database, or Amazon SimpleDB. Using the principal of a 3-teir architecture, the business logic for the General Object Graph is implemented in one or more server(s) 115 which exposes the business logic using API 120 which preferably is exposed over HTTP optionally using the principals of Representational State Transfer (REST) or a remove procedure call style such as XmlRPC or alternatively SOAP.
Third party service providers 101, which may or may not be technically and commercially related to the provider of General Object Graph 114 and the data center 100, provide applications which read and optionally write specific classes of objects relating to their domains to General Object Graph 114. They access General Object Graph 114 through API 120. Optionally, third party service providers 101 utilize a different API to the API used by the client 111.
Objects are the central Concept in this Metamodel. An InstanceOf relationship relates Objects to the Classes they belong to. In contrast to Objects in accordance with most prior art Object Oriented metamodels, an Object in accordance with a principle of the current invention may belong to multiple Classes because this happens with real world objects. For example, a particular person may belong to a Class known as Engineers and a Class known as French citizens. Classes are related by Subclass relationships creating a Directed Acyclic Graph (DAG). An Object which is an InstanceOf a Class is implicitly an Instance of every Superclass of that Class. Therefore the function “Subclass-of” is also known as “Inherits-from”. In accordance with a principle of the invention, a Class is itself a special kind of Object and a Class may be an Instance of a Class. This contrasts with Object Oriented models of the prior art.
A Class has Associations. These provide a template for the Attribute of the Instance Objects of that Class. An Association may be Simple and have a datatype selected from, among others, integer, Boolean, and date. In another embodiment an Association may be Compound in which case the type is itself a Class. Thus, in a non-limiting example of an embodiment of a Compound Association, a Class “Person” has an Association “father” and the type of that Association is “Class Man”. Associations may have minimum and maximum cardinality and a combination of Associations may be marked as Unique, i.e. no distinct Objects may share values for all such Associations.
The Objects have Attributes—generally one for each Association of each Class which the Object is an Instance of, although this restriction need not be strongly enforced. The Attribute has Values and the number and type of Values preferably follow the type of the relevant Association, although this restriction need not be strongly enforced.
Particular Objects exhibit special DisplayData attributes—giving the icon graphic and caption for displaying it.
It is helpful to define two special Class Objects (whose name is written in all-capitals to distinguish these special Class Objects which are within the graph from the Metamodel Concepts they correspond to):
A small sample graph is provided in
An aspect of the Metamodel of the present invention is that the ‘schema’ concepts—Class, Association and SubclassOf can preferably change at runtime and are not hard coded as in most object-oriented systems.
According to a preferred embodiment of the present invention the General Object Graph includes Associations which are ‘Simple’ in the sense that they point at dataypes instead of other Classes and the corresponding Attributes take primitive values instead of pointing to Objects.
Two data types require special mention, User Ratings and Votes, which are particularly applicable for instances where multiple users collaborate, or share, a joint resource. In such an embodiment, there is often a need, or a desire, to rate the resource and show the ratings to various users. For example the rating of a movie is advantageously established by averaging multiple user ratings or movie-of-the-year is advantageously established by allowing users to vote on the value (being a composite value which points at specific Objects of Class movie, say).
User Ratings is a value which is comprised of an average of user votes. For examples a user may choose a rating between 1-5, for example by selecting one to five of five stars in a user interface of Client 111. In a preferred embodiment each vote is stored including the userid of the voter, in order to prevent duplicate votes by the same user and all of them are associated with a single User Rating value object which has methods for calculating the average which is the value then displayed.
Alternatively a more general scheme of User Votes is possible which is not limited to 1-5 ratings. In this scheme every Association has a binary variable indicating if it is a User Vote or not (not shown in the Metamodel of
For any Attribute instantiating a User Vote Association, the Attribute will not have a normal Value but instead a number of Vote Values will be provided by users. Whenever the Attribute is shown to a user who has not yet voted on that specific Attribute, they will be invited to enter a ‘vote’ which is simply a Value (Simple or Composite) of a Type which is appropriate to the Type of the Association.
To implement this, preferably all Vote Values are persisted in a single relational database table or one Amazon Web Services SimpleDB domain although alternatively a separate table or domain may be used for each User Vote Association. Each Vote Value is preferably persisted with the following data:
The Attribute of a User Vote Association does not itself need to persist any Value since those are available in the Vote Value persistence. However to increase performance, preferably the Attribute keeps some statistical data such as:
Two alternative preferred embodiments are described for persisting Internationalized Strings in a relational database (or by extension in another data persistence solution such as SimpleDB) so that Internationalized Strings which are Values in the General Object Graph may be persisted. In both of them each string has a unique identifier which might be a unique number and/or a more descriptive text key such as title-for-the-logout-warning-alert or more preferably a string of identifiers creating an implicit tree structure such as desktop-strings/alert-strings/title-for-the-logout-warning-alert.
According to a first embodiment one table (or file or Amazon Web Services SimpleDB Domain) has a row per string which includes:
In this first embodiment there is optionally a second table which lists the Internationalized String identifiers and in that case the Internationalized String metadata moves to the second table.
In a second embodiment there is one Internationalized String table which lists the Internationalized String identifiers and metadata and there is one table per language which contains columns for Internationalized String identifiers and the translation String.
Preferably Internationalized Strings are transmitted from Virtual Hosted Operating System Server code 116 to Client 111 in one of two ways:
In the language of the user's choice, the user's choice being a parameter for the Client 111 request to receive an Internationalized String from Virtual Hosted Operating System Server code 116; or
All the translations at once e.g. in an XML element of the general form as shown in
As well as using Internationalized Strings for general attributes in the General Object Graph, e.g. for a description of a camera or review of a book, the same mechanism can be used to internationalize the graphical user interface of Client 111, as will be described further below.
In one embodiment, General Object Graph 114 is persisted by an object-oriented database management system (such as those from Versant Inc. of Fremont, Calif.) since these are specifically designed to persist object graphs—however these typically do not support the full Metamodel desired.
In another embodiment, General Object Graph 114 is persisted by a relational database management system, with one table per class, and known strategies for capturing inheritance—however the schema will have to be changed at runtime which is not fully supported by most object-relational mapping tools and by the RDBMS itself.
In yet another embodiment a relational database management system is used with a schema reflecting the Metamodel (i.e. one table for all objects)
In one embodiment of General Object Graph 114, a complete history is kept such that General Object Graph 114 can be reconstructed as it was at any moment in history. General Object Graph Concepts (the Metamodel classes) are dividing into two main categories from the versioning perspective: versioned and immutable concepts.
Versioned Concepts are Concepts that include variables subject to change from time to time, so that a version history for those variables is stored, while immutable object do not change, till they are deprecated.
Both of these categories, versioned and immutable are also subject to another classification: immortal and archivable. The second classification comes from the fact that some Concepts cannot necessarily be archived even after being deprecated, since other concepts point back to them so they may be referenced.
The specific concepts in the General Object Graph Metamodel of
In order to track changes in the concepts, accordance to an aspect of the invention we denote a particular type of event as an Edit Event. An Edit Event is preferably represented by the following parameters:
Edit Events are therefore preferably persisted in a relational database table (or Amazon SimpleDB Domain) with four columns, the fourth being an arbitrary unique edit event identifier.
The following events will point to an Edit Event:
Preferably a relational database for persisting General Object Graph 114 is adjusted to accommodate these versioning concepts as described below.
For every versioned concept there will be in addition to the concept identifier column a version identifier column which together form a composite key. Preferably the version identifier 0 will be reserved for the current version whereas version identifiers 1, 2, 3, . . . , n will denote historical versions (so that version 0 actually comes after version n).
Upon a change, the row of the master version 0 is first copied to become version (n+1), and then version 0 is updated with the new values.
In one embodiment such versioning is implemented by Aspect Oriented Programming a technique familiar to object oriented programmers. An Aspect is used to make sure that any change to a versioned concept (e.g. a call to a setter of an Object representing a Metamodel Concept) triggers a copying of the master version in this way.
Additionally every concept table preferably exhibits two additional columns for createEvent and deprecateEvent, In an immutable concept there is one row per concept and these columns denote when it came into existence and when, if at all, it was deprecated.
In a versioned concept each version of each concept has a row and these columns denote when that specific version became active and when it was replaced. The createEvent of version 1 denotes when the concept was first created and if the deprecateEvent if any of version 0 denotes when the concept was finally deprecated.
In certain embodiments the following validity constraints apply to General Object Graph 114. Even so, optionally these are enforced weekly in that the graph may break validity rules and the system will simply highlight such breeches and encourage users to overcome them but will not prevent them. In one particular embodiment these constraints are applied in a ‘lazy’ manner meaning that when concepts happen to be displayed they are then checked for validity.
In certain embodiments, API 120 provides access to General Object Graph 114 for Client 111 and optionally to third-party service providers 110 with methods such as the following:
getObject, getObjectStub, getAssoc, createObject, query, putUpdatedObject, createAssoc, isIntanceOf, isSubClassOf, getAttribute, getAssocs, setAttribute, addAthibuteValue, removeAttributeValue, deprecateItem, deprecateAssoc, addInstanceOfRelationship, addSubClassOfRelationship, removeInstanceOfRelationship, removeSubClassOfRelationship.
By way of example, the API method isInstanceOf is in one embodiment defined as follows
In another embodiment API 120 is an HTTP API preferably designed according to the style known as Representational State Transfer (REST). In this style each object will be given a URL according to its OID, e.g.
http://general-object-graph.com/{OID}
and related concepts may also have a URL e.g. an attribute
http://general-object-graph.com/{OID}/attributes/{attribute-name}
and the related classes
http://general-object-graph.com/{OID}/isInstanceOf
Relevant HTTP methods like GET, POST, PUT, DELETE may be used on these URLs in accordance with the principals of REST e.g. setting an attribute with:
POST http://general-object-graph.com/{OID}/attributes/{attribute-name}
and the attribute value in the body of the POST or using ?value=xyz
Queries may be attached to classes for example this might give all the instances of a class:
GET http://general-object-graph.com/{OID-of-Class}/instances
While this may be a query on some Associations assoc1 and assoc2 of the class (where the text inside [ ] must be URL escaped)
GET http://general-object-graph.com/{OID-of-Class}/instances?query=[assoc1=“5” and assoc2<“banana”]
In one particular embodiment, Object data is returned by API 120 in a format as:
In one variation of this embodiment API 120 uses the WebDAV standard and optionally Categories may be treated as WebDAV collections.
An alternative approach to persistence instead of an RDBMS uses a hosted storage/retrieval/query service which deals with Objects which include name-value pairs. Amazon Web Services Structured Data Service (SimpleDB) available from Amazon.com Inc. of Seattle, Wash. in beta version, offers such a service and is used hereinto below to describe an alternative preferred embodiment of General Object Graph 114 persistence.
In SimpleDB the only datatype that is directly supported is a String. We therefore serialize all General Object Graph Simple Values together with their datatype (and other) metadata into XML Strings of the following format: <v>{serialized value}<t type=“{type code}”/></v>.
It will be appreciated by those skilled in the art that having the same precise string <v> to the left of all values will not impact the sorting of those values. It will also be appreciated that the use of XML allows extensibility to add more metadata—for example <v> may have more XML subtags to capture authorization for the Value, metadata about when the Value was created and edited, etc.
The type codes are in one embodiment as follows:
In one embodiment the following SimpleDB Domains (which are vaguely parallel to relational database tables but not strongly typed in the same way) are used:
According to one embodiment, every SimpleDB Item in this domain encapsulates one General Object Graph Object which may or may not be a Class—including all of its Attributes and Values.
The SimpleDB identifier of the Object is equal to its OID.
Each SimpleDB Item has some name/values pairs corresponding to the Metamodel Variables of the Object and some more name/value pairs corresponding to the Attributes of the Object.
The Object has the following Variables. It is to be understood that the Variables must be distinguished from the General Object Graph Attributes which have name=AID-. This is preferably accomplished by a leading underscore assuming that AIDs never start with a leading underscore.
In addition there is a list of name/value pairs each capturing a General Object Graph Attribute Value where the name is the AID of the Attribute and the Value is the value of the Attribute which is either an OID or a serialized data value. For one Attribute of type AID with multiple Values we put multiple (AID, Value) pairs with the same AID.
For example father=asdlkfhasdlkfh where father is AID of an Association and is a (unique randomly assigned) OID of the Object representing the father.
The SimpleDB Identifier is the AID
We have special name/value pairs representing the Variables of the Association Concept as follows:
We implement each path as an SimpleDB Item with three name/value pairs:
If required a transitive closure SimpleDB Domain (the use of which is described above) may be used where each Item has:
We have one Object for each internationalized string:
SimpleDB Item identifier=Internationalized String ID
name/value pairs are
In an embodiment in which persisting is accomplished in SimpleDB, in one further embodiment versioning is more easily achieved by versioning entire Objects and Associations. This method of persisting is contrasted with the more fine grained versioning scheme describe above.
To do this we create extra SimpleDB Domains for:
When an Object/Assoc changes we copy the old version to an ObjectHistory and AssocHistory domain with a key of OID+Version#.
Every Object Assoc and their historical version get an extra attribute such as versionCreatedByEdit=[editEventID]
Panel 2702 allows the user to define a query for Objects in the General Object Graph. Preferably two types of Queries are allowed:
Panel 2703, shown in its minimized state, shows a hierarch of Folders as familiar from most popular operating systems (or optionally several hierarchies such as the one starting with the user's own “My Objects Folder” and with a general public “Directory of Objects Folder”). When a Folder is selected it is equivalent to an Attribute Query on the FolderContents Attribute of the Folder Object selected—which will therefore show all the Icons/Objects in that Folder.
Panel 2704 shows a set of Icons 2705 pointing at Objects which are the results of the Query 2702 (or the implicity Query of selecting a Folder in 2703).
If a specific Icon 2705 is selected (e.g. by clicking, double-clicking or via a context menu) it may be shown in greater detail as shown at 2706. Simple Attributes may be shown in tabular format 2707. Composite Attributes may be shown using Icons like 2708 if they have a single Value or if there are many values an Icon like 2713 may represent the collection of Objects which are the Values of the Attribute. Clicking a single value Attribute 2708 may make it the subject 2706. Clicking on a set of Attributes 2713 may implicitly populate the Query panel 2702 with the appropriate Attribute Query in this case Books of Adel.
It is also possible to display reverse Attributes (not shown) e.g. Attributes which point back at the Object 2706—for example all the People whose Friend's Attribute includes Adel.
An unstructured search 2709 may search for Objects based on key words (which may be limited to key words in the Caption, or may include other or all Attributes of Type string).
A Folders Panel 2710 may list all the Folders where ContentsOfFolder includes the Object 2706.
A Categories Panel 2711 may list all the Classes which 2706 is an InstanceOf (which may include the direct ones only or also all the Superclasses of those—or the user may be presented with the direct Classes which the Object is an InstanceOf each of which may be the apex of a tree which the user can expand to see the Superclasses and Supersuperclasses, without limitation, which the Object is implicitly an instance of).
Some special “Anchor” Objects 2712 may be shows which may include the Object representing the user themselves, their main or home Folder, or other Objects that they may choose to place there.
Preferably the navigator includes an icon representation for an Object which preferably includes:
Preferably Icons participate in drag-and-drop actions. For example dropping a first icon onto a second icon of category Folder would add to the contents attribute of the Folder the value of the first Icon's OID. Dropping a second Icon representing a Category would add that Category to the list of Categories for the Object which the first Icon represents.
Preferably Client 111 caches copies of Objects that it reads from the server for quick navigation. Preferably results of Queries will not be cached (although it may be cached)—since a specific Object changes only rarely but the result of a Query is impacted by many Objects and will change frequently.
In one particular embodiment, a Cache is implemented using an OpenLaszlo dataset which contains an XML representation of the Objects that have been read. Preferably a ‘dictionary’ data structure is maintained on the Client so that Object data in the cache can be rapidly looked up by Object ID.
Preferably as well as the Object Data, the Client actually keeps an object-oriented object which encapsulates each Object in the cache (e.g. objects according to an OpenLaszlo class GeneralObjectGraphObject which point at the XML in the cache for an Object and which provide methods for manipulating the Object such as getCaption, getAttribute(AID), getInstanceOf and other variations and setters; preferably such an object can be further encapsulated in a graphical object which implements the icon which visually represents the Object).
A use of General Object Graph 114 is to move structured data between applications, an in particular preferably applications launched from the same home application which might include a web desktop or preferably a full Virtual Hosted Operating System.
According to an aspect of an embodiment of the invention visual Icons represent pointers to Objects. Preferably these are implemented using a client-side programming language class denoted herein GeneralObjectGraphObjecticon. Therefore more than one application program may use the same class to represent Icons.
Preferably Icons may be dragged-and-dropped and/or copied-and-pasted between programs as a way of moving structured data, namely Objects, between programs. Alternatively as described elsewhere herein, preferably an Action may be chosen in respect to an Object which will automatically trigger an application or other Service.
In practice, preferably only the OID need be communicated between applications. The target application can use the OID as a key to query General Object Graph 114 for all Attributes (and Attributes of Attributes etc.) of the dragged Object.
Other GUI constructs may represent Object Containers being an interface of any GUI construct (or the underlying model in an MVC scheme) which is able to receive “drop”s of Objects (e.g. with a ‘drop’ or ‘addObject’ method).
Sample use cases include:
Advantageously, by implementing the file system using General Object Graph 114 simpler actions which are known from operating systems in the prior art such as dragging-and-dropping files between folders are implemented as special cases of the more general drag-and-drop.
A use of General Object Graph 114 is to help people find each other and initiate communication. This is achieved, in accordance with certain embodiments of the invention, without any change to the Metamodel by creating Associations which relate a User Class (or more generally a Person Class which may include information about non-Users) to other Classes.
For example there might be an Association StudiedIn which relates the User Class to a University Class. A User may create a corresponding Attribute to register which university they attended. Another user may Query to see who else attended the university they attended.
In another example, the Class Product may have a Composite Association OwnedBy of type the Class Person. As a result, Users can thus use General Object Graph 114 to find other people who share ownership of the same product—for example a camera which they want to discuss usage of.
Preferably General Object Graph 114 is coupled to a Service or Services which in one embodiment is a Third-Party Service from Third-Party Service provider 100, for communication between its users which might include instant messenger, e-mail, voice-over-IP and videoconferencing over IP. Preferably a user initiates such communication by right-clicking in the General Object Graph Navigator, as described above in relation to
It will be appreciated that by combining General Object Graph 114 with an ability to instantiate communication, General Object Graph 114 takes on a new and unique role in enabling rich social networking around common interests, common geography common family links, and/or common history of people. The above is a non-limiting example of advantageous social networking according to an aspect of the invention.
Further any Association of type Person, or a subclass thereof, which has maximum cardinality more than 1 defines a group of users with something in common and these user may be invited to become a group for other purposes including, but not limited to: group communications, sharing privileges to access shared resources and/or sharing desktop preferences.
According to certain embodiments of the invention, files from multiple file system have their data represented as objects in General Object Graph 114 in addition to inside the file system. Advantageously, this allows richer object-oriented metadata for the files. For example a file representing say a photo may be represented by an object which has an attribute pointing at an object representing the photographer.
Further advantageously, files from different file systems from different service providers can all have metadata in a single General Object Graph 114 providing a sort of virtual file system.
Generally, prior art file systems allow logical units of data called ‘files’ to be stored on the same physical disk. Further they usually allow the files to be organized into a hierarchy of folders. Networked file systems allow files from more than one physical disk to be organized into the same folders. Links or “shortcuts” allow the same file to be referenced from more than one folder. What is common to these systems is that each file corresponds to some physical location on a directly accessible disk.
This approach is not appropriate for a user who wishes to work with files from many different web service providers (e.g. as part of a Virtual Hosted Operating System) across the Internet over which they have no physical control.
For example today a user may have photos stored on flickr.com by Yahoo! Inc. of Sunnyvale, Calif., spreadsheets stored on Google Docs from Google Inc. of Mountainview, Calif., and any files at xdrive.com from AOL Inc. These third party file hosting service providers each have exclusive control over the physical storage of the files they store. Yet a user would like to organize all of these files into the same set of folders. Also the user would like to apply actions to these files depending on their type, irrespective of the service provider.
For example a user may desire to take a photo file hosted by photo storage service flickr.com and another photo file hosted at xdrive.com and logically place them in a single ‘My photos’ folder. A simple hyperlink will not suffice because the user desires to perform specific actions such as ‘edit photo’ which are specific to the type of file in discussion.
A detailed example use case is as follows as illustrated in
The virtual file system aspect of the invention may be understood by reference to
The left panel shows a hierarchy of Folders. The root folder is called ‘My Documents’ and is selected. The right panel shows Objects which are in the selected Folder.
These includes subfolders ‘favorites’, ‘quick launch’ and ‘desktop’. This user interface for viewing the folder hierarchy may be used instead or as well as the more general user interface in illustrated above in
The contents of the ‘My Documents’ folder shown in the right panel further includes:
The distinction from a physical file system will be appreciated. The different icons do not represent files with a known physical location. Instead they represent files which may be accessed through different third party services using different interfaces. Further the metadata in the Object is not just a hyperlink generic file metadata but is preferably highly structured metadata optionally including Composite Attributes which link the Object to other Objects.
Even so the user is able to interact with these files almost as if they were on the local disk. Advantageously the virtual file system of the subject invention abstracts access to files stored by different third party file storage service provider including:
The mechanism for abstracting authentication is described elsewhere herein under ‘Single Sign-On’ and is further described in the above incorporated co-pending and co-filed patent applications.
The mechanism for abstracting the classes of files and the actions associated therewith are described elsewhere herein under ‘General Object Graph’—since in accordance with certain embodiments the invention is able to associate actions with classes of resources more broadly than only classes of file resources.
To abstract the different protocols to access the files, a common protocol or interface is preferably used. In one embodiment, file transfer protocol known as ftp defined by the Internet Engineering Task Force of Sterling, Va. is used. Where a third party service provider does not support the common protocol, an adapter may be hosted by the service provider of the Virtual Hosted Operating System within Virtual Hosted Operating System Server code 116. In one particular embodiment the adapter is a Java Servlet running on a Java Web Server with a Servlet Container such as TomCat from Appache. The adapter accesses the file from the third party service provider and makes it available using the common protocol. When such an adapter is used, the URL address listed for the third party service provider in the services directory will be the URL of the adapter.
Alternatively, multiple protocols may be supported and the services directory may list as an Attribute of a Service implementation which protocol is supported by each file storage service provider.
It should be noted that in many cases the third party file storage service provider also provides a file editing service. For example Google Inc. hosts spreadsheets documents and also hosts application software for editing the spreadsheets. In this case it is not necessary for the Virtual Hosted Operating System to access the physical file at all. In the case where the User desires to use the editing service from the same service provider, the editing service is preferably launched, e.g. in an iFrame window, and passed a parameter identifying the file to be edited.
If however the user desires to edit a file from one file storage service provider with an editor from a different hosted application service provider, the Virtual Hosted Operating System accesses the file using a common protocol or adapter and transmits it to the third-party hosted application service provider.
While the Virtual file system may be implemented independently, it is instead preferably implemented using General Object Graph 114. In one particular embodiment:
While the Virtual File System of Client 111 can accommodate files hosted by Third-party Service Provider 101 and in fact Objects of all Classes, it is advantageous for the Virtual Hosted Operating System server 115 to include some storage for each user for uploading/downloading files from their local operating system. A user interface for this as part of a File Explorer is shown in
Preferably specific interfaces are created for various specific hosted file services. For example suppose there is a General Object Graph Class SupportedHostedFilesClasses and for every instance such as GoogleHostedSpreadsheet a menu item appears in the File Explorer “New Google Hosted Spreadsheet”. According to an Association of SupportedHostedFiles, GoogleHostedSpreadsheet has an Attribute pointing at some code or a URL of an adapter which is able to launch Google Spreadsheets with a blank new spreadsheet in an iFrame. When “New Google Hosted Spreadsheet” is selected, Client 111 creates a new Object of type GoogleHostedSpreadsheet in the current Folder and passes the OID to the adapter which returns Google's unique ID for the new spreadsheet using Google's API and this is added as an Attribute to the Object. The next time the Object is double-clicked, a second method of the adapter is called to open the existing spreadsheet based on Google's unique ID. In this workflow the request to create the hosted file originates in the Virtual Hosted Operating System Client but alternative adapters can help discover existing hosted files and create Objects to represent them in the General Object Graph in order to create an effective Virtual File System.
In one embodiment services are overlaid over the virtual file system, the overlaid services being otherwise designed to work with a physical file system.
For example, a file transfer protocol (ftp) server product such as Apache FTP Server from the Apache Software Foundation is adapted to ensure that the calls it makes to a physical file system are replaced by calls to a virtual file system.
A system for matching files with editing services, and more generally objects and actions with service providers according to a preferred embodiment of the invention may be understood by reference to
At the top of
At the bottom we see that there are ServiceProvider. These are typically companies who offer services online, i.e. Third-Party Service Providers 101. A ServiceProvider may offer a specific implementation of a Service such as photo-editing and specific implementations of the associated actions. ActionImp has a template for accessing the action including at least a URL and a parameter name for passing the object identifier by for example HTTP GET or POST of the Object on which the Action is being invoked.
ServiceProvider typically offer Subscriptions which may often span multiple services. The system preferably tracks when a Virtual Hosted Operating System user signs up to a service provider for services. Preferably, a separate table keeps parameters associated with how to access a given service provider sign-in and actions, as described further below regarding Single Sign-On.
By adding methods to the General Object Graph Metamodel
An alternative approach to matching actions and specific third-party service offerings to Objects is by extending the Metamodel as illustrated in
In the Metamodel of
A method may optionally take further arguments. For example the “bid” method on a Product may require a price number and the user asking to implement the method (e.g. by right-clicking on an Object's Icon to see all methods associated with the Object's Class including Superclasses) will be prompted to input values for the Arguments.
A Class also has MethodImplementations each of which implements some Method (of the same Class or of a Superclass) by providing a specific API method to be called (which may be a local method call in the Client [shown by way of non-limiting example as a Laszlo method], a remote call in the server, or direct to a third-party service-provider API). The MethodImplementation may override a MethodImplementation of a superclass which relates to the same Method.
By way of example:
The goals of authorization is to provide a logical model from which we can determine in a useful, fair and secure way, who may:
Additionally we need to know who is authorized to set and change permissions for the above.
The principles of a model for cascading authorization according to the invention may be understood with reference to
The following roles interact with General Object Graph 114:
An assumption according to the invention is that we may assume that once a user reads data there is nothing to stop the user from transferring this data to others. For example if user A is authorized to discover the OLD of an Object, and thereby see all Attributes with default permissions, they may choose to pass on the OID to another user. Preferably the Virtual Hosted Operating System will not try to prevent that because in real life too—anyone who is trusted with information must also be trusted to choose who they pass it on to.
An OID for an Object is a secret key to that Object. It is too long and random to guess. Preferably the OID for an object comprises a 128 bit random number generated using one or more of fine grained time, IP address, ambient temperature and other arbitrary varying data. Anyone who has an OID is assumed to have either discovered themselves based on legitimate permissions or to have received the OID from someone who discovered it legitimately and who had the right to pass it on.
Permission for an Attribute are determined based on a combination of:
A model of two Categories, C and D, and an Association between them, should consider which direction the Association is based on, and this is based on ownership. An Association C->D will be controlled by the owner of the C-type Object. An Association D->C will be controlled by the owner of the D-type Object.
The following special Categories preferably have hard-coded behavior which imposes restrictions on how the Instance Items are Owned. Other Categories may be Subcategories of these.
In one embodiment a Disjointed Class constraint is added to the General Object Graph Metamodel to indicate that the above three Categories are disjointed—i.e. no Object may Instantiate more than one.
If none of these special Ownership Categories apply then preferably an Object will be Owned by its Creator who may also assign the Ownership to another.
Non-Limiting Example
Object ownership impacts modeling. Preferably Credit Card data is separated from Credit Card Account because the former is owned by the credit-card holder whereas the account is controlled by the bank.
An owner preferably sets permissions for an Object
The permissions are preferably ordered, i.e. each permission implies the permissions above it.
Each of the four permissions may be Owner/Trusted/Public or may be granted to a specific set of UserGroupings
These permissions are preferably set at three levels:
Barring any other settings, the permissions will be:
Every Class preferably determines the default permissions for the Items in that Class differently to the above generic defaults. For each of Read, Write and Delete, the Class preferably sets a default permissions pattern of:
A Class inherits these from its Subcategories—it preferably inherits the strictest if there is more than one. If an Object belongs to more than one Class which sets default Object permissions, it will preferably inherit the strictest.
The default for Administer is preferably always Owner and preferably cannot be overriden by the Class.
The Owner or anyone with Admin permissions may preferably change the permissions for a specific Object.
Attribute permissions may be determined in three levels:
If there are no specific permissions for the Attribute and its Association then its read/write permissions will preferably be the same as the Object.
An Association preferably tells that its corresponding Attributes and values should be permissioned differently to rest of the Object. For each of read and write the Association preferably may specify one of
The owner or an Object administrator preferably overrides the Object and Assoc defaults and set any read/write permissions for the specific Attribute.
The authorization scheme just described may be further understood with the help of an example with respect to an Object of the Class Person.
For example an Object of Class Person. Person extends SelfOwned so the Owner of a Person is themselves.
By default we have:
However the Person Class might overwrite some of these. For example suppose the Person Class sets
A specific Person though may be very reliant on a certain group and very private otherwise and may override this and set
By default the Object's Attributes will inherit the Object's permissions:
However some Assoc's might change this. For example the SocialSecurity Assoc might set:
Finally the Owner may override permissions for a specific Attribute—say their name is not sensitive:
According to a second embodiment there is not one General Object Graph 114 as in
The overall design of this second embodiment may be understood by reference to
For each data provider, an adapter 2002 is provided which preferably:
The adapter may be provided by third party data provider 2001, by the provider of API 120, e.g. running within data center 100, or by a third-party.
In this design Client 111 accesses third party data either via the server 115 using API 120, directly to Data adapters 2002, or directly to third party data provider 2001. However Browser 110 may prevent direct communication between Client 111 and the domain of data adapters 2002 and/or third party data provider 2001 if Client 111 is a web page not downloaded from the same domain. Thus, preferably proxy server 2005 is provided as part of data center 100 to forward requests to data adapters 2002 and/or third party data provider 2001.
Database 113 will capture extra metadata which users of the Federated General Object Graph may want to add to data objects stored at third-parties—this includes private metadata 2011 (such as a user adding their personal tag or note on an Object) and public metadata (such as user reviews or ratings) 2010.
Additionally to the third-party services, Federated General Object Graph 118 may provide some native object oriented storage for public objects 2015 and storage for private objects 2016, e.g. using the techniques of the first embodiment of General Object Graph 114.
In another embodiment server 115 and/or database 113 may actually be run as part of Client 111 or any other combination without exceeding the scope of the invention.
Some extensions to the Metamodel of
The API for Federated General Object Graph 118 can be almost identical to the REST API described above for General Object Graph 114 just taking into account the different format of OID's and composite values.
In Federated General Object Graph 118 there are typically two levels of APIs, the federated API 120 and the API of the specific data adapters 2002. Optionally both can use the same style optionally with just different domains.
API 120 for General Object Graph 114 can be extended with user metadata to achieve Federated General Object Graph 118. Extra APIs may be supported for creating records in Public metadata 2010 and Private Metadata 2011.
For example:
POST http://federated-general-object-graph.com/objects/{OID=serviceProviderID-accountId-ObjectID}/tags?newTag=Personal
Associated with a Third-Party data provider 2001 there is preferably data source metadata which may be coupled to data adapter 2002 and provided by the Third-Party data provider 2001, by the provider of Federated General Object Graph 118a or even by a third party. The data source metadata provides details of the capabilities and of the specific API of the data source. Optionally, two separate sets of metadata are provided: one for the underlying Third-Party data provider 2001, which may not be compliant to a standard API, and one for data adapter 2002, which optionally has a more standard API wrapping the API of Third-Party data provider 2001.
Preferably the data source metadata is put in an XML file made available at a URL using a standard Web server. In this way a user who wants to add a data source to the system, whether an administrator adding a source for everyone's use, or a user adding a source for their own personal use, needs only specify the URL of the drive metadata file and the system will be able to read all parameters of the drive from that URL. Advantageously, by placing metadata in an XML file on the Web, search engines can find the new data source. Such metadata can be supplied either by Third-Party data provider 2001 or by a third party.
Metadata for a data source might include:
The function of data adapters 2002 has been described above in relation to
In one embodiment, metadata is added to an object stored with a Third-Party data provider 2001, by created in one of public objects stores 2015 and provide objects store 2016 a new extender Object. The extender Object extends a third-party Object in accordance with the extended Metamodel, as described above in relation to
In an alternative embodiment, each of public metadata 2010 and private metadata 2011, as described above in relation to
The role of the server or servers 115 is to implement the business logic layer of the Federated General Object Graph 118, preferably using a well known 3-tier architecture of persistence/business logic/presentation.
Requests will come into server 115 from API 120 and be processed accordingly, being forwarded as required to database 113 or to data adapter 2002, or alternatively to consult the data source metadata and use the data source metadata to formulate a request directly to third-party data provider 2001.
For example a user may use the navigator, described above in relation to
POST http://general-object-graph.com/{OID}/attributes/{attribute-name}, with the attribute value in the body of the POST
Server 115 will process the OID to retrieve the respective identifier for Third-party data provider 2001, e.g. ThirdPartyInc, and look up the service provider API in an optional directory of service providers and data sources. Alternatively the actual URL of the data source or of its metadata maybe part of the URL. The server logic will then POST a request such as:
POST http://adapter-for-ThirdPartyInc.com/{service provider's id}/attributes/{attribute-name}
Data adapter 2002 converts this into a call to the service provider's proprietary API. Optionally some or all of data adapter 2002 may be soft-coded, such as in the format of tables, to map the class and association names used by Federated General Object Graph 118 to those used by the data source provider.
In an alternative workflow, Client 111 will actually call adapter-for-ThirdPartyInc.com directly or via proxy server 2005.
Optionally, server 115 offers some features which are not passed on to one Third-Party data provider 2001 but federated to several e.g. using parallel execution threads. This include, without limitation, some or all of:
In one embodiment, the schema in Federated General Object Graph 118, i.e. the Class and Associations, are only allowed in a centrally stored aspect of the graph e.g. in the central public objects store 2015.
In another embodiment all data sources of database 113 may have schema Objects, and Objects from one data store may point at schema Objects from another.
The navigator for Federated General Object Graph 118, as described above in relation
It will be appreciated that icons for Federated General Object Graph 118 may be general or may be specialized to specific Classes or sources and may be embedded as components in general applications.
In certain embodiments, as described above, database 113 includes a directory of available Third-Party data providers 2001 and all their metadata. It may be hard coded as an application or soft-coded as part of the schema and objects of the General Object Graph.
It will be appreciated by those skilled in the art that object-oriented inheritance can be conveniently used to add many specific schemes. By way of a non-limiting example DigitalAccessAuthentication is one way to authenticate API calls.
Server 115, or Client 111 on behalf of the user, or data adapter 2002, may need to make API calls to Third-Party data providers 2001 or other service. In one embodiment the user has Objects stored with the Third-Party data provider 200 which are accessible using an API such as WebDAV.
The API call will typically require authentication especially if the Objects are private. Cookies are not usually used—more often the calling party will ‘digitally sign’ the call by attaching a digest of the call together with the username and password or using a sessionID, using known cryptographical techniques.
In one particular embodiment, Federated General Object Graph 118 is coupled to an identity management functionality such that a user may store their third-party login credentials (in a format such as: user id, service provider id, username, password) in identity repository 1006 and optionally also cached in client 111. The identity management functionality may be hard coded as an application or soft-coded as part of the schema and objects of the General Object Graph. One possible model for the identities (and associated sessions described below) are the classes ThirdPartyIdentity and ThirdPartySession shown in
A plurality of embodiments are now described which enable the use of identity repository 1006 to achieve SSO:
In, every one of these four approaches there are common steps, detailed below.
Much of the description has assumed that a single Client 111 is used to navigate all data sources. In another embodiment a third party Object explorer client is embedded. In one particular further embodiment the third party Object explorer client is embedded using HTML iframes or pop-up windows.
A typical workflow is as follows, as illustrated in
In accordance with certain embodiments of the inventions, a user interface, such as a home application, associated with Federated General Object Graph 118 helps the user to create accounts with third party data source providers. In one particular embodiment, this involves referring the user to the third-party's sign-up page opened e.g. in an iframe or pop-up window. Furthermore, in certain embodiments, signUpUrl may be an additional attribute of the metadata for a data source.
In one particular embodiment, third-party accounts are made using an API call. In an non-limiting example an API may be a POST with tags equivalent to:e
For each such parameter a tag name and an indicator or required/optional/not-supported may be all be added to app directory 2030 so that there is enough data for automatic sign-up to the third-party.
Preferably the home application will digitally sign calls to the third-party sign-up API so that the third-party can trust the call. Preferably it is up to the home application, associated with Federated General Object Graph 118, to require a “captcha” test to validate that the user is human.
Thus, the present embodiments enable a General Object Graph for sharing structured data between users and between applications and for social networking between the users, an associated graphical user interface and application to a virtual file system with an associated authorization scheme. A distributed version of the General Object Graph is also presented known as a Federated General Object Graph.
It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable sub-combination.
Unless otherwise defined, all technical and scientific terms used herein have the same meanings as are commonly understood by one of ordinary skill in the art to which this invention belongs. Although methods similar or equivalent to those described herein can be used in the practice or testing of the present invention, suitable methods are described herein.
All publications, patent applications, patents, and other references mentioned herein are incorporated by reference in their entirety. In case of conflict, the patent specification, including definitions, will prevail. In addition, the materials, methods, and examples are illustrative only and not intended to be limiting.
The terms “include”, “comprise” and “have” and their conjugates as used herein mean “including but not necessarily limited to”.
It will be appreciated by persons skilled in the art that the present invention is not limited to what has been particularly shown and described hereinabove. Rather the scope of the present invention is defined by the appended claims and includes both combinations and sub-combinations of the various features described hereinabove as well as variations and modifications thereof, which would occur to persons skilled in the art upon reading the foregoing description
This application claims priority from U.S. Provisional Patent Application Ser. No. 60,893,968 filed Mar. 9, 2007, entitled “VIRTUAL HOSTED OPERATING SYSTEM” the entire contents of which is incorporated herein by reference. This application is further related to the following co-pending, co-filed and co-assigned patent applications, the entire contents of each of which are incorporated herein in their entirety by reference: “A VIRTUAL IDENTITY SYSTEM AND METHOD FOR WEB SERVICES”, docket GHO-005-PCT; “VIRTUAL FILE SYSTEM FOR THE WEB” docket GHO-006-PCT; “SYSTEM AND METHOD FOR BROWSER WITHIN A WEB SITE AND PROXY SERVER” docket GHO-008-PCT; and “SYSTEM AND METHOD FOR A VIRTUAL HOSTED OPERATING SYSTEM” docket GHO-009-PCT.
| Filing Document | Filing Date | Country | Kind | 371c Date |
|---|---|---|---|---|
| PCT/IL08/00320 | 3/9/2008 | WO | 00 | 2/6/2010 |
| Number | Date | Country | |
|---|---|---|---|
| 60893968 | Mar 2007 | US |
