-
Notifications
You must be signed in to change notification settings - Fork 6
/
Copy pathedit.html
executable file
·3082 lines (2511 loc) · 174 KB
/
edit.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
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html xmlns='http://www.w3.org/1999/xhtml' lang='en'>
<head>
<meta charset='utf-8'/>
<title>Modelling Opportunity Data 2.1</title>
<script type="text/javascript" class='remove'>
var respecConfig = {
// specification status (e.g. WD, LCWD, NOTE, etc.). If in doubt use ED.
specStatus: "CG-DRAFT",
// the specification's short name, as in http://www.w3.org/TR/short-name/
shortName:"modelling-opportunity-data",
// if you wish the publication date to be other than today, set this
// publishDate: "2009-08-06",
// if there is a previously published draft, uncomment this and set its YYYY-MM-DD date
// and its maturity status
// previousPublishDate: "1977-03-15",
previousMaturity: "ED",
previousPublishDate: "2018-07-29",
// if there a publicly available Editor's Draft, this is the link
edDraftURI: "https://www.openactive.io/modelling-opportunity-data/EditorsDraft/",
previousURI: "https://www.openactive.io/modelling-opportunity-data",
//prevED: "https://www.openactive.io/spec-template/",
//previousURI: "https://www.openactive.io/realtime-paged-data-exchange/0.2.3/",
//testSuiteURI: "https://www.openactive.io/endpoint-validator/",
copyrightStart: 2018,
// if this is a LCWD, uncomment and set the end of its review period
// lcEnd: "2009-08-05",
// editors, add as many as you like
// only "name" is required
editors: [
{ name: "Timothy Hill", url: "https://theodi.org/person/timothy-hill/",
company: "Open Data Institute", companyURL: "http://opendata.institute/",
w3cid: 114402 },
{ name: "Leigh Dodds", url: "http://ldodds.com",
company: "Open Data Institute", companyURL: "http://opendata.institute/",
w3cid: 55359 }
],
// authors, add as many as you like.
// This is optional, uncomment if you have authors as well as editors.
// only "name" is required. Same format as editors.
//authors: [
//],
otherLinks: [
{
key: "Version",
value: "2.1 Candidate Specification",
href: "https://www.openactive.io/modelling-opportunity-data/EditorsDraft/"
}
],
logos: [
{
src: 'https://www.openactive.io/assets/openactive-logo-large.png',
href: "https://www.openactive.io",
alt: "openactive.io",
width: 255, //170
height: 43, //22
id: 'logo'
}
],
// extend the bibliography entries
//localBiblio: {},
// name of the WG
wg: "OpenActive Community Group",
// URI of the public WG page
wgURI: "https://www.w3.org/community/openactive/",
// name (with the @w3c.org) of the public mailing to which comments are due
wgPublicList: "public-openactive",
// URI of the patent status for this WG, for Rec-track documents
// !!!! IMPORTANT !!!!
// This is important for Rec-track documents, do not copy a patent URI from a random
// document unless you know what you're doing. If in doubt ask your friendly neighbourhood
// Team Contact.
maxTocLevel: 4,
preProcess: [ ],
isRecTrack: true,
isNoTrack: true,
github: "https://github.com/openactive/modelling-opportunity-data/",
format: "markdown",
localBiblio: {
"JSON-LD": {
"href": "https://www.w3.org/TR/json-ld/",
"title": "JSON-LD 1.0",
"status": "REC",
"publisher": "W3C",
},
"SCHEMA-ORG": {
"href": "https://schema.org/",
"title": "Schema.org"
},
"SKOS": {
"href": "https://www.w3.org/TR/skos-primer",
"title": "SKOS Simple Knowledge Organization System Primer",
"status": "NOTE",
"publisher": "W3C",
},
"BasicGeo":{
"href": "https://www.w3.org/2003/01/geo/",
"title": "W3C Semantic Web Interest Group: Basic Geo",
"publisher": "SWIG"
},
"Publishing-Opportunity-Data": {
"href": "https://www.openactive.io/opportunity-data-primer/",
"title": "Publishing Opportunity Data: A Primer",
"publisher": "OpenActive Community Group",
},
"OpenActive-Beta-Namespace": {
"href": "https://www.openactive.io/ns-beta/",
"title": "OpenActive Beta Namespace",
"publisher": "OpenActive Community Group",
},
"OpenActive-Vocabulary": {
"href": "https://www.openactive.io/ns/",
"title": "OpenActive Vocabulary",
"publisher": "OpenActive Community Group",
},
"Open-Booking-API": {
"href": "https://www.openactive.io/open-booking-api/EditorsDraft/index.html",
"title": "OpenActive Open Booking API",
"publisher": "OpenActive Community Group",
},
"OpenActive-Activity-List": {
"href": "https://openactive.io/activity-list",
"title": "OpenActive Activity List",
"publisher": "OpenActive Community Group",
}
}
};
</script>
<script src='https://www.w3.org/Tools/respec/respec-w3c-common' class='remove'></script>
<style>
table {border-collapse: collapse; border: 1px solid #bec9d9}
td, th {padding: 3px 0.5em; border-left:1px solid black; border-right: 1px solid black; border-bottom:1px solid #E2EDFE;}
tr th[colspan] {color: #005A9C; background-color: #FEEDE2; text-align: center}
th {color: #005A9C; background-color: #E2EDFE; font-weight: normal;border-bottom:1px solid #BEC9D9;}
tbody tr th {text-align: left;}
td.nb { font-size: smaller;}
.rec, .pr {color: #005A9C; background-color: #99EE99}
.ext {background-color: #FFFFFF}
.cr, .lcwd {color: #005A9C; background-color: #EEEE99}
.wd {color: #005A9C; background-color: #EE9999}
.ed, .fpwd {color: #005A9C; background-color: #FF7777}
code {white-space: pre;}
html {
background-image: none !important;
}
body {
background: white top left fixed no-repeat !important;
background-size: 25px auto !important;
background-image: url('https://www.openactive.io/assets/openactive-label-specification.png') !important;
}
h1 {
font-family: 'Open Sans',sans-serif !important;
font-weight: 300 !important;
color: #3B3089 !important;
font-size: 220%;
}
#toc {
padding-top: 0px !important;
}
.remove {
background-colour: yellow;
}
code {
color: #C83500;
}
em.rfc2119 {
font-variant: small-caps;
}
</style>
</head>
<body>
<style>
body {
background-size: 25px auto !important;
}
body.toc-sidebar #toc {
background-size: 25px auto !important;
background-attachment: fixed !important;
}
em.rfc2119 {
text-transform: lowercase;
font-variant: small-caps;
font-style: normal;
color: #900;
}
</style>
<section id='abstract'>
This specification introduces a data model to support the publication of data describing
opportunities for people to engage in physical activities ("opportunity data"). This model
covers description of activities, as well as the events and locations in which they take place.
The specification is intended to support the publication of opportunity data as open data
for anyone to access, use and share. It will also guide reusers of opportunity data,
introducing them to the key concepts relevant to that sector.
The model may also be useful in guiding the development of both new and existing booking
systems and applications that consume opportunity data.
The specification is an output of the [OpenActive Community Group](http://www.w3.org/community/openactive/)
and serves as a common reference point for other specifications and outputs of that activity.
Developers looking for a quick primer on the model and how to use it to structure opportunity data may want to refer to the
[[Publishing-Opportunity-Data]] primer which provides a number of additional examples.
The data model introduced in this document has been mapped to existing standards and vocabularies, including
SKOS ([[SKOS]]) and the Schema.org ([[SCHEMA-ORG]]) types and properties. This existing work provides a
useful existing framework around which the
[OpenActive Community Group](http://www.w3.org/community/openactive/) can build additional data standards.
</section>
<section id="sotd" class="introductory">
<h2>Status of This Document</h2>
Contributions to this document are not only welcomed but are actively solicited. Please add any solutions, comments, or improvements you might have via [GitHub Issues](https://github.com/openactive/modelling-opportunity-data/issues)
and pull requests. The source code is available on [GitHub](https://github.com/openactive/modelling-opportunity-data).
<div class="note">
This document represents a published Candidate Release, including minor non-breaking clarifications that build on the version released at [https://www.openactive.io/open-booking-api](https://www.openactive.io/open-booking-api). This Candidate Release is published for the purposes of creating accompanying tooling and gathering implementation experience, and will be updated with further clarifications and minor technical improvements based on implementation feedback. We encourage developers to implement this API and share their experience.
</div>
</section>
<section class="informative">
# Introduction
The [W3C OpenActive Community Group](http://www.w3.org/community/openactive/) was
established with the objective of facilitating the sharing and use of
physical activity data. Open publishing of this data has enormous potential to increase
participation in physical activities.
## Categories of Physical Activity Data
There are several different categories of data that are relevant to physical activities.
This data covers different parts of [the data spectrum](http://theodi.org/data-spectrum)
and is represented in the following diagram.
<figure>
<figcaption>Types of physical activity data</figcaption>
</figure>
Some of this data is shared data. It can only be accessed by
specific people or groups, under terms and conditions that define how and when
it can be accessed and used. This shared data includes personal data about
people taking part in activities and participation data that describes how people have
been involved in previous events.
Some of this data can be open data. Open data is data that anyone can access, use and share.
All of the following types of data can be published as open data:
* descriptions and lists of physical activities
* details of the locations and venues at which activities or events takes place
* the facilities available at those locations
* the details of event involving physical activities e.g. when and where they will take place, restrictions
on attendance, costs, etc
* any related information, e.g. about the format of the event, its organisers, etc
Collectively this is known as __*opportunity data*__.
## Requirements
This specification has been developed to meet a broad set of requirements.
### Support all types of opportunity data
As described in the previous section, opportunity data covers a variety of different types of
information including data on venues, activities and events. The specification should support
publication of all of these different types of data
### Support discovery of opportunities
The aim of the OpenActive initiative is to encourage people to be more physically active. This means
that this specification should focus on the data that will help people discover these
opportunities.
### Support all physical activities
The specification should be inclusive and support sharing of opportunity data about
all types of physical activities, not just sports.
### Allow sharing of activity lists
At present the physical activity sector does not have a standard list of physical activities.
The specification should allow data providers to share the lists they have and support the
sector in moving towards a standardised list of physical activities
### Support a variety of sources
Opportunity data is collected and held in a variety of different tools, platforms and websites.
There is variation in the amount of detail held about individual events so the specification must
provide flexibility to share what data is currently available, whilst guiding activity providers
towards additional useful data to collect about events.
### Be agnostic to formats and APIs
Reflecting the wide variety of tools and platforms in use, and also that the sector is at an
early stage in sharing its data more widely, this specification should not prescribe specific
data formats or APIs. Ideally opportunity data could be published as JSON, XML, CSV or other formats.
### Create an extensible framework
This specification should support extensions to allow it to be customised and revised to meet future
requirements, as well as the needs of specific communities of data publishers and consumers.
## Scope
This specification defines a data model for opportunity data. This reflects the goal of
[the OpenActive initiative](https://www.openactive.io/) whose aim is to
encourage the publishing and reuse of open data that might help people to become
more active.
The following items are therefore out of scope for this specification:
* booking and related activities, e.g. availability, booking process and membership packages
* participation data, e.g. statistics on attendance
* personal information, demographics and other information about event participants
* APIs for publishing and discovering opportunity data
Support for third-party bookings is covered in the draft [[Open-Booking-API]]
specification.
The [OpenActive Community Group](http://www.w3.org/community/openactive/) may
produce additional specifications that address the other areas.
## Structure of this document
This specification is divided into two main sections:
1. **Introduction** - provides a broad definition of opportunity data and goals for this specification
2. **Key Concepts** - describes the key types of resources relevant to opportunity data, along with their relationships and common attributes
3. **Data Model** - a data model that maps the key concepts to some standard vocabularies
</section>
<section id="conformance">
This specification makes use of the compact IRI Syntax; please refer to the [Compact IRIs](http://www.w3.org/TR/json-ld/#compact-iris) from [[JSON-LD]].
</section>
<section>
# Typographical Conventions
The following typographic conventions are used in this specification:
<dl class="typography">
<dt><code>markup</code></dt>
<dd>Markup (elements, attributes, properties), machine processable
values (string, characters, media types), property name, or a
file name is in a monospace font.</dd>
<dt><a href="#" class="internalDFN">Definition</a></strong></dt>
<dd>A definition of a term, to be used elsewhere in this or other
specifications, is underlined and in black.</dd>
<dt><a href="">hyperlink</a></dt>
<dd>A hyperlink is underlined and in blue.</dd>
<dt>[<a href="">reference</a>]</dt>
<dd>A document reference (normative or informative) is enclosed in
square brackets and links to the references section.</dd>
</dl>
<div class="note">
Notes are in light green boxes with a green left border and with a "Note" header in green. Notes are normative or informative depending on the whether they are in a normative or informative section, respectively.
</div>
<pre class="example">
Examples are in light khaki boxes, with khaki left border, and with a
numbered "Example" header in khaki. Examples are always informative.
The content of the example is in monospace font and may be syntax colored.
</pre>
</section>
<section>
# Key Concepts
This section introduces the high-level data model for opportunity data. This includes a
description of the:
* the resources that are relevant to opportunity data, e.g. places, events, activities, etc
* the relationships between those resources
* the main attributes that help to describe those resources, e.g. names, dates, etc
The model also helps to provide definitions of key terms that are used throughout this
specification.
## Data Model Diagram
This diagram illustrates the resources and relationships that are introduced in the following sections.
<figure>
<figcaption>Opportunity data schema diagram</figcaption>
</figure>
## Physical Activities
A __*Physical Activity*__ is an exercise, sport or other form of bodily movement
that involves physical effort. Physical activities will usually have a well-understood,
dictionary definition.
Examples of Physical Activities include walking, running, cycling, rugby, football and tennis
Activities should have a name. They might also be associated with one of more synonyms
that provide alternative names for that activity. E.g. "Soccer" is a synonym
for "Football". This additional information may be useful to help improve search engines and
improve data collection.
Physical Activities may also have additional information associated with them.
For example a sporting activity might be overseen by a governing body or federation.
Physical Activities might also be recognised by different bodies. In the UK certain
activities are recognised as suitable for educational assessments, while others
may be recognised by funding bodies like Sport England.
An __*Activity List*__ describes a set of Physical Activities. An Activity List may be a
simple list of activity names. But an Activity List might also capture additional information.
A common requirement is to describe relationships between Physical Activities.
One method of grouping activities is to define "broader" and "narrower" relationships.
For example Judo, Karate and Kendo are all more specific examples of the broader activity of
"Martial Arts".
<ul>
<li>Martial Arts
<ul><li>Karate</li>
<li>Kendo</li>
<li>Judo</li>
</ul>
</li>
</ul>
This type of grouping could also be used to describe the disciplines associated with
Physical Activities. For example olympic and open water swimming.
An Activity List might also group Physical Activities into collections. For example
swimming, water aerobics, and water polo might all be classified as "Water Sports".
Water polo and football might also be grouped into a collection of "Team Sports".
<ul>
<li>Team Sports
<ul><li>Football</li>
<li>Water Polo</li>
</ul>
</li>
<li>Water Sports
<ul><li>Swimming</li>
<li>Water Aerobics</li>
<li>Water Polo</li>
</ul>
</li>
</ul>
An Activity List may include any number of collections of Physical Activities. As shown in the
example above, an individual Physical Activity might be present in more than one grouping.
Some systems may choose to use grouping and hierarchical relationships between
Physical Activities to help people find opportunities to be active. For example
a search engine might offer users results for all types of Martial Art, or for Karate specifically.
<div class="note">
The proposed model for Activity Lists is based on the [[SKOS]] standard for publishing controlled
vocabularies.
</div>
<div class="note">
It is not a requirement that systems store, publish or use relationships between
Physical Activities. A system may choose to treat Physical Activities as simple tags
or categories associated with Events. Other systems may define a fixed list of
Physical Activities that are used as a controlled vocabulary to guides user input
and data collection. Others may adopt a more complex hierarchical approach.
</div>
<div class="note">
<p>__Developing a standard activity list__</p>
<p>This specification doesn't place any requirements on how applications manage
or use Physical Activities or Activity Lists. There is no requirement that applications that
implement this specification must adopt a single standardised list, or agree on standard groupings. The intention
here is to just capture a useful model that can represent the variety of data currently in use.
</p>
<p>However there are benefits to the physical activity sector in convergence on a standard list of
activities in order to improve discovery, reporting, etc. The OpenActive Community Group are developing
a standard list as a separate activity. For more information see [[OpenActive-Activity-List]].
</div>
## Events
An __*Event*__ is an opportunity to take part in a Physical Activity. Events take place at a
specific location (see below) at an agreed date and time.
Some Events are one-off occurrences. For example a fun run organised by a local group
may run as a standalone event on a particular date.
Other events take place on a regular __schedule__. For example a weekly gym class may
run every Wednesday evening at 7pm. While a local walking club might meet on a Saturday
morning once a month.
It is useful to publish data about both individual Events and those with recurring schedules.
People looking for opportunities to be active will be interested in both specific questions
("what can I do tomorrow") and more general information about scheduled activities.
For some scheduled events, participants may not have to commit to attending every
session. They can drop-in for individual classes, or build up a regular habit to
improve their fitness. For other events, like a course, there is might be an
expectation that a participant will attend every class.
Some large scale events, such as a family fun day, might consist of a programme
of smaller scheduled events that take place over the course of a single or multiple
days.
In order to simplify terminology in this specification we use the term "Event"
to refer to all types of opportunities, including one-off and
regularly occurring events. However in the detailed data model we distinguish
between some types of events to allow data users to better present opportunities
to potential participants.
Regardless of what type of an event is being described, there
is a range of additional information that may help describe the event to potential participants.
This includes:
* the Physical Activity or Activities that will take place at the event
* the location (Place or Venue) in which it is taking place
* the Organiser of the event, which might be a person or an organisation
* the Programme used to structure the event
* descriptive attributes, such as its suitability for specific age or weight ranges
* general category information to tag the event as suitable for certain fitness levels, intensity, etc
* booking information, including price, attendance numbers and method of booking
<div class="note">
<p>There are a variety of ways to categorise and describe events. This includes restrictions on attendance,
aspect of suitability for different audiences and fitness levels, and a mixture of pre-requisites such as the
need for certain qualifications, membership or equipment.
</p>
<p>
The initial version of this specification prioritises capturing the essential elements of describing an event. The
structured information about time, place and activity is supplemented with some basic descriptive properties.
This also includes the ability to add "tags" to an event to capture a variety of categorisation elements. Future
versions of this specification will use experience working with real-world data to decide the best approach of
formalising these categories.
</p>
</div>
## Organisers (Persons and Organizations)
Events have __*organisers*__. An event organiser might be a __*Person*__ or an __*Organization*__.
The organiser of an event is the person or organisation who arranged and/or hosts the event. The organizer
will be the person or organisation who is ultimately responsible for an Event.
Examples of organisers might be coaches, or a local sports club.
Events may involve other named individuals or organisations. Examples might include named staff who will be participating
in the event in addition to the main organiser. These are referred to as __*contributors*__.
In addition to their names, some systems may have additional information about organisers and contributors.
E.g. links to their web sites, photos, logos or contact details.
<div class="note">
<p>__Applications must not publish personal data without permission__</p>
<p>
This specification provides a data model for publishing information about individual people, e.g. coaches,
volunteers, etc. However applications <em class="rfc2119">MUST</em> respect privacy and data protection laws and must not publish
data about individuals without their consent.
</p>
<p>
The ability to publish this type of data has been included because event organisers often choose to publicly
share some information about themselves to help advertise an event. E.g. their name and some background on
their qualifications or experience. But this information <em class="rfc2119">MUST</em> not be published as open data without getting the
consent of the individual concerned.
</p>
</div>
## Places
Events take place in a __*location*__. But, depending on the activity, the location
may be defined to different levels of precision. For example:
* A gym class may take place in a leisure centre at a specific address or other precisely defined location
* A cycling or walking event might start at a specific location, but will subsequently follow a route
* An exercise or running group might meet in an area of a local park, rather than at a specific address
In addition to this, data publishers will have different approaches for capturing location data.
Recognising this need for flexibility, this model proposes that a location can be specified as any of the
following:
* a description, e.g. "Meet by the lake, in Victoria Park"
* an address
* a venue, such as a leisure centre, which might have an address and/or a latitude or longitude
* a facility within a larger venue, e.g. a football pitch which is part of a leisure centre
This specification uses __*Place*__ as a general concept to refer to all types of locations, venues and facilities.
The concept of Place therefore covers general outdoor areas such as parks, event venues (e.g. a Leisure centre)
and facilities within a venue (e.g. a squash court, running track, etc). Facilities are contained in Places.
A __Sports Activity Location__ is a type of Place that is used to describe a facilities within a broader
Place.
Places may have additional descriptive properties, for example:
* a name
* an address and/or geographic coordinates
* opening hours
## Programmes and Brands
Events are often organised and run in a variety of different ways. This tailoring
might include adjusting the activity to a particular type of participant, demographic.
Or it could include running the event in a particular style, e.g. with a fixed routine
or sequence of activities.
A __*Programme*__ describes a means of organising and running a Physical Activity. Some programmes are very loosely defined.
While others are more structured and may be run to a specific agenda or in a particular style.
Programmes are often associated with branding or marketing that helps participants understand more about what they
can expect from an event of that format. Formats might be offered or overseen by specific organisations
Examples of programmes include:
* Les Mills BodyPump
* Learn to Row, from British Rowing
* Back to Netball, from England Netball
Programmes provide another means of tagging or describing Events to help describe them to
participants. When participants are looking for opportunities they may be interested in
discovering Events based on either the general activity (e.g. Running) or a specific
programme (Back to Netball).
## Offers
Some opportunities are freely available for anyone to attend. Others are only available to members or
paying attendees.
An __*Offer*__ is used to describe the terms under which a participant can pay to attend an event.
<div class="note">
<p>
The concept of an Offer is taken from Schema.org, which itself references the [Good Relations](http://www.heppnetz.de/projects/goodrelations/)
vocabulary for ecommerce. The data model described in a later section is not intended as a
complete specification. The concept is introduced in this version of specification to highlight
the support available in Schema.org for associating offers with events. Later versions of the specification
will explore the area of booking in more detail.
</p>
</div>
## Facility Use and Slots
Not all opportunities to be physically active are scheduled Events. Leisure centres and other locations also provide
facilities (e.g. squash courts, pitches, table tennis tables) that are available for use by participants.
To manage demand these facilities are usually available for hire at specific times of day. These are referred to as __Slots__.
A Slot is an opportunity to use a facility at a specific time and a specific duration, e.g. from 10am for 30 minutes
Some facilities are permanent parts of a leisure centre (or other Place). For example tennis courts, football pitches, etc.
But many leisure centres have flexibility to reconfigure their spaces to support different, often mutually exclusive ways.
For example an individual sports hall might be used as either a single indoor 5-a-side pitch, or as two separate badminton courts.
Modelling the potential configurations of these spaces is outside the scope of this specification. The community group has
chosen to take a more user centred view of describing opportunities to use facilities. This supports our
primary use case of enabling the discovery of opportunities.
A __Facility Use__ is a product that is offered to potential participants. It reflects the ability to use or hire a
facility at a specific location. A platform can publish data about the range of products on offer at a location, updating
their availability as facilities are booked by participants.
The following properties will help to describe the specific Facility Use product on offer:
* basic descriptive attributes of the product, such as its name, description, etc
* the activity or activities for which the facility is to be used
* the location of the facility
* an offer to use the facility, for a specific price
* the Slots during which the product is available, including any associated offers
Some facility use products are opportunities to use a individual, identifiable facility, e.g. Tennis Court 1.
These are referred to a as __Individual Facility Uses__. The location of these products will be a __Sports Activity Location__.
Otherwise, a Facility Use will describe an oppirtunity to use less permanent facilities, e.g. a table tennis table that will be moved into a sports hall on demand, or for an unnamed facility that will be allocated by a platform during booking. In this case the
location will be for the Place in which the facility is available.
Facilities may be offered for use at a single price at any time of day, or the price may vary depending on on which Slot
is used.
As the use of facility is a self-directed activity it will differ from an Event in that is will not be lead, coached, etc.
## Route Guidance
In addition to Events and Facilities hosted by leisure or recreational operators, opportunities for exercise may alse be presented by outdoor trails and pathways suitable for e.g. walking, cycling, horse-riding, etc. For the purposes of this specification, such trails and pathways are referred to as __Routes__, and information about them as __Route Guidance__.
In the OpenActive context, __Routes__ are considered to be a geographical entity: that is to say, the path or trail itself, as characterised by distance, terrain, elevation, and other strictly geographical data points. __Route Guidance__, by contrast, consists of information users might find helpful in accessing or engaging with the __Route__, for instance its starting point, degree of challenge, points of interest, etc.
Note that modelling of __Routes__ themselves is beyond the current scope of this specification, beyond basic provision of a .gpx file or similar for pathfinding. __Route Guidance__, however, **is** within scope, with the intention that such __Metadata__ objects should give users all the information necessary for them to engage with the activity opportunity the __Route__ presents.
Note that __Route Guidance__ objects may exist either as attributes of a scheduled Event or Session (acting as an amenity or resource supporting a planned activity), or as self-standing entitites (simply indicating the existence or availability of a __Route__ for use).
</section>
<section>
# Data Model
The data model described in the following sections reuses existing standards and vocabularies which
have then been extended to cover the additional requirements needs to support the publication of
opportunity data.
The Simple Knowledge Organisation System ([[SKOS]]) is a W3C standard for publishing taxonomies and
category schemes. It can be used to help publish and organise Activity Lists and to describe
Physical Activities.
Schema.org [[SCHEMA-ORG]] provides an existing well-used and documented data model for publishing
data to the web. It provides an existing model for describing Events, Organisations, People, and
Places.
Both standards are widely used, and can be used to publish data in a variety of structured formats, including
[[JSON-LD]].
The __[*OpenActive Vocabulary*](https://www.openactive.io/ns/)__ [[OpenActive-Vocabulary]] is a custom vocabulary designed to support the publication of
opportunity data. It defines a number of new terms that extend SKOS and Schema.org to cover additional
requirements highlighted in this specification.
<div class="note">
Developers looking for a quick primer on the model and how to use it to structure opportunity data may want to refer to the
[[Publishing-Opportunity-Data]] primer which provides many more examples.
</div>
## Namespaces
The rest of this specification makes use of the following namespaces:
<dl>
<dt>`dc:`</dt>
<dd>`http://purl.org/dc/terms/`</dd>
<dt>`schema:`</dt>
<dd>`https://schema.org/`</dd>
<dt>`skos:`</dt>
<dd>`http://www.w3.org/2004/02/skos/core#`</dd>
<dt>`geo:`</dt>
<dd>`http://www.w3.org/2003/01/geo/wgs84_pos#`<dd>
<dt>`oa:`</dt>
<dd>`https://openactive.io/`</dd>
</dl>
<div class="note">
<p>
In the following sections all referenced terms have been qualified using their namespace prefix. This highlights the
source vocabulary in which they have been defined. Terms have also been linked to their definitions.
</p>
<p>
The examples in each section use [[JSON-LD]] syntax and reference the [OpenActive JSON-LD context](https://openactive.io/ns/oa.jsonld) defined by [[OpenActive-Vocabulary]], which is accessible at `https://openactive.io/` when using an `Accept` header that includes `application/ld+json`.
</p>
<p>
The context removes the need to use explicit namespace prefixes in the JSON documents. The context also maps the JSON-LD [@type](https://www.w3.org/TR/json-ld/#specifying-the-type) and [@id](https://www.w3.org/TR/json-ld/#node-identifiers) properties to simple keys (`type` and `id`). This further limits the amount of JSON-LD syntax exposed to developers.
</p>
</div>
## Data Model Overview
The following table provides a high-level summary of how the concepts introduced in the previous sections map to
definitions in SKOS, Schema.org and the OpenActive Vocabulary ([[OpenActive-Vocabulary]]).
|Concept|Mapping|Notes|
|--- |--- |--- |
|Activity List|[skos:ConceptScheme](https://www.w3.org/2009/08/skos-reference/skos.html#ConceptScheme)|Activity lists are controlled vocabularies and map well to the definition of a SKOS Concept Scheme.|
|Physical Activity|[skos:Concept](https://www.w3.org/2009/08/skos-reference/skos.html#Concept)|Individual Physical Activities can be represented as individual SKOS concepts|
|Event|[schema:Event](https://schema.org/Event)|Schema.org provides a well defined model for Events with properties that cover many
of the core requirements for opportunity data. This specification defines some
additional types of Event and properties for describing them in the context of
publishing opportunity data.|
|Place|[schema:Place](https://schema.org/Place)|As well as the general definition of a Place, Schema.org defines sub-types including
[schema:EventVenue](https://schema.org/EventVenue) and [schema:SportsActivityLocation](https://schema.org/SportsActivityLocation) which can be used where appropriate|
|Facility Use|[schema:FacilityUse](https://schema.org/FacilityUse)|Products that describe opportunities to use facilities in a location|
|Organization|[schema:Organization](https://schema.org/Organization)|Covers all types of organisations, including companies, clubs, etc|
|Person|[schema:Person](https://schema.org/Person)|An individual person|
|Brand|[schema:Brand](https://schema.org/Brand)|The brand used to describe a programme of activities.|
|Offer|[schema:Offer](https://schema.org/Offer)|Schema.org provides an existing model for describing offers to pay to participate in an Event.|
|Route Guidance|---|While properties within the Route Guidance model are often drawn from schema.org, the model itself originates with OpenActive.|
## Identifying and Linking Resources
This specification adopts the same approach as Schema.org and encourages the use of URLs as unique identifiers for resources.
Information about Events, Places, Organizations and other types of resources should already have been published online to
make that information accessible to users. Using existing URLs as identifiers avoids the need to define a new identifier
scheme for resources described in opportunity data.
There will generally be a single canonical URL for a resource, e.g. the homepage for an Organization or Place, or
a public web page advertising an Event.
If there are several different URLs that may be used to identify a resource, it is recommended that systems use:
* a direct link to the resource that avoids redirects
* a stable link that will resolve to a public web page, accessible to both web browsers and applications
* a consistent link that will allow reusers to rely on the URL as an identifier, e.g. to merge in updated data
<div class="warning" title="Route Guidance property URLs in the oa: namespace
currently do not resolve. Providing resolvable definitions is a work-in-progress
to be completed 2019-08-01."></div>
This specification provides three properties for identifying resources:
* `@id` - is used to [assign a globally unique URI to a resource](https://www.w3.org/TR/json-ld/#node-identifiers). This may resolve to further machine-readable
information about the resource, e.g. as a reference to an API endpoint. When supplied, this URI <em class="rfc2119">MUST</em> be stable and unchanging over time. Applications harvesting and
indexing opportunity data <em class="rfc2119">SHOULD</em> use this as the unique identifier for the resource
* [schema:url](https://schema.org/url) - provides a link to a public web page about the resource. Further machine-readable metadata
<em class="rfc2119">MAY</em> be discoverable from that web page. Applications <em class="rfc2119">MUST</em> be able to use this URL as a means for providing users with a link to more information about a resource
* [schema:identifier](https://schema.org/identifier) - provides a means of sharing other identifiers for a resource, e.g. a company or registration number for an Organization, or an internal identifier for an Event. Other public identifiers can be via a [schema:PropertyValue](https://schema.org/PropertyValue). Applications <em class="rfc2119">MAY</em> use this
as a unique identifier for the resource, if there is no `@id` available.
In short, the `@id` property provides a unique global identifier, while the `schema:url` provides a means to provide a link to
a public web page about a resource.
If applicable then publishers may choose to use the same URI for these two properties. If an `@id` property is not provided then
applications <em class="rfc2119">MAY</em> choose to rely on the value of the [schema:url](https://schema.org/url) property as a unique identifier.
The option to use two different URLs is useful when there is a need to distinguish between a unique identifier and a
public resource. For example a platform hosting opportunity data may need to assign a unique identifier to a resource
that is separate to its public web page.
<pre class="example" title="Simple event description"><code>
{
"@context": "https://openactive.io/",
"type": "Event",
"id": "http://host.opportunity-data.com/id/12345",
"url": "http://my-leisure-centre.example.org/events/1",
"name": "Tai chi Class"
}
</code>
</pre>
In the above example the `@id` property provides a unique identifier across
the hosting application. But the public URL for the Event uses a separate,
customer-specific domain.
## Required and Optional Properties
The following sections include more detail about the properties available to
describe each type of resource. Some properties are considered to be essential
to ensure the provision of a minimally useful set of information about each
resource. These <em class="rfc2119">REQUIRED</em> properties
<em class="rfc2119">MUST</em> be provided.
All other properties are considered to be <em class="rfc2119">OPTIONAL</em>.
Some properties have been marked as <em class="rfc2119">RECOMMENDED</em>.
Publishers <em class="rfc2119">SHOULD</em> provide these properties if it is
feasible to do so, as they will improve the quality and usability of their data.
Where data is not available to populate <em class="rfc2119">RECOMMENDED</em> and
<em class="rfc2119">OPTIONAL</em> properties, publishers
<em class="rfc2119">MUST</em> exclude these from their data. Published data
<em class="rfc2119">MUST</em> not include properties with null values, empty
strings or empty arrays.
Data publishers <em class="rfc2119">MAY</em> include additional properties,
e.g. from Schema.org or other vocabularies when helpful to describe their data.
See the section on **Extending the Model** for more information.
Applications that consume opportunity data <em class="rfc2119">MUST</em> ignore
any properties that they don't understand. This allows data publishing practices
within the sector to evolve as required.
## Controlled Vocabularies
When the value of a property might be one of a fixed set of values, it can be useful
to publish that list of values as a "controlled vocabulary".
This allows a publisher to publish the list of values, with supporting documentation
and definitions in a machine-readable format. We use the existing [[SKOS]]
standard as a means of publishing these vocabularies.
A number of properties in this data model allow data publishers to use values
from a controlled vocabulary, e.g. `oa:activity`, `oa:level`, `oa:category`, etc.
Publishers <em class="rfc2119">SHOULD</em> publish the controlled vocabularies referenced from
their data in a machine-readable format, under an open licence.
The OpenActive Community group MAY create and recommend the use of specific
controlled vocabularies to help improve the consistency of how data is published.
Publishers SHOULD use values from standard vocabularies where available.
For example, the community group is developing a controlled vocabulary that defines
a standard activity list. Values from this vocabulary can be used in the `oa:activity`
property.
The OpenActive Community Group may decide to define and recommend
some controlled vocabularies for use in these properties. At present the
values of these properties are left deliberately open to encourage publication
of open data that may inform future standardisation.
## Describing Events (<code>schema:Event</code>)
<p>
The Schema.org [schema:Event](https://schema.org/Event) type corresponds to the definition of
Event given earlier in this specification. The properties and relationships associated with the
[schema:Event](https://schema.org/Event) type can all be used to describe events.
</p>
<p>
The following table illustrates how the essential aspects of describing an event map to
existing Schema.org properties and/or properties defined in the OpenActive Vocabulary.
</p>
|Property|Status|Type|Notes|
|--- |--- |--- |--- |
|@type|REQUIRED|String|Identifies the object as being an Event|
|@id|RECOMMENDED|URI|A URI providing a unique, stable identifier for the resource|
|[schema:url](https://schema.org/url)|REQUIRED|URI|Link to a web page (or section of a page) that describes the event|
|[schema:identifier](https://schema.org/identifier)|OPTIONAL|Number, String, [schema:PropertyValue](https://schema.org/PropertyValue) or an array of [schema:PropertyValue](https://schema.org/PropertyValue)|A local identifier for the resource.|
|[schema:name](https://schema.org/name)|REQUIRED|String|The name of the event|
|[schema:description](https://schema.org/description)|RECOMMENDED|String|A free text description of the event|
|[schema:image](https://schema.org/image)|OPTIONAL|Array of [schema:ImageObject](https://schema.org/ImageObject)|One or more images or photos that depicts the event, e.g. a photo taken at a previous event|
|[schema:startDate](https://schema.org/startDate)|RECOMMENDED|String|The start date and time of the event. Can be specified as a [schema:Date](https://schema.org/Date) or [schema:DateTime](https://schema.org/DateTime). While this property is marked as OPTIONAL, a data publisher MUST provide either a [schema:startDate](https://schema.org/startDate) or at least one [schema:eventSchedule](https://pending.schema.org/eventSchedule) for an event.|
|[schema:endDate](https://schema.org/endDate)|RECOMMENDED|String|The end date and time of the event. Can be specified as a [schema:Date](https://schema.org/Date) or [schema:DateTime](https://schema.org/DateTime). It is RECOMMENDED that publishers provide either an [schema:endDate](https://schema.org/endDate) or a [schema:duration](https://schema.org/duration) for an event.|
|[schema:duration](https://schema.org/duration)|RECOMMENDED|String|The duration of the event given in [[ISO8601]] format. Durations MUST NOT be zero length. If duration is unknown it should be omitted. A duration MUST be provided if both a start and end date are available.|
|[schema:location](https://schema.org/location)|REQUIRED|[schema:Place](https://schema.org/Place)|The location at which the event will take place. Or, in the case of events that may span multiple locations, the initial meeting or starting point.|
|[schema:organizer](https://schema.org/organizer)|REQUIRED|[schema:Person](https://schema.org/Person) or [schema:Organization](https://schema.org/Organization)|The person or organization responsible for running an event. An organizer might be an [schema:Organization](https://schema.org/Organization) or a [schema:Person]((https://schema.org/Person).|
|[schema:contributor](https://schema.org/contributor)|RECOMMENDED|Array of [schema:Person](https://schema.org/Person)|One or more people, e.g. a coach, staff member or volunteer who will be helping to run the event.|
|[schema:maximumAttendeeCapacity](https://schema.org/maximumAttendeeCapacity)|RECOMMENDED|Integer|The maximum capacity of the event|
|[schema:remainingAttendeeCapacity](https://schema.org/remainingAttendeeCapacity)|RECOMMENDED|Integer|The number of places that are still available for the event|
|[schema:eventStatus](https://schema.org/eventStatus)|RECOMMENDED|[schema:EventStatusType](https://schema.org/EventStatusType)|The status of an event. Can be used to indicate rescheduled or cancelled events|
|[schema:subEvent](https://schema.org/subEvent)|OPTIONAL|Array of [schema:Event](https://schema.org/Event)|Relates a parent event to one or more child events. Properties describing the parent event can be assumed to apply to the child, unless otherwise specified. A child event might be a specific instance of an Event within a schedule|
|[schema:superEvent](https://schema.org/superEvent)|OPTIONAL|[schema:Event](https://schema.org/Event)|Relates a child event to a parent event. Properties describing the parent event can be assumed to apply to the child, unless otherwise specified. A parent event might specify a recurring schedule, of which the child event is one specific instance|
|schema:eventSchedule|Array of OPTIONAL|[schema:Schedule](https://pending.schema.org/Schedule)|A schedule defines a repeating time period used to describe a regularly occurring Event.|
|[oa:schedulingNote](https://openactive.io/schedulingNote)|OPTIONAL|String|Provides a note from an organizer relating to how this Event is scheduled. For example "This event doesn't run during school holidays", or "This is a regular weekly session". Where possible publishers SHOULD provide machine-readable descriptions of schedules via the `schema:eventSchedule` property.|
|[oa:activity](https://openactive.io/activity)|REQUIRED|Array of [skos:Concept](https://www.w3.org/2009/08/skos-reference/skos.html#Concept)|Specifies one or more physical activities that will take place during an event. The activities SHOULD ideally be taken from an activity list.|
|[oa:category](https://openactive.io/category)|OPTIONAL|Array of String or [skos:Concept](https://www.w3.org/2009/08/skos-reference/skos.html#Concept)|Provides a set of tags that help categorise and describe an event, e.g. its intensity, purpose, etc.|
|[oa:ageRange](https://openactive.io/ageRange)|RECOMMENDED|[schema:QuantitativeValue](https://schema.org/QuantitativeValue)|Indicates that an event is suitable for a specific age range. Specified as a [QuantitativeValue](https://schema.org/QuantitativeValue) with [minValue](https://schema.org/minValue) and [maxValue](https://schema.org/maxValue) properties|
|[oa:genderRestriction](https://openactive.io/genderRestriction)|OPTIONAL|[oa:GenderRestrictionType](https://openactive.io/GenderRestrictionType)|Indicates that an event is restricted to Male, Female or a Mixed audience. Values should be one of the three URIs defined by this specification (see below).|
|[oa:programme](https://openactive.io/programme)|OPTIONAL|[schema:Brand](https://schema.org/Brand)|Indicates that an event will be organised according to a specific Programme|
|[oa:attendeeInstructions](https://openactive.io/attendeeInstructions)|OPTIONAL|String|Provides additional notes and instructions for event attendees. E.g. more information on how to find the event, what to bring, etc.|
|[oa:leader](https://openactive.io/leader)|OPTIONAL|Array of [schema:Person](https://schema.org/Person)|Refers to a person (`schema:Person`) who will be leading an event. E.g. a coach. This is a more specific role than an organiser or a contributor|
|[oa:accessibilitySupport](https://openactive.io/accessibilitySupport)|OPTIONAL|Array of String or [skos:Concept](https://www.w3.org/2009/08/skos-reference/skos.html#Concept)|Used to specify the types of disabilities or impairments that are supported at an event|
|[oa:accessibilityInformation](https://openactive.io/accessibilitySupport)|OPTIONAL|String|Provide additional, specific documentation for participants about how disabilities are, or can be supported at the Event.|
|[oa:isCoached](https://openactive.io/isCoached)|OPTIONAL|Boolean|A boolean property that indicates whether an Event will be coached. This flag allows an Event to be marked as being coached without having to specify a named individual as a coach. This addresses both privacy concerns and also scenarios where the actual coach may only be decided on the day. If this property is not specified then consumers SHOULD assume a value of undefined|
|[oa:level](https://openactive.io/level)|RECOMMENDED|Array of String or [skos:Concept](https://www.w3.org/2009/08/skos-reference/skos.html#Concept)|A general purpose property for specifying the suitability of an event for different participant “levels”. E.g. beginner/intermediate/advanced. Or in the case of martial arts, specific belt requirements. Values SHOULD ideally be drawn from a controlled vocabulary.|
|[oa:meetingPoint](https://openactive.io/meetingPoint)|OPTIONAL|String|Instructions for the attendees of an Event about where they should meet the organizer or leader at the start of the event. Some larger locations may have several possible meeting points, so this property provides additional more specific directions.|
|[schema:isAccessibleForFree](https://schema.org/isAccessibleForFree)|OPTIONAL|Boolean|Indicates that an Event is free to attend. If an Event is bookable in advance, then publishers SHOULD also define a zero priced [schema:Offer](https://schema.org/Offer). If the only [schema:Offer](https://schema.org/Offer) for an Event is zero priced, then publishers SHOULD include this property with a value of `true`.|
|[schema:offers](https://schema.org/offers)|RECOMMENDED|Array of [schema:Offer](https://schema.org/Offer)|Provides one or more offers to book and participate in an Event|
|[schema:potentialAction](https://schema.org/potentialAction)|OPTIONAL|Array of [schema:Action](https://schema.org/Action)|Provides one or more actions that can be carried out on this Event, e.g. through interacting with an API or other service. The [[Open-Booking-API]] defines a `ReserveAction`.|
|oa:RouteGuidance|OPTIONAL|Array of [oa:RouteGuidance](https://openactive.io/RouteGuidance)|See below, [Describing Route Guidance](#describing-route-metadata-oa-RouteGuidance-)|
<p>
The following example shows a simple event description, including its start time and duration:
</p>
<pre class="example" title="Simple event description"><code>
{
"@context": "https://openactive.io/",
"type": "Event",
"url": "http://www.example.org/events/1",
"name": "Tai chi Class",
"description": "A tai chi class intended for beginners",
"attendeeInstructions": "Please wear trainers and comfortable clothing",
"startDate": "2017-03-22T20:00:00-05:00",
"duration": "PT60M"
}
</code>
</pre>
This basic description can be improved by providing information about its location and organizer.
<pre class="example" title="Adding a venue and an organizer"><code>
{
"@context": "https://openactive.io/",
"type": "Event",
"url": "http://www.example.org/events/1",
"name": "Tai chi Class",
"description": "A tai chi class intended for beginners",
"attendeeInstructions": "Please wear trainers and comfortable clothing",
"startDate": "2017-03-22T20:00:00-05:00",
"duration": "PT60M",
"organizer": [{
"type": "Organization",
"url": "http://example.org/orgs/bristol-tai-chi",
"name": "Bristol Tai Chi"
}],
"location": {
"type": "Place",
"name": "ExampleCo Gym",
"address": {
"type": "PostalAddress",
"streetAddress": "1 High Street",
"addressLocality": "Bristol",