Rdfa-profiles

From RDFaWiki

Jump to: navigation, search

Contents

RDFa Profiles

WARNING: This section outlines an experimental addition to RDFa. It is not a standard yet.
YOU MIGHT BE LOOKING FOR: the RDFa Profile for HTML4.

RDFa Profiles are an RDFa extension to simplify the inclusion of RDFa annotation in web pages. The theory is that if, instead of having to define a ton of prefix mappings in every document, authors can reference a single external profile resource that already defines common ones, it will be easier for people to use and get right. This work is based upon ideas Mark Birbeck had mentioned in 2008. These approaches were extended by Manu Sporny to address extending the base set of reserved words and declaring prefixes using a single RDFa vocabulary.

Questions

There are a number of questions that this document covers, namely:

  • How does RDFa declare a profile document?
    • Should this mechanism be allowed only on HEAD, or throughout the document?
    • If the mechanism is specified in HEAD, should the definitions be active for the rest of the content in BODY?
    • Should @profile be allowed on every element, or should a new attribute be created?
  • How does RDFa extend the list of reserved words?
  • How does RDFa extend the list of prefix mappings?
  • Should an RDF vocabulary be used to define prefix mappings in the profile document as well as reserved words in the profile document?
  • How are name clashes resolved between profiles?
  • If @profile and @xmlns/@prefix are defined on the same element, what is the processing order?

Referencing a Profile

An RDFa profile can be imported like so: 

 <div profile="http://example.org/myprofile">

alternates to consider: 


 <link rel="profile" href="http://example.org/myprofile" />

 or

 <link rel="profile" resource="http://example.org/myprofile" />

 or

 <div rdfaprofile="http://example.org/myprofile">
  • Profile mappings can be overridden by @xmlns or @prefix (whichever is used by the language).
  • If @profile and @xmlns/@prefix are defined on the same element, the processing order is @profile first, and then @xmlns/@prefix.
  • If a parent contains a @profile/@xmlns/@prefix, and a child contains a @profile/@xmlns/@prefix - then the child values would overwrite any prefix mappings or reserved words inherited from the parent (which is the way RDFa normally operates).

Thought Process

Since triples in the current page may be affected by the external profile, it is important that the external profile is loaded before processing can continue on the current page.

Concerning load-order for prefixes and reserved words: One can think of the issue in terms of global scope (the profile document) vs. local scope (the current HTML page). It is almost universally accepted that the narrower, local scope (the HTML page) should trump the broader, global scope (the profile document). We want the HTML page author to be able to override the vocabulary author - the control should be in the hands of the page author, not the other way around.

Personally, I'd rather we have just one mechanism for declaring profiles - if we have more than one, the processing rules get more complicated and I'm not sure if it buys us anything to have two mechanisms. ManuSporny 03:38, 13 May 2009 (UTC)

The RDFa Profile Vocabulary

  • The URL for the RDFa profile vocabulary should be the same for all HTML family languages. For example: xmlns:provoc="http://w3.org/vocabs/profile-vocabulary#"
  • The profile vocabulary defines two predicates:
    • provoc:prefix is used to specify additional prefix mappings.
    • provoc:reserved is used to specify additional reserved words.

Thought Process

The previous RDFa Profiles proposal used the XHTML vocabulary document as the container document for the :PREFIX and :RESERVED extension keywords. However, RDFa is being published in HTML4 documents today (MySpace, Flickr). It is expected that the same will happen for HTML5 documents, so we must accept that RDFa will be published across all HTML family documents. It doesn't make a great deal of sense, then, for any of the HTML languages to have domain over the vocabulary terms used to express RDFa Profiles. Creating a separate vocabulary also allows future, backwards compatible additions to be made to the RDFa Profile vocabulary without

The Profile Document

  • The default profile document type for a given set of prefixes and reserved words should be an HTML document annotated with RDFa. This will hopefully make it easier for RDFa implementors since the only parser needed to process a profile document is an RDFa processor. Other mechanisms like RDF/XML could be utilized as well, but at a cost of being less human readable.

Parsing the Profile Document

  • When an RDFa parser detects a @profile attribute, it should parse each document specified in the space-separated list.
  • All triples in the profile document should be placed into a logically separate triple store from the page triples.

hAudio Example

The example below uses RDFa Profiles to express a sub-set of the hAudio Microformat.

The hAudio RDFa Profile: 

<!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" version="XHTML+RDFa 1.0" xml:lang="en">
...
<body xmlns:provoc="http://w3.org/vocabs/profile-vocabulary#">

<p>To use this profile, use the following code in your RDFa document: profile="http://example.org/haudio-rdfa-profile.html"</p>

<p>
The following RDF vocabulary prefixes are pre-defined for this RDFa Profile:
<ul>
<li about="http://purl.org/media#"><span property="provoc:prefix">media</span> maps to the Media RDF Vocabulary.</li>
<li about="http://purl.org/media/audio#"><span property="provoc:prefix">audio</span> maps to the Audio RDF Vocabulary.</li>
</ul>
</p>

<p about="http://purl.org/media/audio#Recording"><span property="provoc:reserved">haudio</span> maps to the Audio RDF Vocabulary's Recording class.</p>
<p about="http://purl.org/dc/terms/title"><span property="provoc:reserved">fn</span> maps to the Dublin Core title term.</p>
<p about="http://purl.org/dc/terms/contributor"><span property="provoc:reserved">contributor</span> maps to the Dublin Core contributor term.</p>

</body>
...
</html>

The Microformats markup for a simple hAudio item would look like this: 

<head profile="http://microformats.org/wiki/haudio#XMDP_Profile">
...
<div class="haudio">
   <span class="fn">Start Wearing Purple</span> by 
   <span class="contributor">Gogol Bordello</span>
</div>

The RDFa markup using the hAudio RDFa Profile would look like this: 

<head profile="http://example.org/haudio-rdfa-profile.html">
...
<div typeof="haudio">
   <span property="fn">Start Wearing Purple</span> by 
   <span property="contributor">Gogol Bordello</span>
</div>

While the RDFa mark-up is just as easy to author as the Microformats markup, the RDFa approach has the following benefits:

  • Fully-qualified vocabulary terms (URLs), which prevent vocabulary term clashes.
  • Distributed vocabulary innovation (you don't have to ask permission from anybody to start creating your own vocabularies).
  • A common, rigorously defined parser, which makes every RDFa parser automatically able to read any current or future RDFa vocabulary.
  • Ability to identify semantic objects with @about.

Changes to RDFa

In order to implement this mechanism, there are several changes that will be needed:

  • One major change to RDFa may include the ability for externally defined reserved words to be allowed in @property and @typeof.
  • Permit the profile URI interpretation rules.
  • A separate, non-page triple store will need to contain the values from the externally loaded RDFa profiles.
  • Tests will need to be created to test @profile behavior.
  • Changes would be necessary for existing implementations.

It is possible that some implementations are not really RDF-aware, and so would have some trouble interpreting and extracting prefix mappings from the RDFa graph parsed from a profile resource. Otherwise the interpolation of additional prefix mappings is completely consistent with the RDFa treatment of prefixes defined via xmlns and via the prefix attribute.

Original Document Content (outdated)

Warning: EVERYTHING BELOW HERE IS FROM THE OLD PROPOSAL. CONTENT BELOW MAY BE INCLUDED IN THE PROPOSAL ABOVE.

Thought Process

In HTML and XHTML, the head element has a profile attribute. This attribute has no real semantics, but takes as its value a whitespace separated list of URIs. Microformats have used this mechanism for quite a while as a way of indicating how microformat-aware processors should interpret the values found in class attributes and other places. It is an obvious extension mechanism, and should work in HTML+RDFa and XHTML+RDFa documents.

However, since RDFa is intended for use in any grammar, it would be handy to have a more generalized mechanism that we can use everywhere. The best way to do this is to define a vocabulary element with the semantics of "profile" and then use it to define references to external profiles. For example: 

  <link rel="profile" resource="someURI" />

Because we are using RDFa, such a reference would mean that a profile for the default subject is defined at someURI. And, since the rel and resource attributes are part of RDFa, they would be available in any other markup language too.

We would need to tightly define the semantics of profiles referenced in these ways. For example:

  • Any profile references in the head element or its children are inherited by the body element (for XHTML and HTML family languages).

Defining Mappings in a Profile Resource

The URI associated with a profile returns a resource that defines zero or more prefix mappings. These mappings are defined in terms of RDF, and can be created using whatever RDF grammar the profile maintainer chooses. Regardless of the grammar, in order for an RDFa processor to recognize the prefix mappings in the RDF graph associated with the resource, the prefix declaration triples must take the following form: 

  <vocabularyURI> <http://www.w3.org/1999/xhtml/vocab#PREFIX> "someprefix" .

In other words, the default RDFa vocabulary space defines a special term "prefix" that has the semantics of declaring a prefix mapping. For example, to express these mappings in an XHTML+RDFa document, you could do the following: 

  <html xmlns="http://www.w3.org/1999/xhtml" >
    <head>
      <title>A Sample RDFa Profile</title>
    </head>
    <body>
     <p>This document provides an RDFa profile that declares prefix
        mappings for the following vocabularies:</p>
     <dl>
         <dt>Dublin Core</dt>
         <dd>The <a href="http://purl.org/dc/elements/1.1/">Dublin Core
             term collection as
             <span property=":PREFIX">dc</span></a>.</dd>
         <dt>foaf</dt>
         <dd>The <a href="http://xmlns.com/foaf/0.1/">Friend of a Friend
             vocabulary as <span property=":PREFIX">foaf</span></a></dd>
     </dl>
    </body>
  </html>

When an RDFa processor sees a reference to this resource as a profile, it retrieves it and extracts the triples: 

<http://purl.org/dc/elements/1.1/> <http://www.w3.org/1999/xhtml/vocab#PREFIX> "dc" .
<http://xmlns.com/foaf/0.1/> <http://www.w3.org/1999/xhtml/vocab#PREFIX> "foaf" .

It then applies those prefixes into the its mapping collection at the point where the profile is referenced (or, if in the head of an (X)HTML document, there and in the collection for the body element.

Retrieved from "http://rdfa.info/wiki/Rdfa-profiles"