Patent Application
20090049379
The assignees of the present patent application have developed a pipe specification editor and execution engine which is disclosed in co-pending U.S. patent application Ser. No. 11/613,960—the '960 application—having Attorney Docket Number YAH1P039 and filed Dec. 20, 2006. The '960 application is incorporated herein by reference in its entirety. While the '960 disclosure and related material are discussed in this Background, this discussion is not meant to state or imply that the '960 disclosure and related material are prior art to the present patent application.
The disclosed pipe specification editor system provides a graphical user interface to receive a user-specified configuration—a pipe—to accomplish aggregating and manipulate syndication data feeds. More particularly, the disclosed pipe specification editor system may be used to create syndication feed data “mashups” to combine content from more than one source, including at least one syndication data feed, into an integrated experience.
Furthermore, not only may users create pipes for their own immediate use but, in addition, users may save pipes and “call” them like any other syndication date feed. A pipe may be published to be shared with other users, allowing other users to clone the pipe, add their own improvements to the pipe, or use the pipe as a subcomponent in their own created pipes.
A hosted pipe is a web-based interface that allows a user to execute a pipe that the user or another user has configured and published. This is a useful mechanism for quickly determining what type of content a pipe outputs. It is also a jumping off point for subscribing to a pipe in a feed reader, viewing how the pipe was constructed, or cloning the pipe for further modification.
In accordance with an aspect, a method is provided to operate a user interface configured for browsing pipes. The pipes are characterized by a plurality of metadata values, the plurality of metadata values including metadata values not discernible from the pipes themselves. Display is caused of a first list of pipe indications for pipes characterized by metadata values, of at least a first category of metadata, satisfying particular criteria. Also, display is caused of a first list of metadata values for at least a second category of metadata, other than the first category of metadata, the pipes of the first list of pipe indications being categorized by the metadata values of the first list of metadata values.
A selection may be received of at least one of the metadata values of the first list of metadata values. Display is caused of a second list of pipe indications characterized by the selected at least one of the metadata values of the received first list of metadata values. Furthermore, display may be caused of a second list of metadata values, the pipes of the second list of pipe indications being categorized by the metadata values of the second list of metadata values.
In some examples, each pipe of the second list of pipe indications is a member of the first list of pipes indications. In some examples, at least some pipes of the second list of pipe indications are not a member of the first list of pipe indications.
The metadata values list display causing and the pipe indications list display causing may be repeated, to thereby accomplish drilling down into the pipes of the first list of pipe indications.
The categories of pipes metadata may include, for example, attributes of the pipe specification itself, attributes by which the pipes have been characterized by users of the pipes, and attributes characterizing execution of the pipes.
There can be many pipes available for use by a user. The inventors have realized that it would be desirable for the user to be able to select a pipe to use, from the many available pipes, based on metadata characterizing the pipes. The metadata includes metadata that is not discernible from the pipe specification itself including, for example, “tags” provided by a pipe author or other users, running time of the pipe, and many other metadata.
The execution of a pipe may be more generally characterized as a “retrieve and process” operation. That is, the pipe execution processing makes “calls” to other services (e.g., via available API's) to mix and match from multiple data sources (which, in a specific example, are syndication data feeds). More generally, it may be desirable for a user of “retrieve and process” specifications to be able to select a specification for use based on metadata characterizing the specifications, including metadata not discernible from the specifications themselves.
Returning now to
Returning to
While the
In addition, it should be noted that, when a particular metadata value is selected, the displayed list of pipe indications (such the list 302 of pipe indications) may be limited to be a subset of previous list of pipe indications (such as the list 202 of pipe indications). In this manner, by selecting a particular metadata value, a “drill down” into the pipes may be accomplished. That is, each time a particular metadata value is selected, the resulting list of pipe indications is a subset of the previous list of pipe indications, and only those pipes characterized by the selected metadata value are indicated in the resulting list.
In some examples, the resulting list of pipe indications is independent of the previous list of pipe indications. Thus, in one example, when a particular metadata value is selected, the resulting list indicates all pipes (e.g., from some global set of pipes) characterized by the selected metadata value and is not limited to being a subset of the previous list of pipe indications.
In browsing the pipe specifications 408, the user 402 is presented a list of pipe indications and one or more lists of corresponding pipe specification metadata values. An indication of user selection of metadata values is provided to the pipe specification service 404 and, based on the pipe specifications 408 and the pipe specification metadata 410, an appropriate list of pipe indications and one or more lists of metadata values are provided to the user 402.
Thus far, we have discussed browsing in the particular context of pipe specifications such as may be created and/or used as disclosed in the '960 application referenced in the Background. A specification of a pipe may be more generally characterized as a specification of a “retrieve and process” operation. That is, the pipe execution processing makes “calls” to other services (e.g., via available API's) to mix and match from multiple data sources (which, in a specific example, may include syndication data feeds). Each specification may have associated metadata values, including metadata values that are not discernible from the specifications themselves.
We thus described a method/system for a user to be able to select a specification to use, from the many available specifications, based on metadata characterizing the specifications. The metadata includes metadata that is not discernible from the specification itself including, for example, “tags” provided by a specification author or other users, running time of the pipe, and many other metadata.
Embodiments of the present invention may be employed in any of a wide variety of computing contexts to provide supplemental material that is appropriate to a nominal expected retrieval and processing time and/or is appropriate to a nominal expected content of the processed specifications for mixing and matching data resulting from various web service calls s. For example, as illustrated in
According to various embodiments, applications may be executed locally, remotely or a combination of both. The remote aspect is illustrated in
The various aspects of the invention may also be practiced in a wide variety of network environments (represented by network 512) including, for example, TCP/IP-based networks, telecommunications networks, wireless networks, etc. In addition, the computer program instructions with which embodiments of the invention are implemented may be stored in any type of computer-readable media, and may be executed according to a variety of computing models including, for example, on a stand-alone computing device, or according to a distributed computing model in which various of the functionalities described herein may be effected or employed at different locations.
