- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 20 Feb 2011 14:23:31 -0500
- 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. http://www.w3.org/2010/02/rdfa/track/issues/73 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: http://www.w3.org/2010/02/rdfa/wiki/rdfa-profile-management 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 processed. 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 Languages. 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 http://digitalbazaar.com/2011/01/31/web-commerce/
Received on Sunday, 20 February 2011 19:24:04 UTC