Category: Semantics

Categories
Just Shelley RDF

And with all that

And with all the unpleasantness this weekend, including a comment breaking my XHTML, captured for posterity by the playful, puckish, Anne, I find that I have misunderstood one key element of the RDFa specification, and have embarrassed myself greatly.

screenshot of Anne being an asshole

Why is every time I touch anything to do with the W3C or associated mailing lists, I always come away feeling like the idiot child who has just wasted the time of her elders? It has gotten to the point, where I don’t want to write anything about technology online.

Now, I have to re-visit my XHTML formatting for my comments, for yet another use case that is slipping through the filters.

update Another set of test cases bites the dust. I now have two modules, HTML Purifier and htmLawed implemented, in addition to the built-in URL converter and automatic line break functionality. The order these are implemented is important and the following seems to create a compatible effect: HTML Purifier, htmLawed, URL converter, line break. I’ll have to do other testing, but two particular use cases that came up yesterday—yes, two— both seem to be trapped with these changes.

second update Based on request from from the htmLawed creator, I attempted to reduplicate the original errors. One was quite simple: the use of <self-close /> caused the Drupal built-in HTML corrector to over correct, adding a </self-close >. I’m not sure why I had the built-in HTML corrector active, anyway, as it does conflict with htmLawed. Removing it removed the problem.

The second test case didn’t get corrected by htmLawed, when I tested with the original comment, so I added HTML Purifier. However, when I went to duplicate the test case, I couldn’t, so I had documented the test case for duplication incorrectly. I’ve since turned off HTML Purifier, and if the case occurs again, will leave it to show the htmLawed creator. It doesn’t hurt to use both modules, and I only use them with comments, but if I don’t need two, I’d rather not use two.

Categories
Semantics

Stop justifying RDF and RDFa

update The discussion on RDFa in HTML5 is quite active on the WhatWG mailing list, and so I’m closing comments down here, and encouraging the discussion in that location. There is no restriction on joining the mailing list. A place to start would be a thread I started but I’m sure new threads will be springing up.

I did want to apologize for assuming that the XHTML errors I had recently were due to WhatWG members having fun at my expense. I’ve had people deliberately break my XHTML-based comments in the past when I’ve written about XHTML, and the break was documented with a screenshot on the website of a WhatWG member. I put 2 and 2 together and came up with 5.

I was reading the back and forth argument about the support for RDFa in HTML5, when it hit me that we, who support RDF, and its embedded serialization technique, RDFa, are going about it all wrong.

The question that gets asked, repeatedly, in the HTML5 and WhatWG mailing lists is What problem does RDFa solve? This typically then leads to lengthy discussions about RDFa versus microformats, how one only needs rel, class, meta, and script in order to seemingly record the same information. Or that marking this information up in any way is unnecessary, as people won’t use it, use it badly or for evil purposes, and the only direction forward for the web is natural language processing…yada, yada, yada—you’ve heard it all before.

But what if we stop focusing on the perceived purpose of RDF/RDFa? What if, instead of defending RDFa as a format for discovery of semantics on the web, in competition with other techniques, we focus on RDF, as others have focused on MathML and SVG—as a rich, mature specification with its own unique purpose, and its own unique benefit? In other words, begin with the assumption that RDF has value in, and of itself, and does not need to be “justified”. Instead, let’s focus on whether HTML5 can support RDF—the rich, mature specification—as is, with the existing HTML5 extension mechanisms.

The quintessential aspect of RDF is the triple of subject, predicate, and object. For simplicity’s sake: the thing, the property of the thing, and the property’s value.

For the most part, the thing is identified by a URI, a Uniform Resource Identifier, in order to distinguish it from every other thing when different instances of data are combined. To repeat the underlying basis of this particular thought experiment, disregard, for the moment, that RDF is used to record semantics. Focus, instead, on the essential structure of RDF data structure. Now ask yourself: can we represent RDF within an HTML5 document, using the HTML5’s current mechanism for extensibility? My assertion in this writing is that the answer is, no.

To demonstrate, let’s look at the RDF/XML output derived from an examination of the RDFa currently embedded in this page. Case in point, the following:

<rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
  xmlns:ns0="http://www.w3.org/1999/xhtml/vocab#"
  xmlns:ns1="http://purl.org/dc/elements/1.1/"
  xmlns:ns2="http://www.w3.org/2000/01/rdf-schema#">
  <rdf:Description rdf:about="http://realtech.burningbird.net/semantic-web/semantic-markup/oh-look-its-not-just-us-semantic-web-dweebs-who-noticed">
    <ns1:title rdf:parseType="Literal"><a xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" href="/semantic-web/semantic-markup/oh-look-its-not-just-us-semantic-web-dweebs-who-noticed">Oh, look. It's not just us Semantic Web Dweebs who noticed.</a></ns1:title>

    <ns1:subject rdf:parseType="Literal">Semantic Web: <a xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" href="/semantic-web/semantic-markup">Semantic Markup</a></ns1:subject>
  </rdf:Description>
</rdf:RDF>

The RDFa from which this RDF model was derived is the following:

<div id="node-572" class="node" about="/semantic-web/semantic-markup/oh-look-its-not-just-us-semantic-web-dweebs-who-noticed">
      <h2 class="node-title" property="dc:title">
      <a href="/semantic-web/semantic-markup/oh-look-its-not-just-us-semantic-web-dweebs-who-noticed">Oh, look. It's not just us Semantic Web Dweebs who noticed.</a>
    </h2>          
     <div class="taxonomy">
      Tagged: <ul class="links inline"><li property="dc:subject">Semantic Web: <a href="/semantic-web/semantic-markup">Semantic Markup</a></li></ul>    </div>
...
</div>

The triple we’ll focus on is that a given story (subject), belongs to a particular category of story (predicate), which is this case is “Semantic Markup”.

In the example, the subject is identified with the about attribute attached to the outer div element, which encompasses the actual text of the story. The predicate associated with the subject is identified in the property attribute, which is attached to a list element (li), and the RDF object is the text, “Semantic Markup”, contained within the list item element’s opening and closing tags. The two element attributes used in this example, which are not a part of HTML5, are “about” and “property”. The question then is: can we use HTML5’s current extensibility mechanisms to record the same data, maintaining the same essential structure, in order to derive the same RDF data model when the page is passed to some RDF extraction mechanism?

Goodness knows it would seem to be a simple way to represent the RDF bits in existing HTML5 attributes. For instance, we could add “subject” as another class item and thus eliminate the need for the RDFa property. We already have the link contained within the list item, which would seem to serve the purpose of identifying the object uniquely, and therefore don’t need about. In other words, HTML5’s extension mechanism would seem to be sufficient. Except, of course, it’s not.

If the data so documented existed solely within the page, I could use the class attribute to denote the RDF property, but is the “subject” I use in my document, the same as “subject” in someone else’s document? Who knows. Other than a similarity of text, we have no idea if they mean anything. This is a critical breakdown, too, because precision of data model is also an essential element of RDF. Otherwise, we wouldn’t be able to combine documents found on the web with any degree of confidence.

However, I suppose we could annotate the “subject” class value with an abbreviation of the domain from which it derives, in this case the Dublin Core domain, or “dc:” for short. By doing so, when you have a dc:subject in your document, and I have a dc:subject in my document, and both documents attach this property to the same subject, then the data can be safely merged. There is no confusion about what each of us “means”, when use use “subject”.

Of course, we’ll then have to negotiate for a shared meaning behind “dc:”. And we’ll have to ensure that everyone in the world uses the same designation for Dublin Core. Then we’ll have to repeat this exercise for every existing and new vocabulary that comes along…

Perhaps the abbreviated designation isn’t as feasible as it would first seem. So, what we’ll do, then, is annotate the subject with the full domain name URI, and still use the class attribute:

<li class="inline node http://purl.org/dc/elements/1.1/subject">Semantic Markup</li>

Well, that’s going to be interesting to see in our web page documents. Of course, we’ll have to duplicate the domain name URI with every reference to the property, increasing the overall size of the document. And, unfortunately, the dozens, potentially hundreds of RDF parsers that already exist will have to be modified to account for the difference in handling between RDFa embedded in HTML5, and RDFa embedded in XHTML, but that’s a small price to pay for HTML5 compatibility. Really. The RDFa processors will have to look at every use of class in a document, which potentially could slow down processing, and make the applications more sluggish, but that’s also a small price to pay.

Really.

So, we’ve accounted for the predicate, the property in our triple. Next, we need the ability to uniquely identify the resource.

A possible HTML5 attribute we could use is rel attribute, supplying the URI for the subject. However, a quick glance at the HTML5 Wiki for Rel and we can see that, though rel can be str-e-e-e-e-tched almost beyond recognitions, there are limits. Our use of rel as a way of recording a specific URI does not fit within the HTML5 boundaries for permissible uses of the attribute, because it’s not a repeating value that we can define in a table ahead of time.

In our web pages, we can point out our sweethearts, our timesheets, our muse, and a crush. We can’t, however, use rel to point to the resource to which a specific RDF property is attached.

If not the rel, how about others of the HTML5 attributes? For instance, a likely named alternative is the id. Would id work?

Currently, the HTML5 specification supports id to identify a web page element uniquely, but only an element specific to the document and the document’s DOM, or Document Object Model. It’s handy for whizzing the element about the page using JavaScript, and playing pretty, pretty with CSS, but how will it combine with, say, the data from a hundred web pages? A thousand?

Well, it doesn’t combine at all, because the id supported in HTML5 is semantically not the same as the URI necessary for RDF. Though the name of the game in HTML5 is “overloading R us”, in this case the meaning of the term must stretch too much in order to successfully encompass both needs.

So, what is wrong with using a hypertext link to identify a resource? And convincing the HTML5 crew to add “rdf-resource” to “sweetheart” and “muse” in the list of valid rel attribute values?

Ah, now that’s where the rubber meets the road when it comes to RDF. This takes us all the way back to the beginning of the discussions about RDF, and the emphasis placed on the fact that a URI is not the same as a URL. And though a URL is an instance of a URI, not every instance of a URI can be safely used in place of a URL. In other words, we can’t depend on using a hypertext link to identify a resource.

OK, then, what about limiting our RDF to those cases where the URI is a URL?

Unfortunately, this also fails to map cleanly between HTML5 and RDF. In the example, the actual hypertext link associated with the list element with the given property of “dc:subject” isn’t the RDF triple subject, at all. That link is associated with the web page leading to a list of related postings. It’s handy, but it doesn’t uniquely identify the subject being described. No, the actual resource, or subject, is the story, itself.

Now, the story is identified by a hypertext link, but the link in this case isn’t attached in any meaningful way to the element containing our “dc:subject” property attribute. More importantly, from a viewpoint of achieving a clean mapping between the RDF model and bits embedded within the HTML5 document, there is no logic or set of rules within HTML5 to associate the two; not in such a way that we can guarantee the same RDF data model with each iteration of usage within an HTML5 document.

We can assume there’s another link containing the URI within the parent block somewhere that uniquely identifies the resource. There is no formal logic, however, nor set of rules that guarantees we’ll always be able to derive the same RDF model, each and every time.

In other words, the extension mechanisms built into HTML5 can’t ensure that the embedded data can then be used to safely derive and return a consistent RDF model.

RDFa, on the other hand, does define these rules. Defines them well enough that I can make minor modifications to my Drupal template to embed the RDF data, and use a packaged PHP-based API to pull this same RDF data back out. Not just myself—anyone wanting to annotate their web pages with RDF could do so, without negatively impacting on any other aspect of the page, or its consumption by other agents, such as browsers. And any application can then pull the data out using any number of language-based APIs. Unfortunately, though, RDFa does not fit cleanly into the current HTML5 specification. It doesn’t fit, and seemingly, is not welcome.

In the recent discussions related to once again having to “prove” the worthiness of RDF/RDFa, HTML5 lead editor, Ian Hickson, wrote the following in a note posted to one of the HTML working group’s email list.

Also, while the solutions we’re designing will almost certainly still be in use decades from now, and will almost certainly influence the solutions in use centuries from now, we are not actually designing the solutions for the problems seen decades from now.

That is to say, we are trying to solve the problems of today and the next few years, with a design that will be extensible in the future by the maintainers of HTML once they know what the problems of the future are. HTML5 is not the end of the road; when HTML5 is widely deployed and used, then we will be able to design HTML6 on top of it. And so forth.

Thus there is no need for HTML5 to have author-usable features for extensibility to solve the problems of decades from now. The extensibility mechanisms for authors (and HMTL5 has many …) should solve _today’s_ problems; and the language should be designed in such a way that the future maintainers of HTML can later extend the language to fix their problems. This is just how HTML4 was done; it’s how CSS was done; it’s how XML was done (you can’t invent new XML syntax, for instance, that would require a new version of XML).

In this writing, I’ve only looked at the most trivial aspects of the RDF model and its RDFa serialization. If HTML5 fails with something as primitive as a simple RDF triple, it will certainly continue to fail for anything more complex. However, the point on this writing isn’t to highlight the shortcomings of HTML5, as a whole, but to demonstrate that the extension mechanisms within HTML5 are not sophisticated enough to handle existing needs. Not some future extensiblity, as Ian notes, but a need that exists today.

RDF is a rich data model with widespread use, documented by a mature specification, supported by any number of tools in any number of applications, in use by any number of companies, for any number of purposes. It is not some lightweight Johnny-come-lately that can be disregarded and ignored because it doesn’t satisfy a small group’s determination of what is, or is not, essential to the web. We don’t have to justify our interest in RDF, and therefore are fully within our rights to ask that it be supported in any web page markup currently under development by the W3C.

Now, if the HTML5 working group wishes to demonstrate that the RDF model can be implemented in HTML5, as is, then they should do so. They should not, though, demand that we give up the RDF model in order to support some other model, just because they don’t happen to see the need for RDF for themselves.

We in the RDF community are not asking the HTML5 working group to support …extensibility to solve problems of decades from now. We’re asking for a solution to a problem that exists today. Now. This very moment.

Categories
Semantics

Oh look it’s not just us Semantic Web dweebs who noticed

A List Apart has a new article out on the Semantics in HTML5. John Allsopp writes

We’ll start by posing the question: “why are we inventing these new elements?” A reasonable answer would be: “because HTML lacks semantic richness, and by adding these elements, we increase the semantic richness of HTML—that can’t be bad, can it?”

By adding these elements, we are addressing the need for greater semantic capability in HTML, but only within a narrow scope. No matter how many elements we bolt on, we will always think of more semantic goodness to add to HTML. And so, having added as many new elements as we like, we still won’t have solved the problem. We don’t need to add specific terms to the vocabulary of HTML, we need to add a mechanism that allows semantic richness to be added to a document as required. In technical terms, we need to make HTML extensible. HTML 5 proposes no mechanism for extensibility.

On reading of which, I hurt my head by banging it, suddenly and with force, against my desk.

Categories
RDF SVG Web

Tweaking makes perfect

Not long ago, Tim O’Reilly posted a discussion thread about the importance of practice, and one of the participants in the thread, my long-time editor, Simon St. Laurent, reiterated his interest in practicing this year—both on the trumpet, and in his coding.

I never left programming the way I left trumpet. I simply stopped playing trumpet after eighth grade. I’ve gone back and forth with programming since sixth grade, getting totally into it for a year or two at a time and then departing out of frustration, distraction, or the need to do something else. At O’Reilly, I’m exposed to programming constantly – I edit and write computer books after all! – but editorial is a long ways from actually programming. Even writing books about programming is a seriously meta- activity, one that requires more attention on the communications than on the code. (The code has to be right, but – though this may depend on the audience – the explanations have to do a lot more than the code.) My work isn’t programming practice.

One place I practice is with this site. I still have hopes that I can transform my work with this site into some paying work. At a minimum, I enjoy the tweaking and it keeps me occupied.

In addition, I also frequently re-design this site. Doing so allows me to explore new uses of technology, such as the use of SVG for site design, and JavaScript and RDFa in support of semantics. The practice also helps me improve my use of XHTML and CSS, including how to deal with IE without necessarily having to incorporate massive amounts of workaround code. Luckily, the “in” design concepts today are based on a minimalist design, so if my site is legible and clean in IE, it doesn’t matter if it’s plain.

I’m not practicing with every hot technology; I’ve made choices with how I spend my time. Yes for PHP, Python, JavaScript, CSS, SVG, RDFa, various web services, and XHTML. No on .Net, Ruby, Java, and cloud computing. A maybe on HTML5 and C++. Not necessarily the best decisions, perhaps, as Java and .Net are where the money is made, and the folks in Silicon Valley drool when you mention “cloud”, but I really don’t like the technologies or the environments.

Practice is essential for keeping our skills sharp, but that’s not the only reason it’s important. It’s also a way to constructively deal with the constant barrage of unhappy news we’re subjected to. We may not have any control over warring nations, global warming, or the state of economy, but we do have some control over how we live our lives. And that includes finding pieces of ourselves that can be improved with practice.

Categories
Semantics

RDFaification of Drupal 6

You don’t have to wait for Drupal 7 to RDFaificate your Drupal site. I spent yesterday tweaking my space, and if you access the site now with a tool, such as the Semantic Radar Firefox add-on, you’ll see all sorts of semantic goodness. I used a combination of plug-ins and theme modifications to make my changes, and will probably add to the overall effect over time.

What simplified my RDFa integration is that my site was already being served up as valid XHTML, via a modification to my page.tpl.php file:

<?php
header("Vary: Accept");
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
    header("Content-Type: application/xhtml+xml; charset=utf-8");
else
    header("Content-Type: text/html; charset=utf-8");
?><!DOCTYPE html PUBLIC
    "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus SVG 1.1//EN"
    "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-svg.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" 
xml:lang="<?php print $language->language ?>">

The PHP code checks with the user agent accessing the page. If the user agent accepts XHTML, the code returns the pages as XHTML; otherwise, the pages are returned as HTML. However, the DOCTYPE I had been using was a SVG+MathML DOCTYPE, because of my sometimes use of embedded SVG. To validate as XHTML+RDFa, though, you need to use the RDFa DOCTYPE.


<?php
header("Vary: Accept");
if (stristr($_SERVER["HTTP_ACCEPT"], "application/xhtml+xml"))
    header("Content-Type: application/xhtml+xml; charset=utf-8");
else
    header("Content-Type: text/html; charset=utf-8");
?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML+RDFa 1.0//EN" 
   "http://www.w3.org/MarkUp/DTD/xhtml-rdfa-1.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" dir="ltr"
xmlns:foaf="http://xmlns.com/foaf/0.1/"
xmlns:dc="http://purl.org/dc/elements/1.1/">
<head profile="http://ns.inria.fr/grddl/rdfa/">

The namespaces in the HTML opening tag don’t reflect all that I’ll use in my pages, just the ones I used for RDFa annotation sprinkled, liberally, throughout the page. When I use embedded SVG, I can just add the SVG namespaces directly into the opening SVG element tag. I could add the namespaces now, but I don’t always use embedded SVG.

One unfortunate consequence of switching DOCTYPEs is that when I do use embedded SVG, the page won’t validate. However, this won’t impact on the user agents and their ability to process the SVG correctly, so I’ll just have to live with the invalidation errors. That’s the joy of DOCTYPEs.

Another change is to the opening HEAD tag, where I added the GRDDL profile. This lets data consuming agents know that I’m, first of all, using RDFa, then secondly, using the latest transform profile for RDFa. After all, once the data is provided, we assume someone will want to do something with the data.

I’m ready, now, to begin adding RDFa annotation. Some of the changes I can make directly to the theme pages, such as adding an attribute/value pair of property=”dc:title” to my header element that references my site’s title (“Burningbird’s RealTech”). I also added annotation within the node, via node.tpl.php, again adding property=”dc:title” to each individual site entry’s title.

Other annotation, though, required either the use of a Drupal module, or custom code. For instance, one change I wanted to make was to add a a property=”dc:subject” to my vocabulary terms. In my template.php file (used to override and extend the theme templating engine), I added a taxonomy term function that will not only append the vocabulary to each term, but also annotate the result with the RDFa dc:subject notation:

// split out taxonomy terms by vocabulary
function burningbirds_print_terms($nid) {
     $vocabularies = taxonomy_get_vocabularies();
     $output = '<ul class="links inline">';
     foreach($vocabularies as $vocabulary) {
       if ($vocabularies) {
         $terms = taxonomy_node_get_terms_by_vocabulary($nid, $vocabulary->vid);
         if ($terms) {
           $links = array();
           $output .= '<li property="dc:subject">' . $vocabulary->name . ': ';
           foreach ($terms as $term) {
             $links[] = l($term->name, taxonomy_term_path($term), array('rel' => 'tag', 'title' => strip_tags($term->description)));
           }
           $output .= implode(', ', $links);
           $output .= '</li>';
         }
       }
     }
     $output .= '</ul>';
     return $output;
}

In the node.tpl.php file, I then replaced the existing print $terms line with a reference to my custom terms display function:

    <div class="taxonomy">
      Tagged: <?php print burningbirds_print_terms($node); ?>
    </div>

Other areas that can be annotated with RDFa in an entry are the author and date, but I didn’t have to code these or modify the theme template directly. Instead, I downloaded and installed the Submitted By module. Once installed and activated, this module provides an “Appearance” field in the content type form, which you can use to modify the “submitted by” line in posts.

By default, the template engine generates a line with the author’s username, linked to their user profile, and the date and time when the entry was created. I modified the field to show the author’s name, without linking to the author profile, since I’m the only author. I also modified the post date to just the date. Time, to me, just isn’t relevant for my site. Adding the appropriate RDFa annotation results in the following pattern:

<span property="dc:creator">[author-name-raw]</span> on [day], <span property="dc:date">[yyyy]-[mm]-[dd]</span>

Now that I’ve annotated several elements in the page with RDFa, I went shopping around at various semantic websites to see what else they were providing by way of semantic markup. At Danny Ayers weblog my Semantic Radar toolbar alerted me to the presence of SIOC (Semantically-Interlinked Online Communities Project) data, one of the recommended data types supported by Yahoo’s SearchMonkey. I did a little research and found the SIOC Drupal module, which I downloaded and installed.

The SOIC module automatically generates SIOC, which can be accessed as a direct RDF export. I gather that the module also adds a link to this metadata via the menu system, but I found this only works with a theme like Garland’s. I wanted to be able to integrate a link in the header of my web pages, to page specific SIOC exports, wherever applicable. I checked the module’s documentation, and elsewhere, but couldn’t find anything on automatically adding this link, so decided to add it myself in my theme.

In Drupal, at least 6.x, you can add a preprocess function that will pre-process web page data before the page is displayed. I had such a pre-process function already, to modify my header to a) remove the RSS 2.0 link, and b) modify the content type meta tag to reflect my XHTML content type. It was a simple matter to modify this code to include a conditional check to see if the page being served is the Drupal front page, and if not, whether the page is presenting a node of type story, blog, or user. If the former, I provided a link to the site’s main SIOC export URL; the later, one specific to the node:

function burningbirds_preprocess_page(&$vars) {

  $head = $vars['head'];
  $node = $vars['node'];
  $head = str_replace("<meta http-equiv=\"Content-Type\" content=\"text/html; charset=utf-8\" />",
              "<meta http-equiv=\"Content-Type\" content=\"application/xhtml+xml; charset=UTF-8\" />", $head);
  
  $head = str_replace("<link rel=\"alternate\" type=\"application/rss+xml\" title=\"Burningbird's RealTech RSS\" href=\"http://realtech.burningbird.net/rss.xml\" />\n","",$head);
    
  if (drupal_is_front_page()) {
    $head .= '<link rel="meta" type="application/rdf+xml" title="SIOC" href="http://realtech.burningbird.net/sioc/site" />';
  } else if ($node->type == 'story' || $node->type == 'blog' || $node->type == 'user') {
    $head .= '<link rel="meta" type="application/rdf+xml" title="SIOC" href="http://realtech.burningbird.net/sioc/node/';
    $head .= $node->nid;
    $head .= '" />';
  }

  $vars['head'] = $head;
}

For the node pages, I check to see if the node type is blog, story, or user, as these are the only node types currently supported by the SIOC module. Once this change was in effect, a header link to the SIOC file now appears with the main site page, and with blog, story, and user pages.

This is a start, as I explore other ways to annotate my site with metadata. I also plan on using metadata annotation when I do reviews and other specific types of writing. In addition, I’ll probably add a generic FOAF page, as well as utilize other vocabularies as they present themselves. If you don’t have the Semantic Radar toolbar installed, you can use the W3C RDFa extractor to extract the site’s RDFa. You can see the SIOC by accessing the exporter for the site or an individual entry, such as this story.