--- a/html-data-guide/index.html Sun Dec 11 22:16:37 2011 +0000
+++ b/html-data-guide/index.html Mon Dec 12 16:27:13 2011 +0000
@@ -328,13 +328,13 @@
Writing out IRIs in full can clutter HTML so RDFa provides four mechanisms to shorten IRIs:
</p>
<ul>
- <li>There are several built-in prefixes which can be used for popular vocabularies. These are listed as part of the <a href="http://www.w3.org/2011/rdfa-context/rdfa-1.1.html" class="external text" title="http://www.w3.org/2011/rdfa-context/rdfa-1.1.html" rel="nofollow">RDFa 1.1 Core initial context</a>. Any IRI within one of these <a title="vocabulary">vocabularies</a> can be abbreviated using the <code>prefix:name</code> notation.</li>
+ <li>There are several built-in prefixes which can be used for popular vocabularies. These are listed as part of the <a href="http://www.w3.org/profile/rdfa-1.1">RDFa 1.1 Core initial context</a>. Any IRI within one of these <a title="vocabulary">vocabularies</a> can be abbreviated using the <code>prefix:name</code> notation.</li>
<li>The <code>@prefix</code> attribute can be used to define additional prefixes for other vocabularies.</li>
<li>The <code>@vocab</code> attribute defines a default <a>vocabulary</a> within its scope; any IRIs that begin with this vocabulary can be abbreviated to a short name (the remainder of the IRI after the vocabulary IRI).</li>
<li>Namespace declarations (<code>@xmlns:prefix</code> attributes) can also be used to define prefixes. <strong>This mechanism is deprecated and should not be used.</strong></li>
</ul>
<p>
- Note that if you use any of the last three mechanisms, the shortened IRIs can only be understood when they are within the scope of the relevant attributes. These can be easy to mislay when people copy and paste HTML from one place to another, or as the result of template changes in a content-management system. We therefore recommend that these attributes are avoided where possible — use the built-in prefixes or full IRIs in preference — and, where they are used, placed on elements that represent <a title="entity">entities</a> (those with <code>@about</code> or <code>@typeof</code> attributes) and repeated on each entity element rather than being inherited from an ancestor element.
+ Note that if you use any of the last three mechanisms, the shortened IRIs can only be understood when they are within the scope of the relevant attributes. These can be easy to mislay when people copy and paste HTML from one place to another, or as the result of template changes in a content-management system. We therefore recommend that these attributes are avoided where possible — use the built-in prefixes or full IRIs in preference — and, where they are used, placed on elements that represent <a title="entity">entities</a> (those with <code>@about</code> or <code>@typeof</code> attributes) and repeated on each entity element rather than being inherited from an ancestor element. For more details, see <a href="#context-independence" class="sectionRef"></a>.
</p>
</section>
<section id="mixing-vocabularies-microdata">
@@ -348,7 +348,7 @@
<p>
You might find that you need to target two consumers who each recognise items using <a title="type">types</a> from different <a title="vocabularies">vocabularies</a>. For example, you might want to both target schema.org and use the vEvent vocabulary with the original HTML:
</p>
- <pre><a href="nba-miami-philidelphia-game3.html">
+ <pre><a href="nba-miami-philadelphia-game3.html">
NBA Eastern Conference First Round Playoff Tickets:
Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1)
</a>
@@ -385,7 +385,7 @@
</p>
<pre><div itemscope itemtype="http://microformats.org/profile/hcalendar#vevent">
<strong><link itemprop="http://schema.org/type" href="http://schema.org/Event"></strong>
- <a itemprop="url <strong>http://schema.org/url</strong>" href="nba-miami-philidelphia-game3.html">
+ <a itemprop="url <strong>http://schema.org/url</strong>" href="nba-miami-philadelphia-game3.html">
NBA Eastern Conference First Round Playoff Tickets:
<span itemprop="summary <strong>http://schema.org/name</strong>"> Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) </span>
</a>
@@ -421,8 +421,8 @@
"type": [ "http://microformats.org/profile/hcalendar#vevent" ],
"properties": {
"http://schema.org/type": [ "http://schema.org/Event" ],
- "url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
- "http://schema.org/url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
+ "url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
+ "http://schema.org/url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
"summary": [ " Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) " ],
"http://schema.org/name": [ " Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) " ],
"dtstart": [ "2016-04-21T20:00" ],
@@ -456,7 +456,7 @@
<pre>{
"type": [ "http://schema.org/Event" ],
"properties": {
- "url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
+ "url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
"name": [ " Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) " ],
"startDate": [ "2016-04-21T20:00" ],
"location": [{
@@ -505,12 +505,12 @@
The second method of supporting multiple <a title="property">properties</a> is to have the <a>entity</a> represented by two (or more) microdata items on the page. To enable dragging and dropping the data from these items, they should be nested inside each other. Properties can be set on the outer element using <code>link</code> and <code>meta</code> elements which are hidden from users, while the visible content of the page is marked up by the inner element.
</p>
<pre><div itemscope itemtype="<strong>http://microformats.org/profile/hcalendar#vevent</strong>">
- <strong><link itemprop="url" href="nba-miami-philidelphia-game3.html">
+ <strong><link itemprop="url" href="nba-miami-philadelphia-game3.html">
<meta itemprop="summary" content="Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1)">
<meta itemprop="dtstart" content="2016-04-21T20:00">
<meta itemprop="location" content="Wells Fargo Center, Philadelphia, PA"></strong>
<div itemscope itemtype="<strong>http://schema.org/Event</strong>">
- <a itemprop="url" href="nba-miami-philidelphia-game3.html">
+ <a itemprop="url" href="nba-miami-philadelphia-game3.html">
NBA Eastern Conference First Round Playoff Tickets:
<span itemprop="name"> Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) </span>
</a>
@@ -542,7 +542,7 @@
"items": [{
"type": [ "http://microformats.org/profile/hcalendar#vevent" ],
"properties": {
- "url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
+ "url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
"summary": [ "Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1)" ],
"dtstart": [ "2016-04-21T20:00" ],
"location": [ "Wells Fargo Center, Philadelphia, PA" ]
@@ -550,7 +550,7 @@
}, {
"type": [ "http://schema.org/Event" ],
"properties": {
- "url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
+ "url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
"name": [ " Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) " ],
"startDate": [ "2016-04-21T20:00" ],
"location": [{
@@ -601,7 +601,7 @@
<pre><div <strong>class="vevent"</strong>
<strong>itemscope itemtype="http://microformats.org/profile/hcalendar#vevent"</strong>
<strong>vocab="http://schema.org/" typeof="Event"</strong>>
- <a <strong>class="url" itemprop="url" property="url"</strong> href="nba-miami-philidelphia-game3.html">
+ <a <strong>class="url" itemprop="url" property="url"</strong> href="nba-miami-philadelphia-game3.html">
NBA Eastern Conference First Round Playoff Tickets:
<span <strong>class="summary" itemprop="summary" property="name"</strong>> Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) </span>
</a>
@@ -635,7 +635,7 @@
<pre>{
"type": [ "vevent" ],
"properties": {
- "url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
+ "url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
"summary": [ " Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) " ],
"dtstart": [ "2016-04-21T20:00:00" ],
"location": [ "\n \n \n Wells Fargo Center\n \n \n Philadelphia,\n PA\n \n \n " ]
@@ -647,7 +647,7 @@
<pre>{
"type": [ "http://microformats.org/profile/hcalendar#vevent" ],
"properties": {
- "url": [ "http://example.com/nba-miami-philidelphia-game3.html" ],
+ "url": [ "http://example.com/nba-miami-philadelphia-game3.html" ],
"summary": [ " Miami Heat at Philadelphia 76ers - Game 3 (Home Game 1) " ],
"dtstart": [ "2016-04-21T20:00:00" ],
"location": [ "\n \n Wells Fargo Center\n \n \n Philadelphia,\n PA\n \n " ]
@@ -673,7 +673,7 @@
schema:offerCount "1938" ;
] ;
schema:startDate "2016-04-21T20:00:00"^^xsd:dateTime ;
- schema:url <http://example.com/nba-miami-philidelphia-game3.html> ;
+ schema:url <http://example.com/nba-miami-philadelphia-game3.html> ;
.</pre>
<p>
It is particularly important to check pages in which <a title="syntax">syntaxes</a> are mixed together using an appropriate validator for each format.
@@ -688,10 +688,10 @@
Microformats do not use <code>link</code> or <code>meta</code> elements within the content of the page and in some cases require particular elements to be used to encode information. In particular, <code>abbr</code> must be used to support the <a href="http://microformats.org/wiki/datetime-design-pattern">datetime-design-pattern</a>. Conversely, properties that hold dates and times must be marked up using the <code>time</code> element in microdata. Using the <code>time</code> element is also advantageous in RDFa, as it automatically confers the appropriate datatype to the value. So when using both microformats and RDFa or microdata, you must nest a <code>time</code> element within a <code>abbr</code> element or vice versa, as shown here:
</p>
<pre><strong><time itemprop="dtstart" property="startDate" content="2016-04-21T20:00:00"></strong>
- <abbr <strong>class="dtstart" title="2016-04-21T20:00:00"</strong>>
- Thu, 04/21/16 8:00 p.m.
- </abbr>
- </time></pre>
+ <abbr <strong>class="dtstart" title="2016-04-21T20:00:00"</strong>>
+ Thu, 04/21/16 8:00 p.m.
+ </abbr>
+</time></pre>
<p>
RDFa <a title="vocabulary">vocabularies</a> are typically stricter in the range of <a title="value">values</a> that they accept for <a title="property">properties</a> that take dates and times; it is best to use the syntax <code>YYYY-MM-DD</code> for dates, <code>hh:mm:ss</code> for times and <code>YYYY-MM-DDThh:mm:ss</code> for dateTimes to be compliant with the <a href="http://www.w3.org/TR/xmlschema-2/#dateTime">XML Schema dates and times</a> which RDFa-based vocabularies will typically use.
</p>
@@ -706,7 +706,7 @@
Link relations required in certain microformats, particularly XFN, clash with the use of RDFa's <code>@vocab</code> attribute. For example:
</p>
<pre><a vocab="http://purl.org/dc/terms/"
- rel="date" href="http://reference.data.gov.uk/id/day/2011-11-15">15th November 2011</a></pre>
+ rel="date" href="http://reference.data.gov.uk/id/day/2011-11-15">15th November 2011</a></pre>
<p>
will result in a <code>dc:date</code> relationship based on RDFa processing, but XFN processing will assume that the link is to someone whom the author of the HTML page is dating. It is best to avoid using <code>@vocab</code> on any ancestor of an element that contains a <code>@rel</code> attribute: use <code>@property</code> instead to provide RDFa properties, and if you need to use <code>@rel</code> attributes on your links, use prefixes instead of <code>@vocab</code> in RDFa.
</p>
@@ -737,60 +737,60 @@
When using RDFa, any <a>property</a> elements within an element with a <code>@href</code> (ie a link) will be taken as being properties of the <a>entity</a> identified by the URL in that <code>@href</code>. This is not the case in microdata or microformats, where the <code>@href</code> attribute is only ever used to provide a value for a property. For example, the microdata:
</p>
<pre><div itemscope itemtype="http://schema.org/AggregateRating">
- Ratings:
- <a href="ratings"
- title="23,201 IMDb users have given an average vote of 7.2/10">
- <span itemprop="ratingCount">23,201</span> users</a>
- </div></pre>
+ Ratings:
+ <a href="ratings"
+ title="23,201 IMDb users have given an average vote of 7.2/10">
+ <span itemprop="ratingCount">23,201</span> users</a>
+</div></pre>
<p>
will generate an <code>http://schema.org/AggregateRating</code> whose <code>ratingCount</code> is <code>23,201</code>. However, the similar RDFa:
</p>
<pre><div vocab="http://schema.org/" typeof="AggregateRating">
- Ratings:
- <a href="ratings"
- title="23,201 IMDb users have given an average vote of 7.2/10">
- <span property="ratingCount">23,201</span> users</a>
- </div></pre>
+ Ratings:
+ <a href="ratings"
+ title="23,201 IMDb users have given an average vote of 7.2/10">
+ <span property="ratingCount">23,201</span> users</a>
+</div></pre>
<p>
creates two unconnected statements:
</p>
<pre>[] a schema:AggregateRating .
- <http://example.com/ratings> schema:ratingCount "23,201" .</pre>
+<http://example.com/ratings> schema:ratingCount "23,201" .</pre>
<p>
If the link doesn't have a <code>@rel</code> attribute, as in this example, you can avoid the <code>@href</code> attribute creating a new subject by adding an empty <code>@property</code> attribute to the link:
</p>
<pre><div vocab="http://schema.org/" typeof="AggregateRating">
- Ratings:
- <a href="ratings" <strong>property=""</strong>
- title="23,201 IMDb users have given an average vote of 7.2/10">
- <span property="ratingCount">23,201</span> users</a>
- </div></pre>
+ Ratings:
+ <a href="ratings" <strong>property=""</strong>
+ title="23,201 IMDb users have given an average vote of 7.2/10">
+ <span property="ratingCount">23,201</span> users</a>
+</div></pre>
<p>
If the link <em>does</em> have a <code>@rel</code> attribute, it is usually easiest to move the relevant property outside the link, for example:
</p>
<pre><div vocab="http://schema.org/" typeof="AggregateRating">
- Ratings:
- <strong><span property="ratingCount" content="23201"></span></strong>
- <a href="ratings" rel="nofollow"
- title="23,201 IMDb users have given an average vote of 7.2/10">
- 23,201 users</a>
- </div></pre>
+ Ratings:
+ <strong><span property="ratingCount" content="23201"></span></strong>
+ <a href="ratings" rel="nofollow"
+ title="23,201 IMDb users have given an average vote of 7.2/10">
+ 23,201 users</a>
+</div></pre>
<p>
The alternative is to identify the subject explicitly using a <code>@resource</code> attribute on both the outer element and the link element:
</p>
<pre><div vocab="http://schema.org/" typeof="AggregateRating"
- <strong>resource="_:rating"</strong>>
- Ratings:
- <a href="ratings" rel="nofollow" <strong>resource="_:rating"</strong>
- title="23,201 IMDb users have given an average vote of 7.2/10">
- <span property="ratingCount">23,201</span> users</a>
- </div></pre>
+ <strong>resource="_:rating"</strong>>
+ Ratings:
+ <a href="ratings" rel="nofollow" <strong>resource="_:rating"</strong>
+ title="23,201 IMDb users have given an average vote of 7.2/10">
+ <span property="ratingCount">23,201</span> users</a>
+</div></pre>
<p>
These three methods all generate the same RDF:
</p>
<pre>[] a schema:AggregateRating ;
- schema:ratingCount "23,201" ;
- .</pre>
+ schema:ratingCount "23,201" ;
+ .</pre>
</section>
<section>
@@ -805,25 +805,51 @@
<section>
<h3>Good Publishing Practice</h3>
<p>
- Valid HTML is particularly important in pages that contain embedded markup. All methods of embedding data within HTML use the structure of the HTML to determine the meaning of the additional markup. For example, in microdata the item to which an element with an <code>@itemprop</code> attribute assigns a <a>property</a> is usually the closest ancestor element with a <code>@itemscope</code> attribute.
- </p>
- <p>
- In some cases, elements can be moved when HTML is parsed into a DOM. This can lead to <a title="property">properties</a> unexpectedly referring to the wrong entity, and, if you are serving your documents as XHTML (with a <code>application/xhtml+xml</code> mime type), it can cause discrepancies between the data gleaned by XML-based consumers and HTML-aware consumers. There are two causes for this:
+ There are a number of practices which can help ensure good quality HTML Data that can be easily reused by consumers.
</p>
- <ul>
- <li>
- Error correction in HTML parsing can restructure invalid HTML is restructured to make it valid, for example non-table markup within a table is moved to before the table. This includes <code>link</code> and <code>meta</code> elements that are directly within the <code>table</code> element. You can avoid this restructuring by making sure that your HTML is valid so that it is not needed.
- </li>
- <li>
- Some older browsers may move <code>meta</code> and/or <code>link</code> elements in the <code>body</code> of an HTML document to within the <code>head</code> element, because they could not validly appear within the body in older versions of HTML. If you are targeting consumers which run within older browsers, such as scripts or plug-ins, you can avoid this restructuring by using empty <code>span</code> or other elements instead of <code>link</code> or <code>meta</code>; other consumers should be using an up-to-date HTML5 parser which will not do this.
- </li>
- </ul>
- <p>
- It is good practice to test the data that you expose within your page against a parser that will show you the data your page contains. It is also good practice to test the data that you expose using a tool that understands the <a>vocabulary</a> you are using. Consumers may provide testing tools and validators for this purpose, or you may need to check the way that vocabulary-specific tools behave with your data.
- </p>
- <p>
- The goal of publishing HTML data is to enable consumers to reuse it. To make it clear how the HTML data you publish can be reused, you should include information about the rights holder and license that the information is made under. There are a number of <a title="vocabulary">vocabularies</a> that enable you to do this, such as schema.org, rel-license, Creative Commons and Dublin Core. Your target consumers should indicate which <a title="format">formats</a> they understand when it comes to expressing licensing information and which licenses they know about, and you should choose a relevant <a>format</a> in the same way as you do for the core data that you are publishing.
- </p>
+ <section>
+ <h4>Valid HTML</h4>
+ <p>
+ Valid HTML is particularly important in pages that contain embedded markup. All methods of embedding data within HTML use the structure of the HTML to determine the meaning of the additional markup. For example, in microdata the item to which an element with an <code>@itemprop</code> attribute assigns a <a>property</a> is usually the closest ancestor element with a <code>@itemscope</code> attribute.
+ </p>
+ <p>
+ In some cases, elements can be moved when HTML is parsed into a DOM. This can lead to <a title="property">properties</a> unexpectedly referring to the wrong entity, and, if you are serving your documents as XHTML (with a <code>application/xhtml+xml</code> mime type), it can cause discrepancies between the data gleaned by XML-based consumers and HTML-aware consumers. There are two causes for this:
+ </p>
+ <ul>
+ <li>
+ Error correction in HTML parsing can restructure invalid HTML is restructured to make it valid, for example non-table markup within a table is moved to before the table. This includes <code>link</code> and <code>meta</code> elements that are directly within the <code>table</code> element. You can avoid this restructuring by making sure that your HTML is valid so that it is not needed.
+ </li>
+ <li>
+ Some older browsers may move <code>meta</code> and/or <code>link</code> elements in the <code>body</code> of an HTML document to within the <code>head</code> element, because they could not validly appear within the body in older versions of HTML. If you are targeting consumers which run within older browsers, such as scripts or plug-ins, you can avoid this restructuring by using empty <code>span</code> or other elements instead of <code>link</code> or <code>meta</code>; other consumers should be using an up-to-date HTML5 parser which will not do this.
+ </li>
+ </ul>
+ </section>
+ <section id="context-independence">
+ <h4>Context Independence</h4>
+ <p>
+ One of the ways in which people learn how to publish information on the web is to view the source of other web pages and copy portions of their contents into their own pages. It is also common for web pages to be constructed from templates and for these to change as the result of site redesigns. In both these situations, it can be easy to lose any context information that is used to interpret the HTML Data embedded within the page.
+ </p>
+ <p>
+ To help preserve relevant context information:
+ </p>
+ <ul>
+ <li>when using microformats, use microformats-2 if possible as the prefixed classnames are less likely to be changed during site redesigns; use the top-most microformat class as near as possible to the properties of the relevant <a>entity</a></li>
+ <li>when using RDFa, avoid using namespace declarations, <code>@prefix</code> or <code>@vocab</code>; if you do use them, add them as close to the elements that use the prefixes or vocabulary as possible</li>
+ <li>when using microdata, add the <code>@itemscope</code> attribute as closely as possible to the data and use <code>@itemtype</code> where a relevant <a>type</a> is available rather than relying on consumers to infer the type</li>
+ </ul>
+ </section>
+ <section>
+ <h4>Testing</h4>
+ <p>
+ It is good practice to test the data that you expose within your page against a parser that will show you the data your page contains. It is also good practice to test the data that you expose using a tool that understands the <a>vocabulary</a> you are using. Consumers may provide testing tools and validators for this purpose, or you may need to check the way that vocabulary-specific tools behave with your data.
+ </p>
+ </section>
+ <section>
+ <h4>Clear Licensing</h4>
+ <p>
+ The goal of publishing HTML data is to enable consumers to reuse it. To make it clear how the HTML data you publish can be reused, you should include information about the rights holder and license that the information is made under. There are a number of <a title="vocabulary">vocabularies</a> that enable you to do this, such as schema.org, rel-license, Creative Commons and Dublin Core. Your target consumers should indicate which <a title="format">formats</a> they understand when it comes to expressing licensing information and which licenses they know about, and you should choose a relevant <a>format</a> in the same way as you do for the core data that you are publishing.
+ </p>
+ </section>
</section>
</section>
@@ -839,7 +865,7 @@
If current <a title="format">formats</a> do not encode the information you need to the detail you need it for your application, publishers will be more likely to publish extra data for you to consume if you:
</p>
<ul>
- <li><a href="/wiki/HTML_Data_Vocabularies" title="HTML Data Vocabularies">extend existing common vocabularies</a> they are already using</li>
+ <li><a href="#extending-vocabularies">extend existing common vocabularies</a> they are already using</li>
<li>consume data from a <a>syntax</a> they already use</li>
</ul>
<p>
@@ -1019,7 +1045,14 @@
<section>
<h4>Extending Microdata Vocabularies</h4>
<p>
- Microdata items can have both <a title="property">properties</a> that are scoped to the <a>type</a> of the item and <a title="property">properties</a> that have absolute URLs. The acceptability of non-URL properties is determined by the <a>vocabulary</a> author of the type of the item; some vocabularies may define a set of acceptable properties, others say that any properties are acceptable. In all cases, however, it's possible to add properties to items if they are named with an absolute URL. Third parties who wish to extend an existing type with new properties should check the constraints of the type being extended to work out whether it's possible to use a non-URL property or not. Note that there is always a possibility, if you do use a non-URL property name, that your extension will conflict with an extension made by someone else; properties whose names are absolute URLs do not have this issue but are more verbose when used in markup.
+ Microdata items can have both <a title="property">properties</a> that are scoped to the <a>type</a> of the item and <a title="property">properties</a> that have absolute URLs. There are two ways you can extend a type by adding new properties:
+ </p>
+ <ul>
+ <li>use a property that is an absolute URL</li>
+ <li>if the vocabulary allows it, use a new short-name property</li>
+ </ul>
+ <p>
+ Third parties who wish to extend an existing type with new properties should check the constraints of the type being extended to work out whether it's possible to use a non-URL property or not. Note that there is always a possibility, if you do use a non-URL property name, that your extension will conflict with an extension made by someone else; properties whose names are absolute URLs do not have this issue but are more verbose when used in markup.
</p>
<p>
Microdata does not allow items to have multiple <a title="type">types</a> from different vocabularies. Some vocabularies, such as schema.org, may permit third parties to freely extend existing types within that vocabulary. In this case, items should be assigned both the supertype and the extension type within the <code>@itemtype</code> attribute. For example, schema.org describes a <a href="http://schema.org/docs/extension.html">method of extending its vocabulary</a> that involves identifying an appropriate supertype or superproperty and appending a <code>/</code> and then the name of a subtype or subproperty. Schema.org also permits anyone to create additional non-URL properties on these new types. To extend schema.org's types with a type for a member of parliament, a <a>vocabulary</a> author might use the URI <code>http://schema.org/Person/MP</code>, and mark up their page with
@@ -1153,7 +1186,7 @@
<section class='appendix'>
<h2>Acknowledgements</h2>
<p>
- Many thanks to the members of the HTML Data Working Group for their contributions to this document.
+ Many thanks to the members of the HTML Data Task Force for their contributions to this document.
</p>
</section>
</body>