W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > February 2011

Last Call Response to ISSUE-73: RDFa Profile management

From: Manu Sporny <msporny@digitalbazaar.com>
Date: Sun, 20 Feb 2011 14:23:31 -0500
Message-ID: <4D616A33.1040803@digitalbazaar.com>
To: Toby A Inkster <mail@tobyinkster.co.uk>, Harry Halpin <hhalpin@w3.org>, RDFa WG <public-rdfa-wg@w3.org>
Hi Harry, Toby and RDFa WG members,

This is an official response from the RDFa Working Group concerning
comments around ISSUE-73: RDFa Profile management.


Harry this is indirectly related to your comments about RDFa authoring
and default profiles, which is why you're cc'ed on this e-mail. Toby
this issue came about partly as a result of your XHTML Vocabulary
document re-work.

The decisions discussed in this e-mail are summarized here:


You will want to read that wiki page before reading this e-mail, as it
will provide a framework to understand the rest of the decisions
discussed in this e-mail.

RDFa 1.1 introduced the concept of Default RDFa Profiles to accomplish a
number of important goals:

1. In order to enable more Microformats-like markup, it is beneficial
   to be able to pre-define a set of prefixes and terms in an external
   document and pull it in via the @profile attribute.
2. In order to ensure that prefixes and terms are re-used across all
   RDFa Host Languages, it is beneficial to publish these prefixes and
   terms in a set of well known documents.
3. In order to help authors that forget to pre-declare common prefixes,
   a set of commonly used prefixes is declared in a Host Language's
   Default RDFa Profile, which is loaded before an RDFa document is

The addition of this new mechanism resulted in the following concerns,
which were raised during RDFa Core 1.1 Last Call:

1. Determine if we want to add an XML+RDFa document conformance section
   to the RDFa Core specification.
2. Determine whether or not we want to have separate profile documents
   for RDFa Core and XHTML+RDFa,
3. Specify an algorithm for determining which profile document to use
   and publish it somewhere.
4. Determine the process for managing the profile documents

The findings when addressing the concerns listed above are discussed below:

XML+RDFa 1.1 Document Conformance

It was determined that the RDFa WG did want to add an XML+RDFa 1.1
Document Conformance section to the RDFa Core 1.1 specification. This
was effectively there before and is the mechanism that SVG Tiny 1.2 used
to integrate RDFa into their specification. However, the WG thought that
it would be better for us to be explicit about how authors could
integrate RDFa into their XML-based languages. This would also give
processor writers clear guidance on what to expect in a generic XML+RDFa
1.1 document.

With the addition of the XML+RDFa 1.1 section (which will be completed
in the coming week or two), RDFa Host Language authors will be able to
refer to the RDFa Core 1.1 specification instead of having to write
unnecessary boilerplate in their Host Languages.

Having an XML+RDFa 1.1 Document Conformance section will also help RDFa
processor implementers ensure that their implementations will work
across all XML-based RDFa languages.

It was implied that XML-based RDFa processors could operate in a generic
fashion before. With the addition of the new language in the RDFa Core
1.1 specification, that implied functionality has now been made explicit.

Separate Default Profile Documents

The RDFa WG has determined that it will be beneficial to have separate
RDFa Core 1.1 and (X)HTML+RDFa 1.1 profile documents. This is because
there are terms in HTML and XHTML that are not common in many other
types of RDF applications. For example, rel="colleague" is allowed in
HTML5 and may be considered for the (X)HTML+RDFa default profile, but
probably should not be a part of the RDFa Core default profile. Due to
real-world concerns like this, it was determined that there should be
separate default profile documents for RDFa Core 1.1 and certain Host

It was also determined that HTML4, XHTML1, and HTML5 must share the
terms in a default profile document because an HTML5 processor operating
on an XHTML1 document served as "text/html" will treat that document as
HTML5 instead of XHTML1 (regardless of the DOCTYPE). That is, it is
impossible to reliably determine whether or not that document is
actually an XHTML1 document or an HTML5 document from the standpoint of
an RDFa processor operating in an HTML5 environment. Since the HTML5
specification effectively states that all documents served as
"text/html" are HTML5 documents, the terms expressed via an RDFa default
profile for XHTML1, HTML4 and HTML5 must only specify rel-value terms
that are used in a way that is common to all those languages.

Specifically, values like rel="stylesheet alternate" MUST NOT produce
two triples per HTML5, but instead express that the stylesheet is an
alternate stylesheet (effectively a single triple). This is incompatible
with the way that XHTML+RDFa 1.0/1.1 generates triples and so,
XHTML+RDFa 1.1 will be forced to remove the "alternate" rel-value to
ensure that the semantics are aligned between all HTML-based host languages.

Therefore, the RDFa WG will publish at least two default profile
documents - one for RDFa Core 1.1 and one for the HTML family of Host
Languages that support RDFa.

Profile Document Selection Algorithm

The RDFa WG discussed several algorithms for determining the correct
profile to use. In the end, the simplest and most reliable mechanism
seemed to be to do the following:

1. Always load the RDFa Core 1.1 default profile first.
2. If an "application/xhtml+xml" or "text/html" MIMEType is detected,
   load the HTML+RDFa 1.1 default profile.

Step #1 will be placed into the RDFa Core 1.1 specification. Step #2
will be placed into the (X)HTML Host Language specifications.

Default Profile Document Management Process

The RDFa WG determined that a community-driven process for adding
prefixes and terms would be the most desirable when moving forward with
RDFa Default Profiles. The discussion spanned several months and in the
end, we have settled on the following approach:

1. The profiles are modified on a consistent basis and do not change
   very often (perhaps once every 1-2 years).
2. Prefixes and terms are managed by the Semantic Web Activity Lead,
   who announces changes on some well-known mailing list prior to each
   update. Prefix and Term suggestions are provided by the general
   Linked Data community via a yet-to-be-determined process (which will
   probably mirror the XPointer registry).
3. Prefixes and terms MUST NOT be /removed/ from dated profiles.
4. Prefixes and terms SHOULD NOT be /updated/ in the dated profiles.
5. Specifically, the URL strings MUST NOT change because they will make
   some semantic reasoners fail.
6. Prefixes already used by other vocabularies MUST NOT be re-used for
   new vocabularies. For example, if a new non-semantically-backwards-
   compatible version of 'geo' is released, it SHOULD be named 'geo2'
   or 'geonext'. In other words, the prefix for the new vocabulary
   SHOULD NOT be 'geo'.
7. An 'Expires' header SHOULD be included in the HTTP response for a
   profile when it is dereferenced via HTTP. RDFa processors SHOULD use
   this header to implement local caching of the profiles. It is also
   suggested that "Last-Modified", "E-Tag" and "Cache-Control" are
   included in order to further aid caching of Vocabularies.


Addressing this issue resulted in the RDFa WG visiting a number of
important topics - RDFa document conformance, RDFa processor
conformance, RDFa Host Language design, XML+RDFa, (X)HTML+RDFa, default
profile management, and a community process that is both flexible as
well as predictable.

We hope that we have struck the right balance by publishing these
findings. Know that some of these findings are in a draft stage and may
change slightly over the next Last Call period, based on feedback.
However, we feel that the majority of the framework is there, makes
sense, and will probably not change drastically before RDFa Core 1.1 and
XHTML+RDFa 1.1 proceed to Recommended status.

Harry, Toby, since this is a Last Call issue that may be related to your
feedback/work, we ask that you please respond to this e-mail and let us
know if this solution works for you.

-- manu

Manu Sporny (skype: msporny, twitter: manusporny)
President/CEO - Digital Bazaar, Inc.
blog: Towards Universal Web Commerce
Received on Sunday, 20 February 2011 19:24:04 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:19:51 UTC