US20090037431A1

US20090037431A1 - System and method for maintaining metadata correctness

Info

Publication number: US20090037431A1
Application number: US12/072,454
Authority: US
Inventors: Paul Martino; Gian-Paolo Musumeci; Kristopher C. Wehner
Original assignee: Individual
Current assignee: Aggregate Knowledge Inc
Priority date: 2007-07-30
Filing date: 2008-02-26
Publication date: 2009-02-05
Also published as: US20190066125A1; US11880849B2; US11144933B2; US20220277318A1

Abstract

A method is disclosed. The method includes a relationship server receiving a discovery service request from a client computer, the relationship server comparing metadata provided in the discovery service request against a database and a crawler retrieving updated metadata from a commerce server for if the metadata provided in the discovery service request does not match the metadata stored in the database column.

Description

This is a non-provisional application based on provisional application Ser. No. 60/962,552 filed on Jul. 30, 2007, and claims priority thereof.

COPYRIGHT AUTHORIZATION

A portion of the disclosure of this patent document may contain material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

FIELD OF THE INVENTION

This invention relates generally to maintaining metadata correctness. More specifically the invention relates to maintaining metadata correctness for a set of objects subscribing to a web service.

BACKGROUND

Metadata is data that is used to supplement other data. For example metadata can be used to describe information that is auxiliary to another piece of data or object. Examples of data or objects include products, web pages, photographs or any other piece of data that is capable of having data associated therewith. Using the photograph as an example of an object, metadata could include, but is not limited to: the type of camera used, the time of day it was taken, where the picture was taken, the size of lens used and the name of the photographer. Using a camera as an example of an object, metadata could include, but is not limited to: price, SKU number, manufacturer, stocking status and one or more thumbnail images.
Traditionally, this metadata is maintained by the entity that controls the object: the photographer that created the photograph or the retail outlet selling the camera, in keeping with the earlier examples. It is common for ancillary services to require access to this metadata. For example, going back to the photograph example, a search engine might need or want to provide a searchable interface to many photographs based on their metadata (“show me pictures by Ansel Adams taken after 9 p.m. in Alaska with an 8 inch lens”). Unfortunately, because the service does not maintain the metadata and any changes thereto, consistency and correctness problems may emerge.
Historically, these problems have been dealt with by accepting copies of the metadata, as well as incremental updates, from the owner, be it in bulk format (a dump), an explicit integration with external systems (an integration) or in a streaming format for incremental updates (a feed). These external data sources are then used to synchronize the changes in the catalog with the service's database. This approach is difficult to automate, prone to errors, time-intensive, and goes out of date due to the error prone nature of feeds and the complexity of their maintenance over time.
Therefore, what has been needed and heretofore unavailable is a system and method of maintaining metadata correctness that overcomes the shortcomings of the previous approaches.

SUMMARY

According to one embodiment, a method is disclosed. The method includes a relationship server that receives a discovery service request from a client computer, the relationship server compares the metadata provided in the discovery service request against a database and a crawler retrieves updated metadata from a commerce server if the metadata provided in the discovery service request does not match the metadata stored in the database column.
In a further embodiment, a network is disclosed. The network includes a plurality of commerce servers, a client computer to request a page including metadata from a first of the commerce servers corresponding to a product and a relationship server to receive a content request including the metadata from the client computer, to compare the received metadata to first metadata stored in a database and to validate the metadata if the received metadata does not match the first metadata.

BRIEF DESCRIPTION OF THE DRAWINGS

The inventive body of work will be readily understood by referring to the following detailed description in conjunction with the accompanying drawings, in which:

FIG. 1 is a high-level block diagram of one embodiment of a computing environment according to one embodiment of the present invention.

FIG. 2 is a high-level block diagram illustrating one embodiment of a functional view of a computer system.

FIG. 3 shows one embodiment of a screen capture depiction of a merchant's store on the World Wide Web.

FIG. 4 is a high-level block diagram illustrating one embodiment of a data center.

FIG. 5 is a flow chart illustrating one embodiment of checking the accuracy of metadata dynamically.

FIG. 6 is an example process of an embodiment enabling maintaining metadata correctness.

FIG. 7 is an embodiment for dynamically updating metadata.

DETAILED DESCRIPTION

A detailed description of the inventive body of work is provided below. While several embodiments are described, it should be understood that the inventive body of work is not limited to any one embodiment, but instead encompasses numerous alternatives, modifications, and equivalents. In addition, while numerous specific details are set forth in the following description in order to provide a thorough understanding of the inventive body of work, some embodiments can be practiced without some or all of these details. Moreover, for the purpose of clarity, certain technical material that is known in the related art has not been described in detail in order to avoid unnecessarily obscuring the invention.
Reference in the specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase “in one embodiment” in various places in the specification are not necessarily all referring to the same embodiment.
It should be appreciated that embodiments of the described inventive body of work can be implemented in numerous ways, including as processes, apparatuses, systems, devices, methods, computer readable media, and/or as a combination thereof. Illustrative embodiments are described below.
In one embodiment, a method for the dynamic validation of metadata correctness is disclosed. End user interactions are used with an object for transmitting metadata information, which allows integration of various types of metadata. Metadata is associated with an object. Each time a user interacts with an object, the current metadata associated with the object is transmitted to a web application. The web application compares the current metadata with the service provider's metadata (if any). If a change has been detected, e.g., a mismatch between the service provider's stored data and the metadata originally transmitted to the web application, the object having inconsistent metadata is tagged for subsequent re-inspection.
Re-inspection process implements a decoupled inspection mechanism, such as a web crawler, that retrieves the object and associated metadata directly from the owner of the metadata. The metadata is inspected and, if a change is valid, the service provider's database is updated. The asynchronous nature of the validation system lends an additional measure of defense by preventing a third party from forging changed metadata information records and inciting the service into generating a denial-of-service attack.
Commonly-assigned U.S. patent application Ser. No. 11/369,562, entitled Using Cross-Site Relationships to Generate Recommendations filed Mar. 1, 2006 (“the '562 application”), which is hereby incorporated by reference in its entirety, describes embodiments of an invention related to determining recommendations by tracking interactions across multiple websites.
Embodiments of the invention may include various processes as set forth below. The processes may be embodied in machine-executable instructions. The instructions can be used to cause a general-purpose or special-purpose processor to perform certain steps. Alternatively, these processes may be performed by specific hardware components that contain hardwired logic for performing the processes, or by any combination of programmed computer components and custom hardware components.
Elements of the present invention may also be provided as a machine-readable medium for storing the machine-executable instructions. The machine-readable medium may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs, and magneto-optical disks, ROMs, RAMs, EPROMs, EEPROMs, magnetic or optical cards, propagation media or other type of media/machine-readable medium suitable for storing electronic instructions. For example, the present invention may be downloaded as a computer program which may be transferred from a remote computer (e.g., a server) to a requesting computer (e.g., a client) by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection).
FIG. 1 and the other figures use like reference numerals to identify like elements. A letter after a reference numeral, such as “110A,” indicates that the text refers specifically to the element having that particular reference numeral. A reference numeral in the text without a following letter, such as “110,” refers to any or all of the elements in the figures bearing that reference numeral (e.g. “110” in the text refers to reference numerals “110A,” “110B,” and/or “110C” in the figures).
The client 110 in this embodiment represents a computer system that is used by an end-user to interact with the web sites 112 via the network 116. The client 110 may be, for example, a personal computer or another network-capable device, such as a personal digital assistant (PDA), a cellular telephone, a pager, a video game system, a television “set-top box” etc.
The web sites 112 are locations on the network 116 that provide web pages to the clients 110 via the network 116. The web sites 112 may be, for example, media sites that primarily provide content such as news to the end-users, retailer sites that enable the end-users to purchase items, social networking sites that enable end-users to interact with other people, blogs and hybrid sites that provide a mix of these features. Those of skill in the art will recognize that there are essentially an unlimited number of different types of web sites 112 with which the clients 110 can interact. The web sites 112 may or may not be related or associated with each other as the present invention envisions being applicable in both cases. Although FIG. 1 illustrates three clients 110 and three web sites 112, other embodiments may include any number of clients 110 and web sites 112.
The end-users of the clients 110 interact with the web sites 112. In one embodiment, the interactions establish relationships. For example, an end-user may view a web page for a digital camera, and subsequently view a web page for a memory card for that camera. These actions create relationships between the end-user and the camera, and between the end-user and the memory card. The information from web sites 112 are provided to the relationship server 114.
The web sites 112 receive recommendations from the relationship server 114. These recommendations are provided to the end-users, typically by including the recommendations on web pages served to the end-users' clients 110. The recommendations can be for arbitrary and/or heterogeneous items and the web sites can request that the relationship server 114 provide recommendations for only specified types of items. For example, the recommendations may include items an end-user may want to purchase, news stories the end-user may want to read, musical groups in which the end-user may have interest, discussion groups in which the end-user may want to participate, etc.
The relationship server 114 receives descriptions of interactions that are derived from the web sites 112 and/or clients 110 and provides recommendations based at least in part on these interactions. In one embodiment, the relationship server 114 performs collaborative filtering on the received relationships to generate the recommendations.
Collaborative filtering allows for filtering based on arbitrary labels, predicates, intents, and/or relationships. In one embodiment the collaborative filtering is performed using relationships supplied by multiple web sites 112 and/or clients 110, and the resulting recommendations are of high quality. Moreover, the activities of the end-users that provide personally identifiable information may be tracked across multiple web sites 112 enabling the pool of relationships on which the collaborative filtering is based to be deeper than if only single-site activities were tracked.
The network 116 represents the communication pathways between the clients 110, web sites 112, and relationship server 114. In one embodiment, the network 116 is the Internet. The network 116 can also utilize dedicated or private communications links that are not necessarily part of the Internet. In one embodiment, the network 116 uses standard communications technologies and/or protocols. Thus, the network 116 can include links using technologies such as 802.11, integrated services digital network (ISDN), digital subscriber line (DSL), asynchronous transfer mode (ATM), etc.
Similarly, the networking protocols used on the network 116 can include multiprotocol label switching (MPLS), the transmission control protocol/Internet protocol (TCP/IP), the hypertext transport protocol (HTTP), the simple mail transfer protocol (SMTP), the file transfer protocol (FTP), etc. The data exchanged over the network 116 can be represented using technologies and/or formats including the hypertext markup language (HTML), the extensible markup language (XML), the web services description language (WSDL), etc.
In addition, all or some of links can be encrypted using conventional encryption technologies such as the secure sockets layer (SSL), Secure HTTP and/or virtual private networks (VPNs). In another embodiment, the entities can use custom and/or dedicated data communications technologies instead of, or in addition to, the ones described above.
FIG. 2 is a high-level block diagram illustrating a functional view of a typical computer system 200 for use as one of the entities illustrated in the environment 100 of FIG. 1 according to one embodiment. Illustrated are at least one processor 202 coupled to a bus 204. Also coupled to the bus 204 are a memory 206, a storage device 208, a keyboard 210, a graphics adapter 212, a pointing device 214, and a network adapter 216. A display 218 is coupled to the graphics adapter 212.
The processor 202 may be any general-purpose processor such as an INTEL x86, SUN MICROSYSTEMS SPARC, or POWERPC compatible-CPU. The storage device 208 is, in one embodiment, a hard disk drive but can also be any other device capable of storing data, such as a writeable compact disk (CD) or DVD, or a solid-state memory device. The memory 206 may be, for example, firmware, read-only memory (ROM), non-volatile random access memory (NVRAM), and/or RAM, and holds instructions and data used by the processor 202. The pointing device 214 may be a mouse, track ball, or other type of pointing device, and is used in combination with the keyboard 210 to input data into the computer system 200. The graphics adapter 212 displays images and other information on the display 218. The network adapter 216 couples the computer system 200 to the network 108.
As is known in the art, the computer system 200 is adapted to execute computer program modules. As used herein, the term “module” refers to computer program logic and/or data for providing the specified functionality. A module can be implemented in hardware, firmware, and/or software. In one embodiment, the modules are stored on the storage device 208, loaded into the memory 206, and executed by the processor 202.
The types of computers 200 utilized by the entities of FIG. 1 can vary depending upon the embodiment and the processing power required for the entity. For example, the client 110 typically requires less processing power than the web site 112 and relationship server 114. Thus, the client 110 can be a personal computer, cellular telephone, etc.
The web site 112 and relationship server 114 computers, in contrast, may comprise more powerful processors and/or multiple computers working together to provide the functionality described herein. In addition, the computers 200 can lack some of the features shown in FIG. 2. For example, a blade server supporting a web site 112 may lack a keyboard, pointing device, and display. In one embodiment, the computer system 200 serving as the relationship server 114 utilizes a processor 202 and/or memory 206 having a 64-bit word size.
FIG. 3 shows one embodiment of a merchant store on the World Wide Web. Any object may be displayed in the merchant store. In this particular embodiment, a chair 301 is displayed in the storefront. In other embodiments, different retail items can be displayed or articles from media sites or information on blogs. When an end user decides to purchase the chair 301 by selecting an add to cart icon 302, the metadata 303 is transmitted to a web application (not depicted) for validation. In this embodiment, the metadata 303 includes the items Uniform Resource Locator (“URL”) 304, the list price 305, today's price 306, you save 307 and catalog # 308. The metadata 303 in one embodiment may be visible to the end user, in other embodiments the metadata 303 may be entirely invisible and in other embodiments there can be a blend of both.
FIG. 4 is a high-level block diagram illustrating modules within relationship server 114 according to one embodiment of the present invention. Relationship server 114 includes a web application module 401 a crawler 402 and a database 403. Those of skill in the art will recognize that other embodiments can have different and/or other modules than the ones described here, and that the functionalities can be distributed among the modules and/or entities illustrated in FIG. 4 in a different manner.
The web application module 401 receives information from websites 112. In a preferred embodiment information is transmitted based upon client 110 interaction with a website 300. Furthermore, the web application module 401 stores metadata 303 received from a client 110 describing the metadata for a website 112 into database module 403. In one embodiment, these components communicate using a network. In another embodiment, the components are collocated in a single server.
The database module 403 stores metadata in tables. In one embodiment, the database module 403 stores data such as prices, thumbnails and other metadata for retail items. In another embodiment, database module 403 stores data describing news stories, including titles, descriptions and summaries.
The crawler 402 checks the database for existing metadata 303 and updates the table based upon metadata retrieved on its own based upon communications for a website. In one embodiment, the metadata received from a client 110 is compared with the stored metadata in the database 403 by the web application module 401. Changes to the metadata detected by the web application module 401 will then trigger the crawler 402 to verify the metadata via its own communications with the website 112.
FIG. 5 is a flow chart illustrating one embodiment for checking the accuracy of metadata dynamically. At processing block 501 metadata 303 that is associated with object 301 is generated in response to a client 110 interaction with a webpage 300. In one embodiment, the interaction with the website 300 that generates the metadata 303 is the “add to cart” action performed by a client on the webpage 300.
However, in other embodiments there are a variety of interactions that could prompt the generation of metadata (e.g., viewing the object, clicking on the object, clicking on a thumbnail representation of the object or any other interaction that one of ordinary skill in the art would appreciate in light of the purpose of the invention). At processing block 502, the metadata 303 is transmitted to the web application 401. The web application subsequently loads the metadata 303 into the database 403, which is illustrated at processing block 503.
At processing block 504, the metadata 303 is analyzed against existing information in the database. For example, the database may have a different price than the received metadata 303, or may have no data at all. In such a case, the metadata 303 is flagged and placed in a verification queue 404 for verification. In processing block 505, the crawler checks queue 404 for metadata 303 that needs verification. In processing block 506, the crawler makes an HTTP request of the website 300 from where the original metadata 303 was derived and receives new metadata and the webpage (e.g., metadata specific to the crawler request). At processing block 507, the crawler compares the new metadata. to the flagged metadata . . . . If there is a difference between the flagged metadata and the new metadata the table is updated to reflect the new metadata as illustrated at processing block 508.
FIG. 6 illustrates one embodiment for maintaining metadata correctness. At process 601, the client 110 submits a request for product information to an e-commerce web site 112 via some network 116. At process 602, the web site 112 responds with an HTML-formatted web page, 650, including a discovery service URL, 651 having encoded metadata about the product that was referenced. At process 603, a web browser at client 110 requests the discovery service URL 651 from the relationship server 114.
At process 604, the relationship server 114 checks the metadata provided in the encoded URL 651 during process 603 against a database 670. This database includes a set of columns. The columns include a unique item identifier 671, the last time a request for this item was seen 672, the associated metadata 673, and a flag to indicate pending updates 674. If the metadata provided in the encoded URL 651 matches the metadata 673 associated with the product, then the timestamp 672 is updated and no further work occurs. If the metadata does not match, however, then the pending update field 674 is set for this product. Note that the metadata provided in the URL 651 that has passed through the client 110 is not trusted in any way.
The relationship server 114 then returns a HTML-formatted list of recommendations 652 to the user 110 at process 605. At process 606, the crawler 680 awakens and checks the database 670 for a list of all product identifiers 671 that have the pending update field 674 set. At process 607, for each of these items, it requests the product information from the e-commerce web site 112 via some network (again, not shown here). At process 608, the web site 112 replies with a new copy of the HTML-formatted web page 650, again containing a directory service URL 651 which contains encoded metadata.
Finally at process 609, the web crawler 680 inspects the encoded metadata contained in the discovery service URL 651. It updates the necessary entries in the database 670, modifying the current metadata information 673 and clearing the pending update field 674 for the unique product in question.
FIG. 7 illustrates one embodiment of an interaction diagram describing the logical interactions of the components involved in the update of an item's metadata after validation by the crawler mechanism.
An end user browser 703 requests a page from a customer website 701 which describes an item with metadata. In one embodiment, the page describing the item includes a reference to the web application 702. In another embodiment, the end user browser 703 includes a module that communicates with the web application 702.
The end user browser 703 connects to the web application 702 to request content. In a preferred embodiment, the end user browser 703 transmits a copy of the metadata describing the item to the web application 702 along with the content request. In another embodiment, the end user browser 703 makes a separate request to transmit the metadata to the web application 702. In yet another embodiment, the end user browser 703 transmits logically invalid metadata to the web application 702 to force trigger a crawler refresh.
The web application 702 compares the metadata received from the end user browser 703 with the metadata stored in the database 706. If the metadata differs, an identifier for the page is placed in the validation queue 705. In one embodiment, the identifier for the page is the URL of the page. In another embodiment, the identifier for the page can be an external reference such as a database primary key.
The metadata validator 704 removes items from the validation queue 705 to validate. In one embodiment, the metadata validator 704 periodically polls the validation queue 705. In another embodiment, the validation queue 705 notifies the metadata validator 704 when items are available to validate. In yet another embodiment, the web application 702 can directly notify the metadata validator 704 without using the validation queue 705.
When an item is received to validate, the metadata validator 704 fetches a copy of the page from the customer website 701. In a preferred embodiment, the metadata validator 704 executes dynamic content in the page to emulate the operation of the end user browser 703, transmitting the metadata for the item to the web application 702. In another embodiment, the metadata validator 704 reads the metadata from the page and transmits it to the web application 702.
When the web application 702 receives the metadata from the metadata validator 704, it stores the metadata values in the database 706, overwriting any potentially existing values.
The above description is included to illustrate the operation of the preferred embodiments and is not meant to limit the scope of the invention. The scope of the invention is to be limited only by the following claims. From the above discussion, many variations will be apparent to one skilled in the relevant art that would yet be encompassed by the spirit and scope of the invention.

Claims

1. A method comprising:

a relationship server receiving a discovery service request from a client computer;

the relationship server comparing metadata provided in the discovery service request against a database; and

a crawler retrieving updated metadata from a commerce server if the metadata provided in the discovery service request does not match the metadata stored in the database column.

2. The method of claim 1, wherein the database includes a set of columns each column having associated metadata, a unique product identifier, a timestamp indicating the last time a request for an item was checked and a flag to indicate pending updates.

3. The method of claim 2, further comprising updating a timestamp if the metadata provided in the discovery service request matches the metadata stored in the database column.

4. The method of claim 3, further comprising setting the pending update flag if the metadata provided in the discovery service request does not match the metadata stored in the database column.

5. The method of claim 4, further comprising the relationship server returning a list of recommendations to the client computer.

6. The method of claim 4, further comprising:

the crawler checking the database for a list of product identifiers that have a pending update flag set;

the crawler requesting product information from one or more commerce servers for products corresponding to each of the product identifiers;

the crawler receiving metadata from the one or more commerce servers corresponding for the products corresponding to each of the product identifiers; and

the web crawler updating the database entries.

7. The method of claim 6, wherein updating the database entries comprises:

modifying current metadata information; and

clearing the pending update field for the product.

8. The method of claim 1, further comprising:

a client computer submitting a request for product information to a commerce server via a network; and

the client computer receiving a discovery service URL having encoded metadata about the product.

9. A network comprising:

a plurality of commerce servers;

a client computer to request a page including metadata from a first of the commerce servers corresponding to a product; and

a relationship server to receive a content request including the metadata from the client computer, to compare the received metadata to first metadata stored in a database and to validate the metadata if the received metadata does not match the first metadata.

10. The network of claim 9, further comprising the relationship server placing an identifier in a validation queue if the received metadata does not match the first metadata.

11. The network of claim 10, further comprising the relationship server removing the identifier from the validation queue to validate, retrieves updated metadata from the first customer server and stores the updated metadata in the database.

12. The network of claim 11, wherein the updated metadata is written over the first metadata.

13. A relationship server comprising:

a database;

a validation queue;

a web application to receive a content request including the metadata from the client computer and to compare the received metadata to first metadata stored in the database; and

a metadata validator to validate the metadata if the received metadata does not match the first metadata.

14. The network of claim 13, wherein the metadata validator places an identifier in the validation queue if the received metadata does not match the first metadata.

15. The network of claim 14, wherein the metadata validator removes the identifier from the validation queue to validate, retrieves updated metadata from a customer server and stores the updated metadata in the database.

16. An article of manufacture comprising a machine-accessible medium having associated data, wherein the data, when accessed, results in a machine performing operations comprising:

17. The article of manufacture of claim 16, wherein the database includes a set of columns each column having associated metadata, a unique product identifier, a timestamp indicating the last time a request for an item was checked and a flag to indicate pending updates.

18. The article of manufacture of claim 17, wherein the data, when accessed, results in a machine performing further operations comprising updating a timestamp if the metadata provided in the discovery service request matches the metadata stored in the database column.

19. The article of manufacture of claim 18, wherein the data, when accessed, results in a machine performing further operations comprising setting the pending update flag if the metadata provided in the discovery service request does not match the metadata stored in the database column.

20. The article of manufacture of claim 19, wherein the data, when accessed, results in a machine performing further operations comprising the relationship server returning a list of recommendations to the client computer.

21. The article of manufacture of claim 19, wherein the data, when accessed, results in a machine performing further operations comprising:

the crawler receiving metadata from the one or more commerce servers corresponding to each of the product identifiers; and

the web crawler updating the database entries.

22. The article of manufacture of claim 21, wherein updating the database entries comprises:

modifying current metadata information; and

clearing the pending update field for the product.

23. The article of manufacture of claim 17, further comprising: