Envío de mensajes

Parsers and serializers based on the standard representations of RDF are useful for the systematic processing and archiving of data in RDF. While there is consid- erable data available in these formats, even more data are not already available in RDF. Fortunately, for many common data formats (e.g., tabular data), it is quite easy to convert these formats into RDF triples.

We already saw how tabular data can be mapped into triples in a natural way. This approach can be applied to relational databases or spreadsheets. Tools to perform a conversion based on this mapping, though not strictly speaking par- sers, play the same role as a parser in a semantic solution: They connect the tri- ple store with sources of information in the form of triples. Most RDF systems include a table input converter of some sort. Some tools specifically target rela- tional databases, including appropriate treatment of foreign key references, whereas others work more directly with spreadsheet tables. Tools of this sort are calledconverters, since they typically convert information from some form into RDF and often into a standard form of RDF like RDF/XML. This allows them to be used with any other tools that respect the RDF/XML standard.

Another rich source of data for the Semantic Web can be found in existing webpages—that is, in HTML pages. Such pages often include structured infor- mation, like contact information, descriptions of events, product descriptions, publications, and so on. This information can be combined in novel ways on the Semantic Web once it is available in RDF. There are two different approaches to the problem of using HTML sources for RDF data. The first approach assumes that the original author of the HTML document might have no interest in or knowledge of RDF and the Semantic Web, and will create content accordingly. This means that no annotations correspond to predicates and no special struc- ture of the HTML makes it especially “RDF-ready.” The second approach assumes that the content author is willing to put in a bit of effort to mark up the content in such a way that in addition to its use for display as HTML, it can also include information that allows the data to be interpreted also as RDF.

Not surprisingly, the first approach received the most attention, especially as the Semantic Web began the bootstrapping process of gathering enough RDF data to begin the network effect. Legacy data had been represented in HTML

before anyone knew anything about RDF. How could that information be made available to the Semantic Web as RDF triples?

The most “hands-off” approach to this problem is to use a program called a scraper. A scraper is a program that reads a source that was intended for human reading, typically an HTML page, and produces from it an RDF representation of that data. The name scraper was inspired by the image of “scraping” useful information from a complex display like a webpage.

Scraper technology is continuing to develop. We will illustrate the basics with an early scraper system called Solvent, which has been developed as part of the Simile project at MIT. Solvent provides a user interface for highlighting selected parts of a webpage and translating the content into RDF. Figure 4-1 shows

FIGURE 4-1

Solvent at work on a webpage from the Los Angeles Metro Rail site. Solvent is implemented as a Firefox plug-in, and it appears as an extra panel at the bottom of the Firefox window. Solvent provides the basic functions of a scraper. First, it allows the user to select an item on the webpage; in the figure, the user has selected the name and address of one station. The scraper then highlights all the items on the page that it determines to be “the same kind” of item; in this case, we see that Solvent has highlighted all the addresses of stations on the page in yellow.

The scraper then provides a way for the user to describe the selected data; in this example, the user specifies that “Allen Station” is the name of the first item and that the next two lines “395 N. Allen Av., Pasadena 91106” is the address of the item. The scraper extrapolates this information to find the name and address of all the stations. The details of how the Solvent user interface does this are not important; the fundamental idea is that a user specifies information about a single item on a webpage, and the system uses that information to mark up all the information on the page. The result is then expressed in RDF; in this example, Solvent produces the following RDF triples:

metro:item0 rdf:type metro:Metro; dc:title "Allen Station";

simile:address "395 N. Allen Av., Pasadena 91106". metro:item1 rdf:type metro:Metro;

dc:title "Chinatown Station";

simile:address "901 N. Spring St., Los Angeles 90012-1862". metro:item2 rdf:type metro:Metro;

dc:title "Del Mar Station";

simile:address "230 S. Raymond Av., Pasadena 91105-2014". (etc.)

Scrapers differ in their user interfaces (for allowing users to specify items and their descriptions) and the sophistication with which they determine “similar” items on a page.

A new development in webpage deployment is a trend that goes by the name ofmicroformats.The idea of a microformat is that some webpage authors might be willing to put some structured information into their webpage to express its intended structure. To enable them to do this, a standard vocabulary (usually embedded in HTML as special tag attributes that have no impact on how a browser displays a page) is developed for commonly used items on a webpage. Some of the first microformats were for business cards (including, in the controlled vocabulary, names, positions, companies, and phone numbers) and events (including location, start time, and end time). The growing popular- ity of microformats indicates that at least some Web developers are willing to put in some extra effort to encode structured information into their HTML.

The W3C has outlined a specification called GRDDL (Gleaning Resource Descriptions from Dialects of Languages) that provides a standard way to express a mapping from a microformat, or other structured markup, to RDF.

GRDDL makes it possible to specify, within an HTML document, a recipe for translating the HTML data into RDF resources. The transformations themselves are typically written in the XML stylesheet transformation language XSLT. Exist- ing XHTML documents can be made available to the Semantic Web simply by marking up the preamble to the documents with a few simple references to transformations.

The W3C is also pursuing an alternate approach for allowing HTML authors to include semantic information in their webpages. One limitation of micro- formats is the need to specify a controlled vocabulary and write an XSLT script for GRDDL to use with that vocabulary. Wouldn’t it be better if, instead, some- one (like the W3C) would simply specify a single syntax for marking up HTML pages with RDF data? Then there would be a single processing script for all microformats.

The W3C has proposed just such a format called RDFa. The idea behind RDFa is quite simple: use the attribute tags in HTML to embed information that can be parsed into RDF. Just like microformats, RDFa has no effect on how a browser displays a page. Current versions of RDFa are somewhat difficult to use, but better tools are being developed. It is unclear whether the microformat approach or the RDFa approach to embedding RDF information into webpages will dominate (or indeed, if either of them will; there really is no reason for the webpage development industry to make a choice, and something else might turn out to catch on better than either of them).

All of these methods that allow webpage developers to include structured information in their webpages have two advantages over scrapers and conver- ters. First, from the point of view of the system developer, it is easier to harvest the RDF data from pages that were marked up with structure data extraction in mind. But, more important, from the point of view of the content author, it ensures that the interpretation of the information in the document, when ren- dered as RDF, matches the intended meaning of the document. This really is the spirit of the word semantic in the Semantic Web—that page authors be given the capability of expressing what they mean in a webpage for a machine to read and use.

RDF STORE

A database is a program that stores the data, making them available for future use. An RDF data storage solution is no different; the RDF data are kept in a sys- tem called anRDF store. It is typical for an RDF data store to be accompanied by a parser and a serializer to populate the store and publish information from the store, respectively. Just as is the case for conventional (e.g., relational) data stores, an RDF store may also include a query engine, as described in the next section. Conventional data stores are differentiated, based on a variety of perfor- mance features, including the volume of data that can be stored, the speed with

which data can be accessed or updated, and the variety of query languages sup- ported by the query engine. These features are equally relevant when applied to an RDF store.

In contrast to a relational data store, an RDF store includes as a fundamental capability the ability to merge two data sets together. Because of the flexible nature of the RDF data model, the specification of such a merge operation is clearly defined. Each data store represents a set of RDF triples; a merger of two (or more) datasets is the single data set that includes all and only the triples from the source data sets. Any resources with the same URI (regardless of the originating data source) are considered to be equivalent in the merged data set. Thus, in addition to the usual means of evaluating a data store, an RDF store can be evaluated on the efficiency of the merge process.

RDF store implementations range from custom programmed database solutions to fully supported off-the-shelf products from specialty vendors. Conceptually, the simplest relational implementation of a triple store is as a single table with three columns, one each for the subject, predicate, and object of the triple. The information about the Los Angeles Metro given in Figure 4-1 would be stored as in Table 4-1.

This representation should look familiar, as it is exactly the representation we used to introduce RDF triples in Chapter 3. Since this fits in a relational data- base representation, it can be accessed using conventional relational database tools such as SQL. An experienced SQL programmer would have no problem writing a query to answer a question like “List thedc:title of every instance

ofmetro:Metroin the table.” As an implementation representation, it has a num-

ber of apparent problems, including the replication of information in the first column and the difficulty of building indices around string values like URIs.

Table 4-1 Names and Addresses of Los Angeles Metro Stations

Subject Predicate Object

metro:item0 rdf:type metro:Metro

metro:item0 dc:title “Allen Station”

metro:item0 simile:address “395 N. Allen Av., Pasadena 91106

metro:item1 rdf:type metro:Metro

metro:item1 dc:title “Chinatown Station”

metro:item1 simile:address “901 N. Spring St., Los Angeles 90012–1862”

metro:item2 rdf:type metro:Metro

metro:item2 dc:title Del Mar Station

metro:item2 simile:address “230 S. Raymond Av., Pasadena 91105–2014” RDF Store 65

On the other hand, in situations in which SQL programming experience is plen- tiful, this sort of representation has been used to create a custom solution in short order.

It is not the purpose of this discussion to go into details of the possible opti- mizations of the RDF store. These details are the topic of the particular (often patented) solutions provided by a vendor of an off-the-shelf RDF store. In partic- ular, the issue of building indices that work on URIs can be solved with a num- ber of well-understood data organization algorithms. Serious providers of RDF stores differentiate their offerings based on the scalability and efficiency of these indexing solutions.

RDF Data Standards and Interoperability