This disclosure relates generally to electronic document management systems, and more specifically to techniques for identifying electronic documents having nearly duplicative content and generating a revision history timeline for such content.
Computers and electronic documents have become an increasingly indispensable part of modern life. In particular, electronic documents, which serve as virtual storage containers for binary data, have gained acceptance not only as a convenient replacement for conventional paper documents, but also as a useful way to store a wide variety of digital assets such as multimedia assets, webpages, financial records, and electronic correspondence. The increased use of electronic documents has resulted in the adaptation of conventional paper-based document processing workflows to the electronic realm. As a result, a wide variety of software applications have been developed to facilitate the process of managing electronic documents and the workflows in which such documents are used. Examples of such applications include electronic document management systems and content management systems, both of which can store and track the revision history of a collection of electronic documents from a central interface. Content management systems also often provide procedures for managing workflows that use the aforementioned digital assets in a collaborative environment. Such workflow management may include designating user groups which are granted rights to take certain actions with respect to one or more electronic documents. Examples of commercially available content management systems include Adobe Experience Manager (Adobe Systems Incorporated, San Jose, Calif.) and Microsoft SharePoint (Microsoft Corporation, Redmond, Wash.).
Existing electronic document management systems and content management systems provide a wide range of tools which help users manage and interact with content items stored in an electronic content repository. However, despite the variety and complex nature of such tools, the process of locating a particular desired piece of information within a content repository still often presents significant challenges. Furthermore, merely locating a particular document does not necessarily provide knowledge with respect to how content provided within that document relates, if at all, to content stored in other documents. More generally, existing document management systems often rely on a document-based approach to organizing content that provides robust version control of a particular document, but that lacks the ability to reliably detect and present information with respect to how content provided in two different documents might be related. This inability to link content in different documents is especially problematic where different versions of content may appear to the document management system as distinct files originating from different sources. This may occur, for example, where a first version of a document is downloaded from a cloud-based storage repository, a second version is received via email, and a third version copied from a universal serial bus (USB) flash memory drive. In this case, a user would be required to manually apply version control to the individual documents, which relies not only on the user's diligence, but also on the user's accurate tracking of which documents have related content. The resulting high likelihood of user error makes this solution highly unsatisfactory.
Thus, and in accordance with certain of the embodiments disclosed herein, techniques are provided for automatically identifying electronic documents having nearly duplicative content and generating a revision history timeline for such content. For example, in certain embodiments a document management system can be configured to associate content provided within a managed document with a content-based revision history timeline. Multiple documents may be associated with the timeline, wherein each of the documents contains content that is nearly duplicative with respect to content contained in at least one other associated document. When the document management system receives a new document, the content within that document is parsed and compared with other content managed by the document management system. Where nearly duplicative content is detected, documents containing such content are grouped together in the same revision history timeline. If no nearly duplicative content is detected, a new revision history timeline is created.
When the document management system receives an updated version of an existing document, the existing document is removed from any existing revision history timelines and the new version is parsed and analyzed as a new document. This may occur, for example, where a user checks-out a document, modifies it, and checks-in the modified version of the document. The document management system recognizes that an updated version of the document has been received as a result of the same document being checked-in and checked-out. In this case, the older version of the document is removed from existing timelines so that the timelines reflect content-based relationships based on the most recent version of the documents managed by the document management system. This avoids confusion where a document modification causes the most recent version of a given document to no longer relate to another managed document, thereby severing the content-based relationship. In an alternative embodiment, revision history timelines can be generated on the basis of older document versions which are archived by the document management system.
Document metadata, such as creation and modification times, can be used to arrange multiple documents on a single timeline in a logical way. The resulting revision history timelines can be rendered in response to certain user commands, such as document check-out from the document management system, thereby providing users with a visual understanding of how content contained within a given document relates to content contained in other documents managed by the document management system. Numerous configurations and variations of the content-based revision history timelines disclosed herein will be apparent in light of this disclosure.
The disclosed content revision history timelines provide several advantages with respect to existing electronic document management systems and content management systems. In particular, the solutions disclosed herein recognize that users often produce multiple versions of a single document when creating content. This may occur, for example, as a result of working at separate home and office computers, exchanging revised versions of a document via email, renaming works-in-progress, and exporting different versions of a document to different file formats. Existing systems emphasize tracking of file operations performed on a particular document and therefore do not necessarily recognize differently named files or differently formatted files as containing related content. In contrast, certain of the disclosed embodiments allow a content revision history timeline to be derived based on detecting nearly duplicative content existing in a variety of locations, such as a cloud-based storage repository, an email server, and one or more client-based local storage devices. And as part of this analysis, content can be extracted from a variety of file types, including word processing files, email files, hypertext markup language (HTML) files, text files, and portable document format (PDF) files. This broad-based approach of detecting a wide variety of different content types from a wide variety of different content sources increases content discoverability and allows a more robust content history to be derived. For example, in certain embodiments a document management system is configured to detect nearly duplicative content from several different storage resources without user intervention, therefore providing a more reliable user experience than existing systems that require manual version control of documents downloaded from, for example, an email server or a cloud-based sharing service. Ultimately, this enables users to accurately trace the evolution of content across different files and media repositories, thereby producing a content revision history rather than a document revision history.
As used herein, the term “content” refers, in addition to its ordinary meaning, to information intended for direct or indirect consumption by a user. For example, the term content encompasses information directly consumed by a user such as when it is displayed on a display device or printed on a piece of paper. The term content also includes information that is not specifically intended for display, and therefore also encompasses items such as software, executable instructions, scripts, hyperlinks, addresses, pointers, metadata, and formatting information. The use of the term content is independent of (a) how the content is presented to the user for consumption and (b) the software application used to create or render the content. The term “digital content” refers to content which is encoded in binary digits (for example, zeroes and ones). In the context of applications involving digital computers, the terms “content” and “digital content” are often used interchangeably.
As used herein the term “document” refers, in addition to its ordinary meaning, to an electronic container used to store a collection or subset of content. It will be appreciated that content can be stored according to a wide variety of different formats which dictate the type of document used to store the content. Examples of such formats include word processing documents, textual documents, HTML documents, and PDF documents. A document may include not only the aforementioned content itself, but also metadata describing certain aspects of the content, such as a creation timestamp, a modification timestamp, or author identification information. A document can take the form of a physical object, such as one or more papers containing printed information, or in the case of an “electronic document”, a non-transitory computer readable medium containing digital data. Electronic documents can be rendered in a variety of different ways, such as via display on a screen, by printing using an output device, or aurally using an audio player and text-to-speech software. Documents may thus be communicated amongst users by a variety of techniques ranging from physically moving papers containing printed matter to wired or wireless transmission of digital data. The terms “document” and “file” may be used interchangeably, although the term “document” is more often used to refer to containers of text-based content.
As used herein the terms “document management system” and “content management system” refer, in addition to their respective ordinary meanings, to systems that can be used in an online environment to generate, modify, publish, or maintain content that is stored in a data repository. Content management systems and document management systems can therefore be understood as providing functionalities which are particularly adapted for workflow management in an online environment, including content authoring and publication functionality for websites, software applications, and mobile applications. These functionalities, which may be provided by one or more modules or sub-modules that form part of the overarching system, may be further adapted to allow multiple users to work collaboratively with the managed content. Such systems can be used to manage a wide variety of different types of content, including textual content, graphical content, multimedia content, executable content, and application user interface elements. Content management systems and document management systems are often implemented in a client-server computing environment that allows a plurality of different users to access a central content repository where the managed content is stored.
As used herein, the term “nearly duplicative” describes a first content item which resembles a second content item, or which is roughly contained within the second content item. The concepts of “resemblance” and “containment” can be quantified according to any suitable algorithm. For example, in one embodiment the resemblance rw(A, B) of Document A and Document B is a number between zero and one such that when the resemblance is close to one, it is likely that the documents are roughly the same. Likewise, the containment cw(A, B) can be understood as a number between zero and one such that when the containment is close to one, it is likely that Document A is roughly contained within Document B. In certain embodiments the resemblance rw(A, B) and containment cw(A, B) of Document A and Document B can be quantified as
Likewise the containment cw(B, A), which represents the likelihood that Document B is roughly contained within Document A, can be quantified as
Here S(A, w) and S(B, w) refer to the set of shingles in Document A and Document B, respectively, where each shingle is of size w. Thus it will be appreciated that the parameters rw(A, B) and cw(A, B) allow the degree to which Document A and Document B are nearly duplicative to be quantified.
As used herein, the term “shingle” refers, in addition to its ordinary meaning, to a contiguous subsequence of tokens contained within a given document. More specifically, a given document can be understood as a sequence of countable tokens that may comprise letters, words, lines, or any other appropriate document fragment. A contiguous subsequence of such tokens is a “shingle”. Thus, for a given Document A, a set of shingles S(A, w) can be generated, where w is the size of each shingle. For example, if Document A comprises the words:
A=a rose is a rose is a rose, (4)
then the w-shingling of Document A, where w=4, is the bag
{(a, rose, is, a),(rose, is, a, rose),(is, a, rose, is),(a, rose, is, a),(rose, is, a, rose)}. (5)
The set of shingles S(A, 4) can be defined as the set of shingles in Document A, where each shingle is of size w=4. The 4-shingling of Document A produced a bag of five shingles, but only there of these shingles are unique. Thus
S(A,4)={(a, rose, is a),(rose, is, a, rose),(is, a, rose, is)}. (6)
A set of shingles can be understood as a condensed fingerprint or sketch of a larger document that still provides useful insight regarding the content contained within the larger document. Additional details regarding the definition of document resemblance, document containment, and shingling are provided by Andrei Z. Broder, “On the resemblance and containment of documents”, Compression and Complexity of Sequences 1997 Proceedings, pages 21-29 (June 1997).
As used herein, the term “revision history timeline” refers, in addition to its ordinary meaning, to a graphical, a textual, or a graphical and textual representation of the evolution of content over time. A revision history timeline may also be represented by metadata or other information stored in computer memory, and thus need not be rendered graphically or textually at a given point in time. The evolved content can be stored in a document, for example. Thus, in one embodiment a revision history timeline includes a linear time axis with notations indicating one or more time points corresponding to receipt, check-in or other manipulations of a document. A revision history timeline may include a plurality of documents, such as where nearly duplicative content appears in several different documents, such as in a word processing document, an email, and a journal entry. Multiple revision history timelines can intersect, such as may occur where a single document contains content that is nearly duplicative of content contained within two different documents which are included in two different timelines. An example graphical representation of three interesting revision history timelines is illustrated in
System Architecture
In one embodiment document management server 100 comprises an array of enterprise class devices configured to host documents, respond to client requests for hosted documents, and manage workflows that manipulate the hosted documents. In an alternative embodiment document management server 100 comprises a personal computer capable of providing content management functionality to one or more client computing systems 200 connected to a home or office network. In general, the hosted documents can be obtained from a wide range of networked or local document sources, including from client computing system 200. Other configurations for document management server 100 can be implemented in other embodiments. Client computing system 200, on the other hand, can be understood as comprising any of a variety of computing devices that are suitable for interaction with document management server 100, wherein such interaction includes both generation of new documents, as well as review and modification of existing documents. For example, depending on the demands and use context of a particular implementation, client computing system 200 may comprise a device such as a handheld computer, a cellular telephone, a tablet computer, a smartphone, a laptop computer, a desktop computer, a digital media player, or a set-top box. A combination of different devices can be used in alternative embodiments.
Thus, in general it will be appreciated that document management server 100 and client computing system 200 can be configured so as to provide a client-server computing environment in which the various embodiments disclosed herein can be implemented. For example, document management server 100 and client computing system 200 can be configured to communicate with each other via network 300, which may be a local area network (such as a home-based or office network), a wide area network (such as the Internet), or a combination of such networks, whether public, private, or both. Access to resources on a given network or computing system may require credentials such as usernames, passwords, or any other suitable security mechanism. For instance, in one embodiment networked computer system 10 comprises a globally distributed network of tens, hundreds, thousands, or more document management servers 100 capable of delivering hosted documents over a network of secure communication channels to an even larger number of client computing systems 200.
In accordance with the foregoing, document management server 100 and client computing system 200 each include one or more software modules configured to implement the various functionalities disclosed herein, as well as hardware that enables such implementation. Examples of enabling hardware include a processor 101, 201; a memory 102, 202; a communications module 104, 204; and a bus 105, 205. An example of one type of implementing software is an operating system 103, 203. Document management server 100 and client computing system 200 are coupled to network 300 to allow for communications with each other, as well as with other networked computing devices and resources, such as a dedicated graphics rendering server or a cloud-based storage repository. Document management server 100 and client computing system 200 can be local to network 300 or remotely coupled to network 300 by one or more other networks or communication channels.
Processor 101, 201 can be any suitable processor, and may include one or more coprocessors or controllers, such as a graphics processing unit or an audio processor, to assist in control and processing operations associated with document management server 100 and client computing system 200. Memory 102, 202 can be implemented using any suitable type of digital storage, such as one or more of a disk drive, a redundant array of independent disks (RAID) a universal serial bus (USB) drive, flash memory, random access memory, or any suitable combination of the foregoing. Thus in certain embodiments memory 102, 202 comprises a distributed system of multiple digital storage devices. In the context of document management server 100, memory 102 can be used to store a document repository 160 and a timeline repository 170. Document repository 160 provides a storage resource for documents managed by document management server 100. Timeline repository 170 comprises a data structure that correlates a given document (for instance, example Document A) with a revision history timeline (for instance, timeline T0), wherein the given document is represented by a set of shingles (for instance, S(A, w)). The organizational structure of an example implementation of timeline repository 170 will be described in turn.
Operating system 103, 203 may comprise any suitable operating system, such as Google Android (Google, Inc., Mountain View, Calif.), Microsoft Windows (Microsoft Corp., Redmond, Wash.), or Apple OS X (Apple Inc., Cupertino, Calif.). As will be appreciated in light of this disclosure, the techniques provided herein can be implemented without regard to the particular operating system provided in conjunction with document management server 100 or client communicating system 200, and therefore may also be implemented using any suitable existing or subsequently-developed platform. Communications module 104, 204 can be any appropriate network chip or chipset which allows for wired or wireless connection to network 300 and other computing devices and resources. Communications module 104, 204 can also be configured to provide intra-device communications via bus 105, 205.
Still referring to the example embodiment illustrated in
In certain embodiments document management server 100 also includes a timeline administration module 140 and a timeline generation module 150. Timeline administration module 140 is configured to associate a new or modified document with a selected revision history timeline based on a degree of similarity between the new or modified document and an existing document included in the revision history timeline. In such embodiments a document associated with a particular revision history timeline will be nearly duplicative of at least one other document included in the timeline. Timeline administration module 140 is also configured to remove documents from a revision history timeline as appropriate. Timeline generation module 150 is configured to generate a graphical representation of a revision history timeline based on the documents associated with the timeline and metadata corresponding to such documents. For example, document creation and modification times can be used to arrange multiple documents on a single timeline in a logical way. Such a graphical representation is optionally provided to client computing system 200 for review and analysis by a user.
Referring still to the example embodiment illustrated in
In certain embodiments document management user interface 280 is configured to generate a graphical user interface 282 which can be implemented with, or otherwise used in conjunction with, one or more suitable peripheral hardware components 290. In such embodiments peripheral hardware components 290 are coupled to or otherwise form part of client computing system 200. Examples of such components include a display 292, a textual input device 294 (such as a keyboard), and a pointer-based input device 296 (such as a mouse). One or more additional or alternative input/output devices, such as a touch sensitive display, a speaker, or a microphone can be used in alternative embodiments. While document management user interface 280 is illustrated in
The embodiments disclosed herein can be implemented in various forms of hardware, software, firmware, or special purpose processors. For example, in one embodiment a non-transitory computer readable medium has instructions encoded thereon that, when executed by one or more processors, allow electronic documents having nearly duplicative content to be identified, and further allow a revision history timeline for such content to be generated. The instructions can be encoded using one or more suitable programming languages, such as C, C++, object-oriented C, JavaScript, Visual Basic .NET, BASIC, or alternatively, using custom or proprietary instruction sets. Such instructions can be provided in the form of one or more computer software applications or applets that are tangibly embodied on a memory device, and that can be executed by a computer having any suitable architecture. In one embodiment the system can be hosted on a given website and implemented using JavaScript or another suitable browser-based technology.
The functionalities disclosed herein can optionally be incorporated into a variety of different software applications, such as word processing applications, desktop publishing applications, presentation applications, and web content editing applications. For example, a word processing application can be configured to display a content-based revision history timeline in response to a user command to open a document managed by a document management server. In such embodiments the word processing application can therefore be configured to implement certain of the functionalities disclosed herein to facilitate generation and display of a revision history timeline. The computer software applications disclosed herein may include a number of different modules, sub-modules, or other components of distinct functionality, and can provide information to, or receive information form, still other components and services. These modules can be used, for example, to communicate with peripheral hardware components 290, networked storage resources, or other external components. In particular, other components and functionality not reflected in the illustrations will be apparent in light of this disclosure, and it will be appreciated that the present disclosure is not intended to be limited to any particular hardware or software configuration. Thus in other embodiments the components illustrated in
The aforementioned non-transitory computer readable medium may be any suitable medium for storing digital information, such as a hard drive, a server, a flash memory, or random access memory. In alternative embodiments the computer and modules disclosed herein can be implemented with hardware, including gate level logic such as a field-programmable gate array (FPGA), or alternatively, a purpose-built semiconductor such as an application-specific integrated circuit (ASIC). Still other embodiments may be implemented with a microcontroller having a number of input/output ports for receiving and outputting data, and a number of embedded routines for carrying out the various functionalities disclosed herein. It will be apparent that any suitable combination of hardware, software, and firmware can be used, and that the present disclosure is not intended to be limited to any particular system architecture.
Methodology and User Interface
Still referring to
Method 1100 also commences with using document administration module 110 to parse Document A into set of unique shingles S(A, w), where w is the shingle size. See reference numeral 1104 in
As described herein, timeline repository 170 comprises a data structure that correlates a given existing document (for instance, Document B) with a revision history timeline (for instance, timeline T0), wherein the given existing document is represented by a set of shingles (for instance, S(B, w)). This correlation can be represented by a data pair such as {S(B, w), T0}, several of which can be stored in timeline repository 170. Thus timeline repository 170 can be understood as storing m distinct timelines. See reference numeral 1106 in
Timeline Tm′ can be understood as including n existing documents, each of which is represented by a set of shingles (for instance, S(B, w)). See reference numeral 1112 in
For example, the resemblance of newly-received Document A with existing Document B can be quantified by the parameter rw(A, B), as provided by Equation (1). If the resemblance rw(A, B) is greater than a threshold resemblance parameter R, then Documents A and B can be considered to be nearly duplicative of each other. See reference numeral 1122 in
The likelihood that newly-received Document A is contained within existing Document B can be quantified by the parameter cw(A, B), as provided in Equation (2). Similarly, the likelihood that existing Document B is contained within newly-received Document A can be quantified by the parameter cw(B, A), as provided in Equation (3). If the containment value cw(A, B) is greater than a threshold containment parameter CAB, then Documents A and B can be considered to be nearly duplicative of each other. See reference numeral 1124 in
If at least one of the conditions {r(A, B)>R or c(A, B)>CAB or c(B, A)>CBA} is true, then newly-added Document A can be considered to be nearly duplicative of existing Document B. In this case, timeline administration module 140 can be configured to add Document A to timeline Tm′ by adding the data pair {S(A, w), Tm′} to timeline repository 170. See reference numeral 1140 in
Thus the example method 1100 illustrated in
Once at least one document in each of the m timelines has been analyzed, it can be determined whether the “Included in Timeline” parameter associated with Document A is set to “true”. See reference numeral 1150 in
As described in conjunction with method 1100, timeline repository 170 can be understood as storing m distinct timelines. See reference numeral 1202 in
On the other hand, if existing Document Aold is included in timeline Tm′, timeline administration module 140 can be configured to remove Document Aold from timeline Tm′ by removing the data pair {S(Aold, w), Tm′} from timeline repository 170. See reference numeral 1214 in
On the other hand, if existing Document A is included in timeline Tm′, timeline administration module 140 can be configured to remove Document A from timeline Tm′ by removing the data pair {S(A, w), Tm′} from timeline repository 170. See reference numeral 1414 in
Referring again to
It is possible to infer a sequence of document history revision events from a revision history timeline generated according to certain of the embodiments disclosed herein. For example, as can be inferred from the example timelines illustrated in
Thus, in general, certain of the embodiments disclosed herein result in one or more revision history timelines that trace the evolution of content regardless of whether the content evolves via importing a newly introduced document or revising an existing document. The timelines in which a given document is included indicate the different content versions added to document repository 160. Multiple documents can be organized into different timelines depending on which documents are nearly duplicative of each other, as defined herein. Within a single timeline, multiple documents can be arranged according to a time-based parameter such as may be extracted from document metadata. For newly created documents, the time-based parameter can be taken as the time the document was created, or if that is unavailable, the time the document was added to document repository 160. This may be, for example, the time a document was uploaded to a cloud-based repository or the time a document was sent or received via email. For documents already existing in document repository 160, the time-based parameter can be taken as the most recent modification time.
The various embodiments disclosed herein advantageously enable the generation and maintenance of content-based revision history timelines for content managed by a document management server. This is particularly advantageous in the context of workflows where users produce multiple versions of a single document when creating and working with content. For example, a user may have an idea for a proposal at home on a weekend. He makes a note in a text file and saves it to an online cloud repository or emails it to his work email account. Upon arriving at the office on Monday, he draws up a proposal using a word processor, exports the file to a portable document format, and shares it with colleagues by using a file sharing service or email. His colleagues add their comments to the shared file, or to the emailed files. The marked-up files are then returned to the first user who incorporates the comments as appropriate and sends a final version to multiple clients. In this example workflow multiple documents containing different versions of the same content are created. If the user wishes to refer to any one of these versions some time later, he may find it difficult to understand the relationship between the versions unless he has carefully saved and indexed them in an organized way. Certain of the embodiments disclosed herein provide an automated way to achieve such organization without requiring user diligence. For example, the content-based revision history timelines disclosed herein provide an automatically-generated collection of documents that have a common origin, even though they may slightly differ from each other or they may represent different stages in the development of the same content. This provides the end user with a better understanding of how the content within different documents relates to each other, thus moving away from traditional document-based management techniques.
Numerous variations and configurations will be apparent in light of this disclosure. For instance, as illustrated in
exceeds a threshold resemblance parameter R. In some cases the first document is considered to nearly duplicative of the second document where at least one of the containment parameter
exceeds a threshold containment parameter C.
Another example embodiment provides a system for content revision history tracking that comprises a timeline repository stored in a memory device. The timeline repository includes a plurality of data pairs {S(D, w), T}, wherein D represents a document, T represents a revision history timeline that includes D, and S(D, w) represents a set of shingles that is derived from D and that is based on a shingle size w. The system further comprises a document administration module configured to receive a first document D1 and a user command with respect to the first document. The system further comprises a content comparison module configured to evaluate a similarity measure between S(D1, w) and S(D2, w), wherein D2 represents a second document that is retrieved from a document repository. The system further comprises a timeline administration module configured to store a data pair {S(D1, w), T12} in the timeline repository in response to determining that the similarity measure exceeds a predetermined threshold similarity, wherein T12 represents a revision history timeline that includes the first and second documents. In some cases the user command is a command to add the first document to the document repository. In some cases determining that the similarity measure exceeds the predetermined threshold similarity indicates that the first and second documents are nearly duplicative based on a comparison of at least one of resemblance and containment. In some cases shingle size w ranges from about 20 words to about 40 words. In some cases the system further comprises a timeline generation module configured to generate a graphical representation of the revision history timeline T12. In some cases the system further comprises a timeline generation module configured to send a graphical representation of the revision history timeline T12 to a user that originated the user command.
Another example embodiment provides a computer program product encoded with instructions that, when executed by one or more processors, causes a process for tracking content revision history to be carried out. The process comprises receiving a first document containing first content. The process further comprises retrieving a second document containing second content. The second document is not an older version of the first document. The process further comprises making a determination whether the first document is nearly duplicative of the second document based on a comparison of the first and second content. Where the determination indicates that the first and second documents are nearly duplicative of each other, the process further comprises adding a representation of the first document to a timeline repository that already contains a representation of the second document. In some cases (a) the determination is based on evaluating a similarity measure for the first and second documents; and (b) the similarity measure is selected from a group consisting of resemblance and containment. In some cases (a) the second document is retrieved from a document repository managed by a document management system; and (b) the first document is received from a first document source external to the document management system. In some cases the process further comprises generating a graphical representation of the revision history timeline based on data extracted from the timeline repository, wherein the revision history timeline includes a plurality of documents, each of which is nearly duplicative of another one of the plurality of documents.
The foregoing detailed description has been presented for illustration. It is not intended to be exhaustive or to limit the disclosure to the precise form described. Many modifications and variations are possible in light of this disclosure. Therefore it is intended that the scope of the disclosure be limited not by this detailed description, but rather by the claims appended hereto. Subsequently filed applications claiming priority to this application may claim the disclosed subject matter in a different manner, and may generally include any set of one or more features as variously disclosed or otherwise demonstrated herein.