ISSUE-71: RDFa Core 1.1 LC comments from Shelley Powers

Core - Shelley Powers

RDFa Core 1.1 LC comments from Shelley Powers

LC Comment - RDFa Core 1.1
Raised by:
Manu Sporny
Opened on:
From Shelley Powers:

I have no suggestions for tangible changes to the RDFa core. I feel that
the existing attributes and their usage has been explained sufficiently,
and there are no inconsistencies.

I really like @profile, though I know it caused some very valid concerns
at one point. However, you did address the concerns in the document. The
only thing I would suggest is ensuring that RDFa authors are aware of
the potential problems with profiles and the use of scripting to perform
RDFa processing. But since the author controls both (the use of the
script and the use of profile), they do control the solution.

The only remarks I have are more about the readability of the document.
As such, they are more suggestions rather than specific requests. The
only item would strongly advise you to consider is bringing in an
accessibility expert, because of the frequent use of visual cues.

RDFa review

In Section 2.2 Examples, you mention the link and meta elements, but in
the section following you reference them as a "concept" but the concept
was never explained. The transition was confusingly abrupt. Especially
going right into CURIEs.

In the following example, you use a CURIE, but again the transition is
lost because of the brevity of the explanation leading into the example.

I'm also a little concerned about the use of color highlighting. From an
accessibility stand point you may want to also make the text bold. In
addition, though I don't know if you want to be this verbose, you may
want to include a reference to the item of importance in the example, so
that those using a screen reader aren't left to guess what's important
in the example.

For instance, instead of the following sentence:

In many cases a block of markup will contain a number of properties that
relate to the same item; it's possible with RDFa to indicate the type of
that item...


In many cases, a block of markup contains a number of properties that
relate to the same item. You can use the RDFa typeof attribute to
indicate the type of that item...

By providing a hint about what's important in the following example, not
only do you provide an additional assistance to those without visual
impairment, you're also providing the only clue for those using a screen

The examples also reference terms that are defined later in the
document, such as using triples. For your audience, I don't know if you
need to ensure clarify to a newcomer to RDF, but you might want to
provide a brief explanation, just to ensure that a person doesn't get lost.

Moving on...

The RDF terminology section is excellent.

In the conformance section, you mention about authors needing to ensure
they remove unnecessary white space, but I'm not sure the authors are
going to see this section. Perhaps an example earlier? Just to ensure
all audience members see this critical information?

Sections 4 though 6 were good: succinct, providing just enough algorithm
to ensure consistency, without pedantically overstating the steps.

In section 6.1, I realize that this section is targeted at the person
asking, "Why not QNames?", but others could benefit from the discussion.
To ensure everyone has the same background entering the section, perhaps
a brief explanation of what is a QName?

The Chaining section was excellent. The only thing I would say about the
examples is that the spans would most likely contain actual visible
text, though that data isn't of matter to the person or people writing
the processor. This is covered in the earlier examples, but redundancy
can't hurt.

The RDFa processing rules, followed by the section on Processing in
Detail is also very well done. The Processing in Detail was a spot on
idea--rather than break flow by inserting examples into the more
detailed implementation specific section, provide the clarifying section
as a follow up.

Overall, very well done. The only other recommendation I would make
would be to have an accessibility expert review the use of visual
elements as indicators, to ensure there's enough other material provided
so that a person with visual challenges can also understand all the
important bits.
Related Actions Items:
Related emails:
  1. Re: Last Call response for ISSUE-71: LC Comments from Shelley Powers (from on 2011-02-06)
  2. Last Call response for ISSUE-71: LC Comments from Shelley Powers (from on 2011-02-06)
  3. RDFa WG telecon minutes for 2011-02-01 (from on 2011-02-01)
  4. RDFa WG telecon minutes for 2011-01-27 (from on 2011-01-27)
  5. Telecon Agenda - January 28th 2011, 1400 UTC (from on 2011-01-24)
  6. ISSUE-71: DRAFT Last Call response to Shelley Powers (from on 2011-01-23)
  7. ISSUE-71 (Core - Shelley Powers): RDFa Core 1.1 LC comments from Shelley Powers [LC Comment - RDFa Core 1.1] (from on 2011-01-04)

Related notes:

Closing issue after response from Shelley Powers noting that she is satisfied with the planned changes:

Manu Sporny, 6 Feb 2011, 20:37:14

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: 71.html,v 1.1 2015/03/27 14:12:31 vivien Exp $