Patent Application
20130166550
The present disclosure relates generally to tagging data, or “tags”, and more specifically, to the integration of tagging data with the object data described by the tagging data to increase the overall functionality of the object data.
Oftentimes, when a computer system user (such as an end user or a user involved more intimately with the design or maintenance of the computer system) accesses data, the user may provide additional data descriptive of the original data being accessed. Typically, this descriptive data is called a “tag” or “tagging data.” Some examples of tagging data include, but are not limited to, user comments regarding the original data, a user rating of the original data, marking of one or more specific portions of the original data, and so on. Typically, this tagging data may be a simple text string providing a comment about the original data, or a typed tag with an associated value (for example, a value of “red” associated with a tag type of “color”).
Depending on the particular environment, the tagging data may be stored separately and reference the original data, or may be attached in some fashion to the original data being described. However, under either scenario, the tagging data collectively represents a “data silo” separate from the original data, as the tagging data typically resides within a different logical “layer” of the environment from the original data, and is thus written, accessed, and viewed as an entity separate from the original data. For example, a particular application that provides and owns a set of original data ordinarily does not foresee or provide any infrastructure for any associated tagging data. As a result, the original data and the tagging data are typically processed or handled by different applications or modules.
The present disclosure is illustrated by way of example and not limitation in the figures of the accompanying drawings, in which like references indicate similar elements and in which:
The description that follows includes illustrative systems, methods, techniques, instruction sequences, and computing machine program products that embody illustrative embodiments. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be evident, however, to those skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction instances, protocols, structures, and techniques have not been shown in detail.
At least some of the embodiments described herein provide various techniques for generating and using tagging data (or, alternatively, data “tags”) that is integrated with one or more data objects. Examples of the tagging data may include, but are not limited to, comments, ratings, categorizations, quantifications, and other characterizations of the data object being tagged.
As is described in greater detail below, a first data object (such as, for example, a business or general-purpose record or file) that is employed in a first computer application is accessed. Also accessed is tagging data that is descriptive of the first data object. As is described below, the tagging data may be provided by a user, or may be generated automatically. The tagging data is stored in at least one of the first data object or a separate data object linked with the first data object such that the tagging data and the first data object may be processed using a second computer application. As a result, the tagging data may be accessed and employed by an application in much the same way as the original data object being tagged, thereby enhancing the value of both the original data and its associated tagging data. Other aspects of the embodiments discussed herein may be ascertained from the following detailed description.
Turning specifically to the enterprise application platform 112, web servers 124, and Application Program Interface (API) servers 125 are coupled to, and provide web and programmatic interfaces to, application servers 126. The application servers 126 are, in turn, shown to be coupled to one or more database servers 128 that may facilitate access to one or more databases 130. The web servers 124, Application Program Interface (API) servers 125, application servers 126, and database servers 128 may host cross-functional services 132. The application servers 126 may further host domain applications 134.
The cross-functional services 132 may provide user services and processes that utilize the enterprise application platform 112. For example, the cross-functional services 132 may provide portal services (e.g., web services), database services, and connectivity to the domain applications 134 for users that operate the client machine 116, the client/server machine 117, and the small device client machine 122. In addition, the cross-functional services 132 may provide an environment for delivering enhancements to existing applications and for integrating third party and legacy applications with existing cross-functional services 132 and domain applications 134. Further, while the system 110 shown in
The portal modules 240 may enable a single point of access to other cross-functional services 132 and domain applications 134 for the client machine 116, the small device client machine 122, and the client/server machine 117 of
The relational database modules 242 may provide support services for access to the database 130 (
The connector and messaging modules 244 may enable communication across different types of messaging systems that are utilized by the cross-functional services 132 and the domain applications 134 by providing a common messaging application processing interface. The connector and messaging modules 244 may enable asynchronous communication on the enterprise application platform 112.
The Application Program Interface (API) modules 246 may enable the development of service-based applications by exposing an interface to existing and new applications as services. Repositories may be included in the platform as a central place to find available services when building applications.
The development modules 248 may provide a development environment for the addition, integration, updating, and extension of software components on the enterprise application platform 112 without impacting existing cross-functional services 132 and domain applications 134.
Turning to the domain applications 134, the customer relationship management applications 250 may enable access to and facilitate collecting and storing of relevant personalized information from multiple data sources and business processes. Enterprise personnel that are tasked with developing a buyer into a long-term customer may utilize the customer relationship management applications 250 to provide assistance to the buyer throughout a customer engagement cycle.
Enterprise personnel may utilize the financial applications 252 and business processes to track and control financial transactions within the enterprise application platform 112. The financial applications 252 may facilitate the execution of operational, analytical, and collaborative tasks that are associated with financial management. Specifically, the financial applications 252 may enable the performance of tasks related to financial accountability, planning, forecasting, and managing the cost of finance.
The human resources applications 254 may be utilized by enterprise personal and business processes to manage, deploy, and track enterprise personnel. Specifically, the human resources applications 254 may enable the analysis of human resource issues and facilitate human resource decisions based on real-time information.
The product life cycle management applications 256 may enable the management of a product throughout the life cycle of the product. For example, the product life cycle management applications 256 may enable collaborative engineering, custom product development, project management, asset management, and quality management among business partners.
The supply chain management applications 258 may enable monitoring of performances that are observed in supply chains. The supply chain management applications 258 may facilitate adherence to production plans and on-time delivery of products and services.
The third-party applications 260, as well as legacy applications 262, may be integrated with domain applications 134 and utilize cross-functional services 132 on the enterprise application platform 112.
The tagging module 302 may perform any of the functions related to the tagging of data objects, including the generation, storage, maintenance, and/or use of the tagging data. In one example, the tagging module 302 directs or controls such functions via a data object/tagging model 303, an example of which is discussed below in conjunction with
The user interface module 304 may provide a user, such as, for example, an end-user, administrator, content manager, or programmer, access to the tagging data and the associated object data. Such access may include the reading and/or writing of the tagging data and the associated object data, the specifying of possible types of tagging data to be associated with the object data, and other functions requiring access to the tagging data.
The first application 306 may generate and/or use the data object to be tagged. Examples of the first application 306 may include enterprise business applications, such as those depicted as domain applications 134 in
The second application 308 may generate or use the data object and its associated tagging data to provide some computer-related functionality. In some examples, by accessing both the data object and the corresponding tagging data, the second application 308 may be capable of providing greater functionality than what may be possible with accessing the data object alone. In one implementation, the tagging module 302, the first application 306, and the second application 308 may reside in different logical layers of a software hierarchy, with the second application 308 located above the tagging module 302, which is itself located above the first application 306, as shown graphically in
The database module 310 may facilitate the storage and retrieval of both the data objects and the tagging data. One example of the database module 310 is a relational database, but any other type of storage facility capable of performing the various storage and retrieval functions commensurate with the various examples discussed below may also serve as the database module 310. For example, the database module 310 may be a data persistency module in which searchable data “indexes”, such as data tables or database “joins” and “views” that store data objects and their associated tagging data. In some cases, such data may be stored in the memory of a server or other system, as opposed to an externally-located database, thus facilitating faster read and write access to the data objects and associated tags.
In the method 400, a first data object employed in a first application is accessed (operation 402). The first application, such as the first application 306 of
In some implementations, a user provides or specifies the tagging data, such by way of the user interface module 304 of
Continuing with the method 400, the tagging data is stored (operation 406). In an implementation, the tagging data may be stored within the data object being tagged. In another example, the tagging data may be stored in a separate data object that is linked to, logically coupled with, or otherwise references the first data object. The tagging data and the first data object may then be processed using a second application (operation 408), such as the second application 308 of
While the operations of the method 400 of
In one example, the first application involving the method 400 may be an application that generates text stored in the data objects, such as a word processing application, a spreadsheet program, or the like. The second application may be a search application providing a mechanism by which a user may employ both the data objects and the tagging data to facilitate a more useful and focused search than what may be possible via the data objects alone. In one example, the second application may be viewed as being located in a higher logical level of an application hierarchy above the first application, thus allowing the second application (in this case, a search application) the visibility to access both the data objects and their associated tagging data, as discussed above with respect to
Each of
In some examples, each of the tags 501A, 501B, and 501C may be implemented as a data object separate from the one or more data objects associated with the tag 501, as shown in
Depending on the type of tagging to be performed, more than one of the tagging formats 500A, 500B, and 500C may be employed for a particular tag. For example, tagging a document file represented by a data object 504 with the name of an author can be accomplished by any of tagging by value 500A (by using the name of the author as a tag value 502), tagging by type 500B (by using the name of the author as a tag value 502, and a tag type 503 of “author”), and tagging by object 500C (by using a tag 501C to link the data object 504 for the document with a second data object 506 representing the author). In some implementations, the tagging module 302 (
By integrating multiple types of tagging data with the data objects, as noted above, relationships between and among the data objects may be made more freely, either automatically, by way of user input, or both, depending on the particular implementation, thus allowing more effective access and use of the data objects.
In the model 600, a number of software connectors 602 through 610 may facilitate communication between the various data objects, tagging data, and associated data structures, and one or more applications or modules. As shown in
Connectors 606 and 610 are connectors for the first carrier object 616 and the second carrier object 618, respectively. Each of these connectors 606, 610 is communicatively coupled with a tag-by-object link connector 608, which facilitates communication with a tag-by-object link 622 linking the first carrier object 616 and the second carrier object 618.
Each of the tagging data objects 620, 622, 624 is coupled with a tagging attributes object 620A, 622A, 624A, respectively. Each of the tagging attributes objects 620A, 622A, 624A provides additional information regarding the tagging data itself, such as, for example, a user that has provided the tagging data. In one implementation, the data attributes include an identity of the user and a rating regarding the effectiveness of the user as a provider of tagging information. In one implementation, this information may be regarded and employed as tagging data describing the provider of other tagging data.
In the specific example emphasized in
Each of the document object 616 and the supplier object 618 are coupled to tagging data in tag-by-type valuations 620, 624, respectively. In the data object/tagging model 600 of
The tag-by-type valuation 620 for the document includes three separate tags: a comment (“Great!”), a file size (“147 MB”), and a file type (“pptx”). The types associated with each of the tags of the valuation 620 are defined in the tag type structure 614. More specifically, the comment is of a type “<any>,” which essentially is an unclassified type, similar to the tagging by value discussed above. The file size value (“147 MB”) is associated with the “file size” type denoted in the tag type structure 614. This particular tag type can be any value useful as a file size, and thus is not limited to a particular set of values. The file type value (“pptx”), on the other hand, is selected from a list of values specifically associated with the “file type” type. This list is defined in the tag type value list 612 coupled to the tag type structure 614. More specifically, the file type is associated with three distinct values: xlsx, docx, and pptx. In this case, the pptx value is selected for the tag-by-type valuation 620 to indicate the file type of the document.
As mentioned earlier, the tagging data may be generated by a user, or generated automatically by the tagging module 302 (
The supplier of the document (“Company A”), represented by the second carrier object 618, is also tagged by way of the tag-by-type valuation 624. The details regarding the associated tagging data are not provided in
The document, represented by the first carrier object 616, is also tagged by way of tagging-by-object. More specifically, the tag-by-object link 622 tags the first carrier object 616 by linking the first carrier object 616 with the second carrier object 618 representing the supplier of the document. The link 622 may be explicitly defined by a user, or may be generated automatically, such as when the document (as well as the associated carrier object 616) is created or stored, based on information provided in the document itself, or based on data generated upon the creation or storage of the document.
As shown in the example of
Further, the integration of the tagging data of
The specific tagging attributes 620A, 622A associated with the tag-by-type valuation 620 and the tag-by-object link 622, respectively, signify the user associated with each tag 620, 622 (namely, “John D.” and “Jane D.”, respectively), as well as a rating associated with either the user or the tagging data itself (three stars and four stars, respectively). In some implementations, another user may utilize this information to ascertain a confidence level in the tagging data, or to contact the user responsible for the tagging data to retrieve more information regarding the tagging of the associated data object.
During configuration of the model (operation 704), various configuration parameters may be defined. An implementation of such parameters may include, for example, identification of the computer systems, data providers, data objects, tagging data, and various connections therebetween by way of the model may be configured. In one particular example, the configuration parameters may allow the linking of files stored on, or accessible via, a test server to business objects of a testing system, but not to business objects of a production system, thus providing a level of security in the generation and use of the tagging data.
At runtime (operation 706), the tagging data associated with one or more data objects is created and stored according to the model previously created and the configuration parameters. Along with the creation and storing of the tagging data, one or more application may employ the tagging data and corresponding data objects to perform one or more tasks, such as searching of the data objects and tagging data, as discussed above.
In some implementations, the administrator 801 may generate and provide one or more tag type groups. Each group may include multiple tag types that are related in some fashion, or that may even be deemed “synonyms” of each other. For example, the name of a particular tag type may have changed over time, even though the newer version of the tag type represents the same tag value information as a preceding version of the tag type. As a result, tag types of the same group may be viewed or searched as though they represent the same tag type.
In
In at least some embodiments discussed herein, the integration of tagging data and associated data objects allows both types of data to be accessed and used in a single, cohesive, seamless manner, thus enhancing the use of both the data objects and corresponding tagging data. Such integration may also result in uniform access and presentation of both the data objects and the tagging data, either via a user interface to a user, an API to an application, or other means. More specifically, the integrated tagging data may also facilitate enhanced searching and navigation of the data objects, such as in the example of the document and related supplier discussed above in conjunction with
The machine is capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
The example of the processing system 900 includes a processor 902 (for example, a central processing unit (CPU), a graphics processing unit (GPU), or both), a main memory 904 (for example, random access memory), and static memory 906 (for example, static random-access memory), which communicate with each other via bus 908. The processing system 900 may further include video display unit 910 (for example, a plasma display, a liquid crystal display (LCD), or a cathode ray tube (CRT)). The processing system 900 also includes an alphanumeric input device 912 (for example, a keyboard), a user interface (UI) navigation device 914 (for example, a mouse), a disk drive unit 916, a signal generation device 918 (for example, a speaker), and a network interface device 920.
The disk drive unit 916 (a type of non-volatile memory storage) includes a machine-readable medium 922 on which is stored one or more sets of data structures and instructions 924 (for example, software) embodying or utilized by any one or more of the methodologies or functions described herein. The data structures and instructions 924 may also reside, completely or at least partially, within the main memory 904, the static memory 906, and/or within the processor 902 during execution thereof by processing system 900, with the main memory 904 and processor 902 also constituting machine-readable, tangible media.
The data structures and instructions 924 may further be transmitted or received over a computer network 950 via network interface device 920 utilizing any one of a number of well-known transfer protocols (for example, HyperText Transfer Protocol (HTTP)).
Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. Modules may constitute either software modules (for example, code embodied on a machine-readable medium or in a transmission signal) or hardware modules. A hardware module is a tangible unit capable of performing certain operations and may be configured or arranged in a certain manner. In example embodiments, one or more computer systems (for example, the processing system 900) or one or more hardware modules of a computer system (for example, a processor 902 or a group of processors) may be configured by software (for example, an application or application portion) as a hardware module that operates to perform certain operations as described herein.
In various embodiments, a hardware module may be implemented mechanically or electronically. For example, a hardware module may include dedicated circuitry or logic that is permanently configured (for example, as a special-purpose processor, such as a field-programmable gate array (FPGA) or an application-specific integrated circuit (ASIC)) to perform certain operations. A hardware module may also include programmable logic or circuitry (for example, as encompassed within a general-purpose processor 902 or other programmable processor) that is temporarily configured by software to perform certain operations. It will be appreciated that the decision to implement a hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (for example, configured by software) may be driven by cost and time considerations.
Accordingly, the term “hardware module” should be understood to encompass a tangible entity, be that an entity that is physically constructed, permanently configured (for example, hardwired) or temporarily configured (for example, programmed) to operate in a certain manner and/or to perform certain operations described herein. Considering embodiments in which hardware modules are temporarily configured (for example, programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, where the hardware modules include a general-purpose processor 902 that is configured using software, the general-purpose processor 902 may be configured as respective different hardware modules at different times. Software may accordingly configure a processor 902, for example, to constitute a particular hardware module at one instance of time and to constitute a different hardware module at a different instance of time.
Modules can provide information to, and receive information from, other modules. For example, the described modules may be regarded as being communicatively coupled. Where multiples of such hardware modules exist contemporaneously, communications may be achieved through signal transmissions (such as, for example, over appropriate circuits and buses) that connect the modules. In embodiments in which multiple modules are configured or instantiated at different times, communications between such modules may be achieved, for example, through the storage and retrieval of information in memory structures to which the multiple modules have access. For example, one module may perform an operation and store the output of that operation in a memory device to which it is communicatively coupled. A further module may then, at a later time, access the memory device to retrieve and process the stored output. Modules may also initiate communications with input or output devices, and can operate on a resource (for example, a collection of information).
The various operations of example methods described herein may be performed, at least partially, by one or more processors 902 that are temporarily configured (for example, by software) or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors 902 may constitute processor-implemented modules that operate to perform one or more operations or functions. The modules referred to herein may, in some example embodiments, include processor-implemented modules.
Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of a method may be performed by one or more processors 902 or processor-implemented modules. The performance of certain of the operations may be distributed among the one or more processors 902, not only residing within a single machine but deployed across a number of machines. In some example embodiments, the processors 902 may be located in a single location (for example, within a home environment, within an office environment, or as a server farm), while in other embodiments, the processors 902 may be distributed across a number of locations.
While the embodiments are described with reference to various implementations and exploitations, it will be understood that these embodiments are illustrative and that the scope of claims provided below is not limited to the embodiments described herein. In general, the techniques described herein may be implemented with facilities consistent with any hardware system or hardware systems defined herein. Many variations, modifications, additions, and improvements are possible.
Plural instances may be provided for components, operations, or structures described herein as a single instance. Finally, boundaries between various components, operations, and data stores are somewhat arbitrary, and particular operations are illustrated in the context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within the scope of the claims. In general, structures and functionality presented as separate components in the exemplary configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the claims and their equivalents.
