ISSUE-76: RDFa Profiles

Core - Jeni Tennison 4

RDFa Profiles

LC Comment - RDFa Core 1.1
Raised by:
Manu Sporny
Opened on:
From Jeni Tennison

Some specific comments around RDFa Profiles.

(Ed) Section 2.2 Examples: When profiles are first introduced here, I think it would be helpful to:

(a) use typeof="rdfa:PrefixMapping" or typeof="rdfa:TermMapping" rather than the slightly obscure typeof=""
(b) provide an example of the RDFa Profile in Turtle, so that it's clearer what RDF triples it contains
(c) be explicit about the assumption of content negotiation of some kind that means that requests to will result in the RDFa document at

(Tech) Section 4.2 Host Language Conformance says:

> The Host Language may define a default RDFa Profile. If it does, the RDFa Profile triples that establish term or URI mappings associated with that profile must not change without changing the profile URI. RDFa Processors may embed, cache, or retrieve the RDFa Profile triples associated with that profile.
> Note: Host Languages are required to change the URI of their default profile if items are added or removed from the default profile document. The URI change is required to accomodate RDFa Processors that statically embed the terms defined in the profile. Host Languages are expected to change their profiles very rarely.

Will this restriction cause problems for HTML5 + RDFa given that HTML5 says that the rel attribute may take values defined in, which is not going to be static and may change very rapidly? Or will the profile for HTML5 set a default vocabulary and thus possibly interpret NMTOKENs that should be ignored as CURIEs?

Section 9 RDFa Profiles:

(Ed) 1st paragraph: For all that it's been developed by members of the RDFa WG, I don't think it's appropriate to call out JSON-LD as a particular syntax for RDF. Given that there are so many syntaxes available, I think it's reasonable to restrict the ones you list to those that are currently published by the W3C.

(Ed) Step 4 says:

> For every extracted triple that is the common subject of an rdfa:prefix and an rdfa:uri predicate, create a mapping from the object literal of the rdfa:prefix predicate to the object literal of the rdfa:uri predicate.

I don't think that triples can be subjects of the rdfa:prefix or rdfa:uri predicates (unless you're getting into reification). I think it should be reworded to something like:

"For every resource that is the subject of a triple with a rdfa:prefix predicate and a triple with a rdfa:uri predicate, create a mapping from rdfa:prefix object literal of that resource to the rdfa:uri object literal of that resource."

(Ed) Step 5 similarly.

(Tech) 4th paragraph says:

> If any conflict arises between two RDFa Profiles associated with URIs in the @profile value, the declaration from the RDFa Profile associated with the left-most URI takes precedence.

In general, profiles that are processed further down the tree (encountered later) override those that are specified further up the tree (encountered earlier). It seems a bit weird that within an individual @profile attribute this precedence is reversed, such that profiles that are encountered *earlier* in the attribute override (or take precedence over) those that are encountered *later*. I would have anticipated that the right-most URI would take precedence.

(Tech) Appendix B: The RDFa Vocabulary for Term Assignments declares rdfs:ranges on the rdfa:prefix (xsd:NMTOKEN), rdfa:term (xsd:NMTOKEN), rdfa:uri (xsd:anyURI) and rdfa:vocabulary (xsd:anyURI) properties. However, none of the examples in the rest of the spec use datatypes. Should the rdfs:ranges be removed? I think it should be made clear in Section 9 that the values of these properties must be plain literals, if that's the intention.
Related Actions Items:
No related actions
Related emails:
  1. RDFa WG telecon minutes for 2011-03-24 (from on 2011-03-24)
  2. LC Response to ISSUE-76 (from on 2011-03-10)
  3. Re: ISSUE-76 (Core - Jeni Tennison 4): RDFa Profiles [LC Comment - RDFa Core 1.1] (from on 2011-03-03)
  4. Re: ISSUE-76 (Core - Jeni Tennison 4): RDFa Profiles [LC Comment - RDFa Core 1.1] (from on 2011-03-03)
  5. Re: ISSUE-76 (Core - Jeni Tennison 4): RDFa Profiles [LC Comment - RDFa Core 1.1] (from on 2011-03-03)
  6. Re: ISSUE-76 Triage (from on 2011-03-02)
  7. Re: ISSUE-76 Triage (from on 2011-03-01)
  8. Preparing Official LC Responses (from on 2011-02-06)
  9. RDFa WG telecon minutes for 2011-02-03 (from on 2011-02-03)
  10. Telecon Agenda - February 4th 2011, 1400 UTC (from on 2011-02-01)
  11. ISSUE-76 Triage (from on 2011-01-27)
  12. ISSUE-76 (Core - Jeni Tennison 4): RDFa Profiles [LC Comment - RDFa Core 1.1] (from on 2011-01-13)

Related notes:

Nathan is responsible for this issue.
The changes are made in the document.

Shane McCarron, 2 Mar 2011, 03:50:50

The response was sent by Nathan, waiting on a reply:

Manu Sporny, 24 Mar 2011, 00:52:49

Display change log ATOM feed

Chair, Staff Contact
Tracker: documentation, (configuration for this group), originally developed by Dean Jackson, is developed and maintained by the Systems Team <>.
$Id: 76.html,v 1.1 2015/03/27 14:12:31 vivien Exp $