Is visually hidden RDFa an anti-pattern?

In a few cases I have encountered a technique of adding RDFa to a part of HTML document and then styling it with CSS (e.g., using display: none;) as visually hidden. For instance, this can be seen in the rNews documentation (section Embedding Hidden Metadata):

<div  style="display:none">
  <div property="rnews:description">The questions about the...</div>
    <div property="rnews:language">en</div>
    <div rel="rnews:thumbnailUri"
         href="http://http://graphics8.nytimes.com/images/common/icons/t_wb_75.gif"</div>           
</div>

Is this an anti-pattern and should we always try to have corresponding information both in visual presentation of a page and in RDFa? Or, are there some legitimate uses of visually hidden RDFa data?

Why would someone include values intended for triples as content to display and then use CSS to hide it when they can use RDFa to encode as values to not be displayed? For example:

<span property="rnews:language" content="en"/>

Doesn't the "a" in "RDFa" refer to storing values in attributes? Or what am I missing here?

First, a few arguments in favor of using invisible data content in RDFa are in[1]. Also note our two tools [2] and [3] that can generate RDFa snippets from other RDF syntaxes with ease, so you can e.g. model your data structures in nice Turtle and then derive the RDFa patterns automatically.

My main argument for the past three years of advocating this is that:

  1. It is way more productive to do so as compared to manually weaving in RDFa patterns into existing HTML page templates for non-trivial data structures (e.g. GoodRelations).

  2. In the case of dynamically generated content from templates using templating engines like Smarty or Jinja, the invisible content will be as current as the visible content, so the old argument of the data not being in sync with the visible content does mostly not hold.

  3. If the HTML is non valid / buggy, then the extraction of data from a part of invisible RDFa that itself is valid (e.g. no missing closing HTML elements) is way more reliable. HTML cleaners applied to buggy HTML can often only guess the intended tree structure and thus often attach properties to the wrong entities.

  4. The two principles of avoiding redundancy (DRY) and separation of concerns (keeping the modeling of rendering aspects separate from conceptual data modeling issues) conflict in the case of RDF in HTML.

As for the practical aspect, I recommend putting the block of invisible RDFa closely BEFORE the respective visible content. Search engines do not seem to like such blocks towards the end of the page.

Best wishes

Martin Hepp

[1] Hepp, Martin; GarcĂ­a, Roberto; Radinger, Andreas: RDF2RDFa: Turning RDF into Snippets for Copy-and-Paste, Technical Report TR-2009-01, 2009. http://www.heppnetz.de/files/RDF2RDFa-TR.pdf

[2] http://www.ebusiness-unibw.org/tools/rdf2rdfa/

[3] http://rdf-translator.appspot.com/

I'd note another strategy for hiding RDFa is to put it in the HEAD of the document, as is done in the Facebook Open Graph Protocol.

One reason for hiding is that this introduces clean physical separation of the RDFa from the rest of the document, so if I want to make major changes in the visual formatting I'm free to do that without concern that I'll break the RDFa.

My advice to alleviate issues would be to consider (RDFa) annotations in the semantics of your HTML and CSS rather than drop big hidden divs. Therefore ideally you should provide classes that represent annotations in different contexts i.e in cases where the HTML + content doesn't lend itself to inline annotation (and you have to embed rather like embedding metadata) and instances where it does.

It is important to recognise that RDFa is primarily a Semantic Web enabler not necessarily a way to annotate fragments of HTML (a secondary use case).