Introduction

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.

Default RDFa Profiles

1. There will be one versioned default RDFa profile, which XML+RDFa will use: http://www.w3.org/profile/rdfa-1.1
2. There will be one versioned default (X)HTML+RDFa profile: http://www.w3.org/profile/html-rdfa-1.1
3. The XML+RDFa part of the RDFa Core 1.1 specification instructs processors to load the RDFa Core 1.1 default profile (http://www.w3.org/profile/rdfa-1.1) before processing a document.
4. The XHTML+RDFa 1.1 and HTML+RDFa 1.1 specifications instruct the processor to first load the RDFa Core 1.1 default profile (http://www.w3.org/profile/rdfa-1.1) and then load the (X)HTML+RDFa 1.1 default profile (http://www.w3.org/profile/html-rdfa-1.1) before processing a document.
5. Default profiles may be cached and/or hard-coded in implementations. When profiles are hard-coded, implementers MUST keep their implementations in sync with the published/live profiles.

Default RDFa Profile Management

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. Specifically, the URL strings MUST NOT change because they will make some semantic reasoners fail.
5. 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'.
6. 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.

Maintaining a Vocabulary in a Default RDFa Profile

1. The vocabulary MUST be long-lived and exist at the location specified in the default profile for at least 5 years, with 10-30 years being favored.
2. If the storage location of the vocabulary may change over time, the vocabulary maintainer SHOULD use a persistent URL re-directing service to provide a URL that is guaranteed to resolve to the vocabulary document over the course of 30+ years. For example, the http://purl.org/ service is one such persistent URL re-directing service.
3. The vocabulary SHOULD support Content Negotiation for common formats like HTML+RDFa, TURTLE, or N3.
4. The semantics of a vocabulary term SHOULD NOT change once a significant group of people start to use the term. The word "significant" is dependent on the size of the community using the vocabulary term, so maintainers are asked to use their best judgement when dealing with potentially backwards-incompatible changes. In general, not changing the semantics of vocabulary terms after the vocabulary has been included in any Default RDFa Profile is RECOMMENDED.
5. Prefixes used to refer to your vocabulary MUST NOT be re-used from old vocabularies. If there is ever doubt, refer to http://prefix.cc/ and search for the short-name you intend to give to your new vocabulary. 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'.

Authoring Content using Default RDFa Profiles

1. Authors are strongly encouraged to use @prefix to ensure that prefixes that they believe to be in the default RDFa Profile continue to mean what they want them to mean. For example, one can almost never go wrong by declaring "foaf" using the @prefix attribute.
2. If authors do not want to use @prefix, they MAY use @profile to specify a default RDFa profile for the version of RDFa that they are using. For example, declaring @profile to be "http://www.w3.org/profile/html-rdfa-1.1" for HTML+RDFa 1.1 documents is a good practice.
3. Authors MUST NOT assume the prefixes/terms in the default profile will remain the same over multiple years. If they want to utilize the default RDFa profile, they SHOULD specify the profile to use via the @profile attribute in their documents. For example, declaring @profile to be "http://www.w3.org/profile/html-rdfa-1.1" for HTML+RDFa 1.1 documents is a good practice as it future-proofs the document markup against any removals of prefixes from the default vocabulary.
4. If authors do not use @prefix and do not use @profile to point to the default profile, their content MAY change semantic meaning in the future (such as when RDFa 2.0 is released). For example, if an author does not declare "foaf" using @prefix or pull in the prefix via @profile, then the processor will rely on the definitions in the default profile to expand the foaf prefix. This is a fine assumption to make for RDFa 1.1, but may not be a safe assumption to make in RDFa 2.0. That is, foaf may expand to a different URL in RDFa 2.0 than it does in RDFa 1.1. In order to protect against this possibility, authors SHOULD use suggestions #1 or #2 to future-proof their markup.