forked from schemaorg/schemaorg
-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathhowwework.html
428 lines (376 loc) · 37.2 KB
/
howwework.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
<!DOCTYPE html>
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>How we work - schema.org</title>
<meta name="description" content="Schema.org is a set of extensible schemas that enables webmasters to embed
structured data on their web pages for use by search engines and other applications." />
<link rel="stylesheet" type="text/css" href="schemaorg.css" />
<link href="prettify.css" type="text/css" rel="stylesheet" />
<script type="text/javascript" src="prettify.js"></script>
<script type="text/javascript" src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.min.js"></script>
<!-- ##### Generated insert [CSEScript-start] see scripts/genhtmlinserts.sh ##### -->
<!-- Enable CSE Search -->
<script>
(function() {
var cx = '013516846811604855281:nj5laplixaa'; // Insert your own Custom Search engine ID here
var gcse = document.createElement('script'); gcse.type = 'text/javascript'; gcse.async = true;
gcse.src = 'https://cse.google.com/cse.js?cx=' + cx;
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(gcse, s);
})();
</script>
<!-- ##### Generated insert [CSEScript-end] see scripts/genhtmlinserts.sh ##### -->
<script type="text/javascript">
$(document).ready(function(){
prettyPrint();
setTimeout(function(){
$('.atn').each(function(i) {
if (($(this).text() == 'itemscope') || ($(this).text() == 'itemtype') || ($(this).text() == 'itemprop') || ($(this).text() == 'itemid') || ($(this).text() == 'time') || ($(this).text() == 'datetime') || ($(this).text() == 'vocab') || ($(this).text() == 'property') || ($(this).text() == 'typeOf') || ($(this).text() == 'rel'))
$(this).addClass('custom');
});
}, 500);
});
</script>
<style>
dt { font-weight: bold; padding: 0.3em 0 0.4em 0;}
</style>
</head>
<body>
<!-- ##### Generated insert [DOCSHDR-start] see scripts/genhtmlinserts.sh ##### -->
<div id="container">
<div id="intro">
<div id="pageHeader">
<div class="wrapper">
<div id="sitename">
<h1>
<a href="../">schema.org</a>
</h1>
</div>
<div id="cse-search-form" style="width: 400px;">
<div class="gcse-searchbox-only" data-resultsurl="search_results.html"></div>
</div>
</div>
</div>
</div>
</div>
<div id="selectionbar">
<div class="wrapper">
<ul>
<li>
<a href="documents.html" >Documentation</a>
</li>
<li>
<a href="schemas.html" >Schemas</a>
</li>
<li>
<a href="../" >Home</a>
</li>
</ul>
</div>
</div>
<!-- ##### Generated insert [DOCSHDR-end] see scripts/genhtmlinserts.sh ##### -->
<div id="mainContent">
<h1>How We Work</h1>
<p>
This document provides a brief overview of schema.org's process for developing and
changing schemas. It accompanies the <a href="about.html">about schema.org</a> page
which describes the organizational structure of the project.
</p>
<p>
<b>Note</b>: the <a href="http://schema.org/">schema.org</a> site contains the officially released
version of schema.org, while <a href="http://webschemas.org/">webschemas.org</a> is the very latest
work-in-progress development branch of schema.org containing more recent fixes and improvements but which may
contain changes that do not represent the consensus of the wider community or of the project <a href="about.html#cgsg">steering group</a>. See <a href="#pending">"pending"</a>
below for more details.
</p>
<p>This document contains a minimal amount of technical detail sufficient to explain
our approach to schema evolution. Operational details for project collaborators can be found via
the <a href="https://www.w3.org/community/schemaorg/how-we-work/">how we work</a>
section of the <a href="https://www.w3.org/community/schemaorg/">Schema.org W3C Community Group</a>.
</p>
<h2>Overview</h2>
<p id="#ataglance">A quick summary.</p>
<ul>
<li>Most materials on schema.org are updated via <a href="http://schema.org/docs/releases.html">official named releases</a> (every few weeks).</li>
<li>Simple improvements around supporting documentation, examples, sofware bugs etc. can be fast-tracked by the project <a href="about.html#cgsg">steering group</a> as "Early Access Fixes"; these are
also recorded in the <a href="http://schema.org/docs/releases.html">releases</a> page, which may also be updated in between formal releases.</li>
<li>Improvements are discussed in our <a href="http://www.w3.org/community/schemaorg">community group</a> at W3C, typically in the project's <a href="http://github.com/schemaorg/schemaorg/issues">github issue tracker</a>.</li>
<li>A work-in-progress development version of the site named "<a href="http://webschemas.org/">webschemas.org</a>" is maintained by the <a href="#webmaster">project webmaster</a> based on github and W3C community group discussions, proposals and change requests. It forms the basis for periodic "release candidates" and reflects the current state of the project's public Github repository.</li>
<li>A "live" hosted extension dedicated to "pending" new vocabulary proposals is maintained as part of this process at <a href="http://pending.webschemas.org/">pending.webschemas.org</a>, and can be updated (including to <a href="http://pending.schema.org/">pending.schema.org</a>) by the <a href="#webmaster">project webmaster</a> immediately, rather than
waiting for a full official release. This serves to highlight possible new vocabulary improvements but may not always reflect wider consensus in the community and steering groups.</li>
<li>Periodically, snapshots of the community's <em>rough consensus</em> are published as release candidates by the project webmaster, for review by the <a href="about.html#cgsg">steering group</a>.</li>
<li>After steering group <a href="#w3rel">review</a> and approval, if no concerns are raised within 10 business days, the schema.org site is updated with the new release by the project webmaster.</li>
</ul>
<h2>Versioning and change control</h2>
<p>
Schema.org is developed incrementally. Since 2011 we have published several
substantial updates a year. These are known as <em>releases</em> and are
documented on the <a href="/docs/releases.html">releases</a> page. Each release
has a name that is assigned upon publication (e.g. "2.1"). Recent releases have
also been given project-internal code names prior to launch, e.g. "sdo-phobos",
which makes it easier to decide upon the final name (e.g. "2.9" versus "3.0") as the work
develops.
</p>
<p>
The content of each release is based on public discussions hosted on W3C's
community group platform and on the Github site. All <a href="/docs/releases.html">changes</a> to the
project have been through unanimous agreement of the Steering Group membership, strongly
informed by the opinions, contributions and discussions in the wider community.
</p>
<p>
Recently we have been expanding on this model with two types of <a href="extension.html">extension</a> vocabulary: hosted and external extensions.
Hosted extensions are effectively part of schema.org but "tagged" within a subdomain (e.g. <a href="http://bib.schema.org/">bib.schema.org</a>,
<a href="http://auto.schema.org/">auto.schema.org</a>). External extensions (e.g.
see <a href="http://blog.schema.org/2016/02/gs1-milestone-first-schemaorg-external.html">GS1's Web Vocabulary</a>) are published elsewhere on the Web, and are typically managed by other
organizations with their own processes, versioning systems and collaboration mechanisms. Hosted extensions are managed and published as part
of the schema.org project, with their design often led by one or more dedicated community groups.
</p>
<p>
For general use, publishers and consumers are encouraged to use the latest release and to use simple non-versioned schema.org URLs such as 'http://schema.org/Place'
in structured data applications. However there are settings in which more precise versioning is important. Schema.org also provides dated snapshots of each release, including
both human and machine readable definitions of the schema.org core vocabulary. These are linked from the <a href="releases.html">releases page</a>. In addition,
the <a href="/schemaVersion">schemaVersion</a> property has been defined to provide a way for documents to indicate the specific intended version of schema.org's
definitions. Finally, all changes to the site and its underlying software are now <a href="https://github.com/schemaorg/schemaorg/">published via Github</a>.
</p>
<h2>Schema structure</h2>
<p>The schema.org site contains:</p>
<ul>
<li>A homepage and a few <a href="/docs/documents.html">overview documents</a> such as this.</li>
<li>Term definitions - one page for each term. Every schema.org term is either a type (e.g. <a href="/Event">Event</a>),
a property (e.g. <a href="/workPerformed">workPerformed</a>),
or an enumerated value (e.g. <a href="/ReservationCancelled">ReservationCancelled</a>). Definitions consist of an identifier such as "<code>Event</code>",
a short textual (HTML) definition, including cross-references and links, as well some factual metadata about the terms. The approach we
use is based on <a href="https://www.w3.org/TR/rdf-schema/">W3C RDFS</a> with some <a href="#schemalang">customizations</a> summarized below.
</li>
<li>Machine-readable files (not intended for humans):
<ul id="jsonldcontext">
<li><a href="/docs/schema_org_rdfa.html">schema_org_rdfa.html</a> - the underlying technical definition of the (core) schemas. Hosted extensions are represented in similar files, see data/ext/* in the github repository.</li>
<li>A <a href="/docs/jsonldcontext.json">JSON-LD context file</a> (also available to software <a href="https://en.wikipedia.org/wiki/Content_negotiation">via</a> the homepage, in application/ld+json format).
This is generated by software automatically, and is needed for schema.org's use with the W3C JSON-LD format. The main purpose is to record
for each property in schema.org whether the default interpretation of a string value in JSON-LD should be URL or text. This allows publishers to
use relative links (e.g. "../news/") more reliably. Schema.org properties that expect <a href="/URL">URL</a> amongst their values are listed in this
way in the JSON-LD definitions. Currently the history of the context document is not archived, but <a href="https://github.com/schemaorg/schemaorg/issues/1101">discussion</a> on this point is welcome.
</li>
<li>Other machine-oriented files are available via <a href="https://github.com/schemaorg/schemaorg/tree/sdo-deimos/data">github</a>.</li>
</ul>
</li>
</ul>
<h2 id="schemalang">Schema definitions</h2>
<p>Schema.org essentially defines a dictionary of terms (types, properties and enumerated values). To understand its evolution, a brief summary
of the definition structure is needed (see also <a href="datamodel.html">datamodel overview</a>). In schema.org, each type can have one or more supertypes,
although it is rare to have more than one supertype. This provides the main <a href="/docs/full.html">hierarchical</a> navigational structure of schema.org: a tree of
types with <a href="/Thing">Thing</a> at the root. Each property may have a more general super-property (e.g. <a href="/partOfSeason">partOfSeason</a> is a specialization of
<a href="/isPartOf">isPartOf</a>), but there is no unified hierarchy of properties. Pairs of properties can also be marked as being inverses of each other: i.e. they
say effectively the thing, expressed in opposite direction, e.g. <a href="/alumni">alumni</a>/<a href="/alumniOf">alumniOf</a>, <a href="/isPartOf">isPartOf</a>/<a href="/hasPart">hasPart</a>.
</p>
<p>It is also important to understand what schema.org does <em>not</em> define or dictate. In particular schema.org does not define any notion of 'mandatory' property.
Different sites and pages naturally have different amounts of information available; these details cannot be anticipated by schema designers. Similarly, the information needs of consuming services may also vary. We do not attempt to reach consensus at schema.org on what an ideal description of some type (Person, Place, TVSeries etc.) ought to contain - this makes consensus significantly easier to achieve. The schema.org site does contain many practical markup examples, which give rough hints about common and useful patterns for combining schema.org terms.</p>
Each release can include several kinds of change:
<ul>
<li>Bug fixes and minor improvements (e.g. typos, markup errors in examples).</li>
<li>New examples.</li>
<li>Adjustments to the textual descriptions of terms (i.e. types, properties and
enumerated values).</li>
<li>Adjustments to the examples that accompany each term, and to the indexing of which terms an example should show up against. Although examples are
not formally part of the schema definitions, they play a central role in schema.org's widescale adoption and are versioned as part of the release.</li>
<li>Adjustments to the machine-readable claims we make about each term: supertype(s), superproperties, inverses, and the associations that link types and properties together.
For each property we maintain a list of one or more types that it is expected to be applied to (technically, "<a href="/domainIncludes">domainIncludes</a>"), alongside one or more types that are expected as its values (expressed using "<a href="/rangeIncludes">rangeIncludes</a>"). We may also mark some properties as "<a href="/supersededBy">supersededBy</a>" others. It is exceptionally rare for a property, type or enumerated value to be deleted/removed without leaving it in the system as "supersededBy" another. Additional machine-readable metadata in RDFS/OWL is also used to express mappings internally and to external vocabularies. These mappings also evolve.
</li>
<li>Term descriptions and definitions can be moved between schema.org's core and its hosted extensions. Each schema.org term is marked as being "<a href="/isPartOf">partOf</a>" either the core
or exactly one extension, and terms can move in either direction. Terms can be generalized for wider use and moved into the core, or migrated from the core into a hosted extension. In both cases, textual definitions and machine-readable definitions may be adjusted.
</li>
</ul>
<p>
Schema.org property names are considered "global" across the entire project (including the core and all hosted vocabularies such as "<a href="http://auto.schema.org/">auto</a>", "<a href="http://bib.schema.org/">bib</a>" etc.).
For example, there is only one property such as "<a href="/startDate">startDate</a>", and both its human-readable and machine-readable definitions need to be appropriate to all the
situations in which it might be used. In the case of "startDate" (defined currently as "The start date and time of the item"), the text has to be appropriate to
all of the different combinations of types it can be used with. </p>
<p>This situation drives many of the evolutionary changes to schema.org. Often properties are added for some specific use case, and their potential relationship to other areas of schema.org only becomes clear later. This gives rise to changes in textual definition
and property-to-type associations that gradually make schema.org more coherent, without introducing radical changes in meaning. Consumers of schema.org data can generally rely on schema.org term meanings not changing dramatically; however term definitions often evolve gradually over time, to accomodate new usage scenarios or to
improve usability. </p>
<p>
A common change is for a property to be marked as applicable to some previously unrelated type, or to expect to take values of a new type. When this happens the textual definitions are often adjusted slightly too. This is either by listing the new types explicitly, or through the use of a more general term like "item", "entity" or "thing". The issue summaries in the project <a href="releases.html">releases</a> page are a good guide to the kind of changes to expect in future.
</p>
<h2 id="extensibility">Extensibility Mechanisms</h2>
<p>
In addition to the two dedicated <a href="extension.html">extension</a> mechanisms (hosted and external) there are several other ways in which schema.org structured
data can be extended with complete independence from the evolving definitions and discussions at schema.org.</p>
<ul>
<li>Schema.org data can be published within the same page or document as other kinds of structured data e.g. microformats, RDFa, JSON-LD and Microdata that
use independent vocabularies.</li>
<li>Schema.org provides the <a href="http://schema.org/PropertyValue">PropertyValue</a> which can be used to expose arbitrary property/value data pairs
within a larger schema.org description. This is used e.g. on e-commerce sites to expose key/value information that does not map easily into schema.org terminology.</li>
<li>Schema.org provides the <a href="/Role">Role</a> mechanism which allows any piece of schema.org to be arbitrarily annotated with extra information.</li>
<li>Schema.org's supported syntaxes (in particular JSON-LD and RDFa but to some extent Microdata) support the mixing of other independent schemas into a schema.org-based
description. Schema.org in JSON-LD (via our <a href="/docs/jsonldcontext.json">context definition</a>) and in RDFa 1.1 (via W3C's <a href="https://www.w3.org/2011/rdfa-context/rdfa-1.1">initial context</a> definition) has pre-supported declarations for many additional schemas identified by short prefix, e.g. 'dc' for Dublin Core.</li>
</ul>
<p>These mechanisms provide for greater expressivity within schema.org-based structured data. They are independent of schema.org vocabulary definitions and
release planning, versioning etc. and no community approval, agreement or steering group consensus is needed to make use of these mechanisms.
</p>
<h2 id="pending">Early Access Fixes and Pending Releases</h2>
<p><b>Early Access Fixes</b>: We have recently introduced mechanisms for more rapid updates to the schema.org site, in between official named releases. Prior to 2015, the schema.org site was only ever updated during official releases (or for occasional emergency repairs such as software bug fixes). In 2015 we introduced
both the hosted <a href="extension.html">extensions</a> mechanism and the notion of "Early Access Fixes" which could be published to schema.org immediately with the agreement of the steering committee. An "Early Access Fixes" section at the top of the <a href="/docs/releases.html">releases</a> page lists any recently implemented fixes that have occurred
since the most recent release.
</p>
<p>
For versioning purposes the changes are considered part of the subsequent full release.
</p>
<p>
Version 3.0 of schema.org introduces the "pending schemas" extension. The pending extension is a staging area for work-in-progress terms which have yet to be accepted into the core vocabulary. Pending terms are subject to change and should be used with caution. Implementors and publishers are cautioned that terms in the pending extension may lack consensus and that terminology and definitions could still change significantly after community and steering group review. Consumers of schema.org data who encourage use of such terms are strongly encouraged to update implementations and documentation to track any evolving changes, and to share early implementation feedback with the wider community. See also <a href="#devpending">FAQ entry below</a>.
</p>
<h2>Workflow FAQ</h2>
<p>
This page has a relatively limited audience. Here are some questions and answers that go into greater depth than the more mainstream,
webmaster-focussed <a href="faq.html">schema.org FAQ</a>.
</p>
<dl>
<dt id="publicvocabs">What are <a href="http://lists.w3.org/Archives/Public/public-vocabs/">public-vocabs</a> and the <a href="https://www.w3.org/wiki/WebSchemas">W3C WebSchemas</a> group?</dt>
<dd>When the project launched in 2011 we created a temporary collaborative home for discussions about the project at W3C. This was the
"<a href="https://www.w3.org/wiki/WebSchemas">Web Schemas</a>" taskforce (see <a href="https://www.w3.org/2001/sw/interest/webschema.html">charter</a>) of the W3C Semantic Web Interest Group. The general names were chosen to reflect the importance of a wide-ranging discussion
group that looked into how schema.org related to other structured data vocabularies. As W3C's Community Group platform matured and we found
schema.org discussions had become the primary focus of the public-vocabs list, schema.org moved to use instead a dedicated Community Group at W3C. Several
other groups working on schema.org extensions have subsequently set up their own Community Groups. The public-vocabs mailing list and
Web Schemas Wiki remain available, but active collaboration on schema.org now uses the
<a href="http://lists.w3.org/Archives/Public/public-schemaorg">new Community Group mailing list</a> alongside <a href="http://github.com/schemaorg/schemaorg/">Github</a>.
</dd>
<dt id="plans">Where's the plan?</dt>
<dd>The day-to-day running of the project is driven by the <a href="http://github.com/schemaorg/schemaorg/issues">github issue list</a>. This covers new
vocabulary proposals, modest improvements and fixes for integration, as well as internal software tooling issues. As there are many open issues, some high
level entry points are available: issues <a href="https://github.com/schemaorg/schemaorg/issues/1" class="issue-link" title="Meta: schema.org planning">#1</a> (planning), <a href="https://github.com/schemaorg/schemaorg/issues/2" class="issue-link" title="Proposed vocabulary additions/changes - general rolling overview">#2</a> (vocab changes) and <a href="https://github.com/schemaorg/schemaorg/issues/3" class="issue-link" title="Meta bug to provide overview of all python/site tool issues">#3</a> (tooling/infrastructure) provide some views into to the various fine-grained issues, as do the labels we attach e.g. <a href="https://github.com/schemaorg/schemaorg/issues?q=is%3Aopen+is%3Aissue+label%3A%22type%3Acleanup+%2B+clarity%22">cleanup</a>.
Generally the project steering group and community prioritize modest (small sized) proposals that maps easily onto structured content that is already widely
published in the Web, and vocabulary that is likely to be used in large scale projects of all kinds. The project's core emphasis remains public Web
content but schema.org vocabulary has been used in other settings e.g. structured data in email, and discussions are welcome on new areas where it may prove useful.
</dd>
<dt id="opinfo">Where are operational details (e.g. github issue tagging policies, related community groups, events etc.) described?</dt>
<dd>
<p>Accompanying this document, we also have a <a href="https://www.w3.org/community/schemaorg/how-we-work/">"how we work" section</a> of the Schema.org <a href="https://www.w3.org/community/schemaorg/">community group</a>. Practical day-to-day details are organized around those pages.
</p>
<dt id="devpending">What is the difference between the "pending" schemas mechanism and the development version of the site?</dt>
<dd>
<p> The "<a href="#pending">pending schemas extension</a>" and the development version of the site are two mechanisms we use for making works-in-progress available. </p>
<ul>
<li>The "pending" extension contains one or more self-contained proposals that add new terms (types, properties and enumerated values) to schema.org.</li>
<li>The development version of schema.org is <a href="http://webschemas.org/">webschemas.org</a>. It is a 1:1 representation of the current contents of the
main development branch of the project's <a href="https://github.com/schemaorg/schemaorg">Github</a> repository.</li>
</ul>
<p>All hosted extensions, i.e. "bib", "auto", "meta" etc., including the "pending" extension and the schema.org "core" itself, are developed within the main project file repository, and consequently have "work in progress" development representations on webschemas.org as well as official named releases.</p>
<h3>Background</h3>
<p>
For several years we have used "testing" versions of the site to publish proposed designs. These were sometimes named after particular schemas (e.g. sdo-actions) or after upcoming releases (e.g. sdo-phobos). To simplify this process and to emphasise integration of changes, we began also posting a unified "next version of the site"
draft. This is now available consistently at <a href="http://webschemas.org">webschemas.org</a>. Other more exploratory test sites illustrating potential major changes can also still be used. The "in development" webschemas.org site may also contain software bugs, be occasionally offline, or be in an inconsistent state due to ongoing editorial work.</p>
<p> The "pending" extension is a related idea. Effectively it exploits our relatively new "hosted extensions" machinery to address a workflow problem
that has affected the project from the beginning. Many interesting and sensible schema.org vocabulary ideas have been proposed which, while self-consistent and
useful, have not received focussed attention from the community, or been approved for inclusion into the schema.org core by the project steering group.
By publishing these proposals directly through a "pending" extension, we encourage more detailed implementation proposals and make wider review much easier.
</p>
<p>This means that there is a "live, development version" set of pending schemas at pending.webschemas.org, as well as a released version
at pending.schema.org. The <a href="#webmaster">project webmaster</a> can update pending.schema.org with new proposals drafted at pending.webschemas.org in order to
share a complete design more widely.
</p>
</dd>
<dt id="whenpending">When should a change proposal go into pending, rather than be drafted as a direct edit to the schema.org core?</dt>
<dd>
<p>
The "pending" area of the site is an optional collaborative mechanism, best suited to relatively self-contained changes that <em>add</em> new vocabulary. It remains
perfectly reasonable to propose core changes directly (via Github issues and pull requests, and <a href="http://www.w3.org/community/schemaorg">commmunity discussion</a>). The pending mechanism can only handle changes to the core that are <em>additive</em>. For example, if you want to propose a new type, and also
amend the definition of an existing property to reference it (without changing its existing relationship to existing types), this is possible to do as a pending proposal. If instead you want to change the textual definition of
an existing type, or alter its supertype, then the pending extension mechanism is not appropriate.
</p>
<p>
The pending extension can be considered an integration-oriented "melting pot" where proposed additions can be seen alongside each other. While these proposals
generally originate in community discussions, the project webmaster is responsible for coordinating and synthesising related proposals, as well as
encouraging discussion amongst their contributors.
</p>
</dd>
<dt id="extfreq">Hosted Extensions: how are they versioned, published etc.?</dt>
<dd>
<p>
Since the initial implementation of hosted extensions (i.e. bib.schema.org, auto.schema.org), they have effectively been managed as an extended
part of schema.org's core: updated on the same release cycle, and reviewed in the same steering and community group discussions.
As more communities begin contributing via hosted extensions we expect to revise this document to provide more details on publication and versioning workflow for these extensions. At the current time
hosted extensions are updated in the same release schedule as the schema.org core vocabulary.
However we expect this process to remain relatively centralized due to the many ways in which schemas can overlap in topical scope, as well as the need for careful assignment of term names to avoid clashes or overly domain-specific definitions.
</p>
<p>
In addition, each hosted extension has a customizable homepage, which can also provide a natural language explanation of the status of that work, including links to
supporting information and related community groups.
</p>
</dd>
<dt id="webmaster">What is the role of the Schema.org webmaster?</dt>
<dd>The Schema.org webmaster's role, assisting the <a href="about.html#cgsg">steering group</a>, is to:
<ul>
<li>Take operational responsibility for the day-to-day running of the schema.org site and other online presence such as W3C community groups, Github, development sites.</li>
<li>Prepare and implement release candidates and site updates as described in <a href="howwework.html">this document</a>, drawing upon the rough consensus of
the wider community, and implemented with the approval of the steering committee.</li>
<li>Faciliate wide-ranging community and industry involvement during schema design discussions, e.g. via W3C, Github.</li>
</ul>
The current schema.org webmaster is Dan Brickley, who serves in this capacity on behalf of the schema.org project rather than on behalf of his employer, Google.
</dd>
<dt id="w3rel">How is this work related to W3C? How does the steering group mechanism work in practice?</dt>
<dd>
<p>
Schema.org is an independent project whose discussions occur within W3C Community Groups. Schema.org data is expressed within underlying infrastructural
standards produced by W3C (JSON-LD, RDFa, CSVW) as well as by WHATWG (Microdata). Schema.org is focussed on using these aspects of the Web platform
for descriptive purposes within structured data, rather than on developing the underlying infrastructure, protocols and technical formats of the Web itself.
The project is not governed by W3C, the W3C advisory group or the <a href="http://www.w3.org/Consortium/Process/">W3C Process</a>; rather, it is part of a wider network of informal collaboration in the Web standards community. Participants in community group and Github discussions are expected to respect the <a href="https://www.w3.org/Consortium/cepc/">W3C code of
ethics and professional conduct</a>, as well as each other. Attention is also drawn to the <a href="http://schema.org/docs/terms.html">terms of service</a> document which includes copyright (CC BY-SA 3.0) and W3C RF commitments from schema.org's founders (i.e. the founding search engines).
</p>
<p>In terms of workflow, the primary difference between schema.org and W3C's recommendation track process is an emphasis on incremental publication of releases (several
releases per year) approved by a small <a href="about.html#cgsg">steering group</a> whose role is to evaluate and approve release candidates prepared by the project <a href="#webmaster">webmaster</a> on the basis of wider discussion. Releases are <a href="/docs/releases.html">published</a> to the official site by the <a href="#webmaster">project webmaster</a> following the review and approval of the <a href="about.html#cgsg">steering group</a>.
Steering Group review occurs in public email threads (e.g. <a href="https://lists.w3.org/Archives/Public/public-schemaorg/2015May/0000.html">v2.0</a>,
<a href="https://lists.w3.org/Archives/Public/public-schemaorg/2015Jul/0003.html">v2.1</a>,
<a href="https://lists.w3.org/Archives/Public/public-schemaorg/2015Sep/0007.html">v2.2</a>,
<a href="https://lists.w3.org/Archives/Public/public-schemaorg/2016Apr/0053.html">v3.0</a>) and the conversation is open to all schema.org project contributors
via the W3C Schema.org Community Group. These public email discussions of the steering group are effectively the publication of steering group minutes.
Release review discussions are on the main <a href="https://lists.w3.org/Archives/Public/public-schemaorg/">[email protected]</a> Community Group list.
There is also a <a href="https://groups.google.com/forum/#!forum/schema-org-sg">rarely used</a> email list for the steering group (also public), but the
Community Group and Github are the main hub for all project activities and internal communication. The project has never published a release without the
unanimous agreement of the steering group. Steering group members who share an employer have adopted the convention that one "agree to publish this release" message serves for their colleagues also.
</p>
<p>
Schema.org's various <a href="#extensibility">extensibility mechanisms</a> serve to ease the reliance on steering group and wider community consensus. For example, <a href="http://gs1.org/">GS1</a> have published their own schema.org-oriented <a href="http://gs1.org/voc/">Web Vocabulary</a> as an <a href="http://blog.schema.org/2016/02/gs1-milestone-first-schemaorg-external.html">external extension</a> to schema.org. No permission or consensus was required for this, and liaison was conducted through community group mechanisms rather than the steering group.
</p>
</dd>
<dt id="metaext">What is the 'meta' extension?</dt>
<dd>Schema.org contains a small number of terms that are used by schema.org itself for <a href="#schemalang">defining schemas</a>. Unlike the schema.org core vocabulary, they are not designed or intended for general use in the Web. These terms are now defined as a 'meta' extension.
</dd>
<dt id="getinvolved">How can I get involved? How can I propose new schemas or other improvements?</dt>
<dd>
<p>
The main forum for schema.org discussions is the <a href="http://www.w3.org/community/schemaorg/">W3C Schema.org Community Group</a>. There are also a number of more topical <a href="#grouplist">related community groups</a>, as mentioned below.
Anyone can participate in these or <a href="http://www.w3.org/community/">other</a> W3C community groups, regardless of whether their employer has
<a href="https://www.w3.org/Consortium/join">joined W3C</a>. These groups each host public email-based discussions. For schema.org, due to the broad scope of the project, the majority of our detailed discussions tend to occur in Github, organized as "<a href="https://github.com/schemaorg/schemaorg/issues">issues</a>". Substantial textual contributors (of schemas and examples) are expected to join the community group and review the project <a href="terms.html">terms of service</a>, but everyone is welcome to discuss issues (in Github or elsewhere), suggest small changes or otherwise collaborate.
</p>
<p>
The best way to propose changes to schema.org is to raise an <a href="https://github.com/schemaorg/schemaorg/issues">issue</a> at Github, perhaps accompanied
by a thread on the <a href="https://lists.w3.org/Archives/Public/public-schemaorg/">[email protected] mailing list</a>. Simple and modestly sized change proposals, and changes that are likely to be used tend to reach a rough consensus most easily. More complex topics (e.g. our designs around <a href="/Action">Action</a> and <a href="/Role">Role</a>) can take substantively longer.
</p>
</dd>
<dt id="sponsorgetinvolved">I work for one of the Schema.org-founding search engines (originally known as "sponsors"). How can I get involved? How can I propose new schemas or other improvements?</dt>
<dd>See <a href="#getinvolved">previous question</a>.</dd>
<dt id="grouplist">Where are all the schema.org-related W3C community groups listed?</dt>
<dd>See the <a href="https://www.w3.org/community/schemaorg/how-we-work/">how we work</a> materials over in our W3C group for a list.</dd>
<dt>Further reading...?</dt>
<dd>
<p>For more background on the project, the following may be of interest:</p>
<ul>
<li><a href="http://queue.acm.org/detail.cfm?id=2857276">ACM Queue article</a></li>
<li>Richard Wallis's "schema.org in practice" articles:
<a href="http://dataliberate.com/2016/02/10/evolving-schema-org-in-practice-pt1-the-bits-and-pieces/">part 1</a>,
<a href="http://dataliberate.com/2016/02/25/evolving-schema-org-in-practice-pt2-working-within-the-vocabulary/">2</a>, and
<a href="http://dataliberate.com/2016/03/01/evolving-schema-org-in-practice-pt3-choosing-where-to-extend/">3</a>.
</li>
<li>R.V.Guha <a href="http://videolectures.net/iswc2013_guha_tunnel/">Light at the end of the Tunnel</a> talk (video + <a href="http://videolectures.net/site/normal_dl/tag=817824/iswc2013_guha_tunnel_01.pdf">pdf slides</a>), ISWC 2013.</li>
<li>Charles Nevile <a href="http://tlks.io/talk/schemaorg-what-how-why">Schema.org - What, How, Why?</a> talk (video).</li>
<li>Peter Mika <a href="https://www.youtube.com/watch?v=Dw2OhqvB0cE">Making the Web searchable</a> talk (video).</li>
<li><a href="http://www.dataversity.net/semtechs-schema-org-panelists-talk-openness-adoption-interoperability/">SemTech's Schema.org Panelists Talk Openness, Adoption, Interoperability</a>, 2012 article.</li>
<li><a href="https://docs.google.com/presentation/d/1f-2asymXOCCYHa75OkOnlqc0SExvD44V5D6buyKHfII/edit">Schema.org Update 2014</a>, Dan Brickley. SemTech Biz presentation.</li>
</ul>
</dd>
</dl>
</div>
<div id="footer"><p>
<a href="../docs/terms.html">Terms and conditions</a></p>
</div>
</body>
</html>