►
From YouTube: OpenActive W3C Community Group Meeting / 2018-06-20
Description
A public hangout for members of the OpenActive W3C Community Group.
Agenda: https://lists.w3.org/Archives/Public/public-openactive/2018Jun/0000.html
For more information visit: https://www.openactive.io/w3c-community-group.html
A
B
I've
got
this
one
facilities
that
return.
Hopefully
it
will
be
returning
and
then
going
away
because
it'd
be
done
would
be
complete.
The
discussion
on
this
in
this
cold
anyway,
any
kind
of
feedback
so
yeah.
So
we
had
a
really
really
I
think
useful,
productive
discussion
last
time
that
we
had
still
hadn't
quite
got
to
level
of
agreement
on
some
of
the
the
approach
we're
taking.
B
B
So
we
don't
get
kind
of
bogged
down
in
things
that
we
might
want
to
do
in
the
future,
or
you
know
kind
of
extra
requirements
that
aren't
kind
of
critical,
just
because
being
able
to
start
to
publish
and
use
some
of
this
data.
So
we're
going
to
focus
the
majority
of
their
call
on
that
and
then
we'll
see
how
we're
doing
for
time.
B
C
B
Kind
of
focusing
on
the
kind
of
use
case
so
I
wanna
make
sure
that
we
recap
them
to
what
to
use
that
as
a
test.
If
really,
if
the
data
model
covers
the
use
cases
that
we've
identified,
then
we
should
feel
comfortable
about
moving
forward
as
we'll
see
in
a
minute.
There's
a
few
extra
use
cases
that
have
come
up
since
then,
some
of
which
we
can
I
think
we
can
encompass,
inspect
small
changes.
B
Some
others
I
think
need
for
the
work
discussion
operation,
but
shouldn't
hold
us
up
moving
forward
so
that
we
can
get
some
data
published
as
soon
as
possible.
So
so
the
key
things
that
we
need
to
be
able
to
do
around
facilities
is,
we
need
to
be
able
to
publish
opportunities,
look
facility,
a
leisure
center,
so
being
able
to
broadly
say
you
can
play
tennis
at
Bethlehem.
You
have
in
turn,
you
can
play
football,
and
just
it
gives
a
level
indication
of
what
opportunities
are
available.
B
People
to
do
that
we
need
to
be
able
to
describe
the
slots
are
available.
So
what
about?
What?
Times
of
the
day?
Can
people
participate
in
those
activities?
Those
facilities
and
indicate
whether
they're
we
need
to
be
able
to
do
pricing
either
pricing
for
using
slots
or
slots
specific
pricing
to
cover
peak
pricing
for
particular
pairs.
Okay,
and
we
also
need
to
be
able
to
have
provide
that
kind
of
information
that
level
of
detail
for
individual
facilities.
E
B
Yeah
yeah,
okay,
yeah
right
so
sometimes
pictures
help
I
thought
you
might
help
with
some
of
the
discussion,
even
though
they're
not
very
good,
very
good
pictures.
So
so
to
give
an
example,
so
we've
got
so
it's
a
pleasure
center.
We
can
book
football
pitches
we
can
play
so
with
the
center
business
Sports
Hall.
We
can
use
that
Sports
Hall
to
play
football
or
we
could
use
it
to
play
badminton,
alright,
so
there's
different
configurations
of
the
sports
all
in
one.
It's
divided
up
into
two
football
pitches
in
another.
B
It's
divided
up
into
six
courts,
so
we've
decided
early
on
that.
What
we
didn't
want
to
do
was
describe
all
of
those
configurations
because
there's
an
awful
lot
of
detail
in
those-
and
we
didn't
want
to
put
all
of
those
business
rules
out.
What
we
wanted
to
focus
on
is
more
a
user-centered
approach,
user,
centered
design
so
focus
on
the
products
that
Pete
there
and
the
opportunities
that
are
being
presented
to
people
rather
and
a
description
of
how
an
individual
Hall
could
be
divided
up
and
used
within
that.
B
So
what
the
current
data
model
is
geared
up
to
do
is
to
support
the
description
of
those
products.
So
we
can.
We
can
currently
describe
what
we're
calling
a
facility
use.
So
there's
a
facility
use
to
play
football
in
sports
hall.
There
is
a
you
can
also
play
badminton
in
the
Sports
Hall
when
we
published
that
those
facilities
as
individual
products
there'll
be
some
structured
data
around
it.
B
So
there's
a
terrible
sketch
in
the
bottom
left
there
for
showing
bits
of
what
we
might
include
around
a
badminton,
so
the
facility
uses
for
a
particular
activity
badminton,
it's
the
the
products
kind
of
name,
so
it
would
be
badminton
in
the
sports
hall,
for
example
the
location
for
where
you'll
be
doing.
That
would
be
in
the
Sports
Hall,
so
we're
saying
specifically,
which
bit
of
the
location
you've
been
doing
it
in
and
then
there'll
be
an
array
of
slots.
B
B
So
that's
kind
of
one
one
use
of
the
current
model.
It
fits
well
with
this
kind
of
sports
all
set
up
where
the
individual
configurations
they're
specific.
You
know
the
specific
badminton
courts
or
the
football
pitches
they're
they're,
more
ephemeral
things
they
might
be
set
up
and
tear
down
over
time.
B
They
don't
really
have
an
identity
beyond
the
fact
that
you
know
you
might
always
be
caught,
one
in
the
left-hand
corner
of
the
hall
right,
so
they're,
really
all
the
only
information
we
need
to
provide
to
people
is
you
can
there
was
an
opportunity
for
you
to
play
football
in
the
Sports
Hall
at
10
o'clock
tomorrow
or
there's
two
slots
available,
perhaps
12
o'clock?
So
that's
high
level
information.
B
There
and
the
the
way
that
we've
defined
the
current
facility
use
model
in
the
draft
covers
that
already
there's
a
slightly
different
example.
Pictures
this
sketch
isn't
as
good
here.
So
my
apologies,
but
let's
stick
to
example:
where
we're
using
bath
where's
your
sensor,
so
I
might
be
able
to
go
and
play
tennis
in
my
local
leisure
center.
I
might
be
able
to
go
and
play
tennis
lawn
tennis,
or
am
I
there
to
go
and
do
tennis
on
on
a
hardcore.
B
D
D
B
Okay,
so
yeah,
so
in
the
letter
sent
er,
there
may
be
facilities
for
me
to
play
on
hard
core
facilities
for
me
to
play
lawn
tennis
right
so
drawing
on
the
early
example,
both
of
those
things
could
be
individual
products.
Individual
facility
uses
because
a
user
might
just
want
to
say:
where
can
I
play
lawn
tennis
locally,
and
we
want
to
just
be
able
to
show
them
that
those
lawn
tennis
facilities
in
buffalo
show
center.
So
we
can
provide
published
data
at
that
level,
so
we
can
provide
slots
offers
at
that
kind
of
high
level.
B
So
we
don't
have
to
go
into
any
detail
around
exactly
which
tennis
courts
are
available.
We
would
just
indicate
how
many
were
available
at
different
different
times
of
the
day
and
just
as
I
was
talking
through,
but
we
do
have
a
requirement
to
be
able
to
provide
information
about
individual
facilities,
individual
chords,
individual
pitches,
because
we
might
want
to
provide
more
information
on
suit
the
surface.
B
B
Information
is
published,
individual
products
for
each
of
their
courts,
so
here
on
the
right-hand
side,
I've
got
a
facility
use
which
is
lawn
tennis
on
korban
there's
a
lawn
tennis
encore
and
each
of
those
would
have
its
own
slots,
its
own
offers
and
its
location.
But
here
it's
the
specific
location
is
called
one
right,
so
I
know
exactly
where
I'm
going,
whereas
the
higher
level
for
lawn
tennis,
it
would
just
be
at
the
Nature
Center
that
makes
sense
so
far.
B
Okay,
so
I
think
this.
This
starts
to
address
so
I
think
this
covers
the
the
requirements
we
have
and
also
the
feedback
that
we
had
from
Jaime.
Inter
we've
got
a
high
level.
We've
got
a
high
level
kind
of
more
aggregated
view
of
providing
the
availability
and
product
information,
so
lawn
tennis,
it
delicious
sensor,
as
well
as
a
disaggregated
view
of
the
availability
of
individual
courts.
B
Okay,
there's
a
bit
of
fine-tuning
to
be
done
on
the
current
data
model,
but
it
actually
encompasses
this
already,
based
on
those
kind
of
discussions
that
we've
had
in
the
past.
I'm
gonna
switch
to
a
different
diagram,
which
kind
of
basically
shows
the
same
information,
but
in
a
kind
of
more
that
kind
of
data
model
view.
So
you
can
maybe
get
your
head
around
how
it
fits
together,
so
I'll
try
and
talk
through
it,
starting
from
the
top
left,
so
in
the
data
modification
of
place.
B
G
B
C
B
Number
of
remaining
uses
maximum
uses,
which
is
useful
in
this
context,
because
we
might
want
to
be
able
to
say.
Actually
there
are
six
courts,
six
lawn
tennis
courts
a
bath.
We
conclude
that
in
the
maximum
and
as
the
slots
get
booked
up,
we
will
reduce
the
number
of
remaining
uses
down
to
zero,
so
that
mechanism-
those
are
new
properties
that
will
we'll
put
into
the
date
model.
B
When
were
publishing
data
about
a
specific
use
of
a
fixed
facility
like
at
court,
but
it'll
have
exactly
the
same
information
as
we've
just
been
talking
about,
so
it
will
have
you'll,
have
a
list
of
slots.
You'll
have
location
and
offers
associated
with
it.
What's,
but
what
is
different
as
a
project
and
the
earlier
diagram?
Is
that
there's
different
look?
B
Those
are
four
different
locations,
the
aggregated
location,
we're
just
talking
about
a
product,
that's
available
in
the
leisure
center,
so
it's
a
place,
but
for
an
individual
facility
use
it
to
make
it
clearer
that
we're
talking
about
a
specific
chord
or
a
specific
pitch.
We
all
associate
that
with
a
location
which
will
be
a
will
use.
Another
schema.org
type,
which
is
a
sports
of
activity,
location,
which
is
they
defined
for
exactly
this
purpose,
for
describe
pointing
to
a
pitch
or
record.
Was
the
similar
facility.
A
B
B
Okay,
so
that's
the
kind
of
some
of
the
conversation
I've
just
been
having
with
Nick
and
hopefully,
as
I
told
through
that
you
can
see
that
model
addresses
the
the
main
use
cases.
The
first
use
case
of
a
is
where
we're
talking
about
lawn
tennis,
athleisure
sensor
or
playing
football
in
the
sports
hall.
We've
got
properties
that
will
provide
available
and
availability
information
for
individual
slots,
so
we
can
say
that
how
many
remaining
uses
there
are
at
a
particular
point
in
time.
B
I
haven't
shown
the
the
offers,
but
I
will
do
that
in
a
moment,
but
we
can
attach
offers
to
the
facility
used
to
provide
some
default
pricing,
but
we
can
also
attach
offers
to
individual
slots.
So
we
can
say
you
know
at
a
peak
time
of
the
day,
there
is
a
different
different
price
for
that
use
and
then
use
case
D,
probably
shot
that
obviously
availability,
those
opportunities
to
use
individual
facilities.
So
we
cover
that
as
well.
B
A
useful
thing
would
be
to
be
able
to
publish
the
opening
times
of
the
facilities
at
a
leisure
center.
So
this
is
death
separate
to
the
opening
times
with
leisure
center
itself.
So
we
need
a
way
to
do
that
again.
There
is
there's
already
support
for
that
in
schema.org,
because
it
has
a
way
to
describe
the
opening
hours
of
locations
so
that
we
can
just
attach
that
that
same
information
to
our
facilities
and
their
products.
B
So
that's
straightforward.
There
were
two
other
requirements
which
have
been
we've
mentioned,
we've
discussed,
but
I
don't
think
we
actually
have
a
strong
user
need
around
it,
particularly
based
on
looking
at
how
you
current
booking
systems
are
implemented.
So
the
first
one
was
allowing
users
to
book
longer
slots,
so
you
might
be
the
default
slot.
Duration
is
half
an
hour
and
somebody
might
want
to
book
it
for
a
full
hour.
So
we
discussed
whether
we
wanted
to
have
some
way
to
describe
that
in
the
data
model.
B
B
B
So
the
reason
I'm
kind
of
showing
this
is
to
show
that
there
is
a
way
to
support
it
within
the
current
data
model
and
the
current
schema.org
markup.
So
it's
there
if
people
want
to
use
it,
but
we
don't
necessarily
have
to
rush
to
get
it
into
the
specification
now
because
it
doesn't
look
like.
Actually.
This
is
a
feature
that
people
currently
offer
by
default
on
booking
systems.
A
B
A
B
Yeah
so
this
said,
let
me
just
say
this
Jason
example,
so
this
is
using
the
same
kind
of
same
model.
That
I
was
just
talking
about
this,
that's
Kony
in
the
specs,
so
it's
a
similar
to
use.
This
is
in
this
example.
It's
table
tennis
at
the
leisure
center.
So
it's
using
that
high-level
aggregated
view
of
talking
about.
We
have
an
array
of
events,
and
these
are
of
type
slots,
so
we
can
distinguish
them
from
any
other
events
that
are
being
published
in
data
feeds.
B
B
B
So
that's
how
it
could
work
so
if
we
can
fit
it
into
the
days
model,
but
at
the
moment
I'm
not
sure
that
we've
come
across
data.
That
kind
of
meets
this.
You
know
data
that
needs
this
kind
of
structure.
So
it's
something
that
we
can
we
can
do
with,
but
debating
exactly
how
they
should
work
shouldn't
hold
us
up
from
kind
of
moving
forward
to
be
delivering
on
the
core
requirements.
B
B
So
at
the
moment,
there's
no
way
in
the
data
model
to
describe
that
kind
of
adjacency
information,
but
I
think
at
the
moment
we
don't
have
a
strong
set
of
requirements
that
this
is.
This
is
something
that
is
important
enough,
that
we
need
to
get
it
into
the
data
model
right
away,
I
mean
because
it
only
applies.
I
think
reasonably
only
applies
to
certain
types
of
facilities
and
activities.
B
So
it's
not
necessarily
gonna
be
a
commonly
used
feature,
but
it's
also
worth
highlighting
that
just
because
we
don't
have
some
way
to
describe
adjacency
in
the
data
model
doesn't
mean
that
somebody
couldn't
implement
an
interface
or
provide
a
way
for
user.
To
do
that.
So
just
to
kind
of
give
an
illustration
here,
interface.
B
So
this
was
an
example
of
like
interface
on
earth.
I
think
one
of
the
lawn
tennis
sites
right
so
here
they're
presenting
the
slots
for
a
section
for
selection.
Of
course,
the
four
courts
particular
location
and
I
can
see.
You
know
if
I
want
to
book
in
adjacent
call.
I
can
just
do
that
as
a
multiple
people
to
purchase.
You
know,
I
could
just
choose
to
book
court,
1
and
court
to
write
and
and
that
that
information
is
already
in
the
parent
data
model.
B
There
isn't
we
don't
necessarily
need
to
bend
over
backwards
of
trying
to
put
a
machine-readable
representation
of
adjacency
or
dealing
with
a
kind
of
how
much
adjacent
inventory
might
be
available
into
into
the
model.
You
know
we're
not
we're
not
blocking
people
of
implementing
these
kind
of
features
or
users
from
achieving
what
they
want
to
do
of
playing
next
to
their
mates.
H
B
So
what
I
would
suggest,
then,
is
that
we
we
we
move
like
discussion
of
that
into
a
separate
proposal,
and
we
handled
that
as
a
you
know,
as
an
improvement
to
the
spec,
rather
than
us
blocking
kind
of
moving
forward
on
the
rest
of
it.
So
we
could
have.
We
know
we've
captured
the
requirements
which
I
think
is
useful
to
do
at
this
stage.
We
don't
have
to
have
done
all
of
the
modeling
work.
B
B
B
A
It
to
be
clear
on
on
the
kind
of
fun,
functional
restriction,
I,
suppose
that
there's
nothing
to
stop
us
doing
booking
two
consecutive
stops
for
F
with
the
model
as
Lee's
proposing,
because
you
can
just
book
eleven
ten
eleven
add
them
to
the
same
basking
complete
purchase.
You
know
what
it
does
restrict
is
that
you
can't
price
to
our
court
different
to
a
one-hour
Court
right
now
in
our
discussions
and
Jamie,
we
kind
of
said
that
of
all
the
data
we
know
about.
It's
always
the
you
know.
H
B
C
Yeah,
no,
that
all
seems
to
make
sense.
I
think
these
are
EF
and
G
points
are
something
that
we
can
kind
of.
Look
at
a
layered
date
in
the
wouldn't
say
would
be
essential
at
this
point
to
get
the
majority
of
it.
Yeah
I
would
say
that
they're
nice
to
haves
rather
than
essential
at
this
point,
so
you
happy
with
the
spec
completely
okay.
D
H
B
B
B
G
Yeah,
sorry,
if
there's
a
lot
of
background
noise
and
just
a
conference
here,
but
actually
really
like
agency,
which
is
currently
being
shown
and
I,
think
that
users,
as
you
said,
you
can
just
like
two
slots
if
they
want
to
book
them,
adjacent
shouldn't
really
be
merged
anyway,
so
yeah
I,
think
hobby
not
far
from
Ireland.
Okay,.
B
Awesome
wait
for
Nick
to
you
can
bring
Jamie
in
first
I'll
just
show
a
few.
These
are
the
examples
I'm
going
to
follow
up
after
the
call
and
provide
links
to
the
slides
and
examples,
but
for
each
of
the
each
of
the
use
cases.
So
the
a
through
f
I've
got
a
little
jason
example.
That
shows
how
we
would
look
in
the
current
data
model.
So
that's
in
the
current
draft.
There's
a
few
amends
that
I
need
need
to
put
in,
but
I
just
kind
of
want.
B
It
was
my
way
of
working
through
making
sure
that
that
should
be
covered
everything
so
just
a
very
briefly
kind
of
step
through
these
here's,
a
very
simple
since
use
example.
So
this
is
the
kind
of
aggregated
view,
so
it's
table
tennis,
leisure
center,
the
activities
table
tennis,
the
location
is
the
leisure
center,
and
then
we
provide
the
array
of
slots.
That's
the
basic
kind
of
basic
bits.
The
model.
B
B
C
B
H
A
E
A
A
H
B
B
That's
the
way
that
we'd
have
to
kind
of
do
at
the
moment,
I
think
unless
you
spit
it
out
as
a
separate
facility
use,
you
had
a
separate
product
for
it,
but
I
think
I
was
probably
less
less
useful.
I
just
wanted
to
show
because
we
hadn't
talked
about
it.
Much
is
that
kind
of
where
the
offers
might
work.
B
So
we
had
the
requirement,
so
this
is
C
being
as
published
default
and
slot
specific
pricing.
So
the
way
that
I'm,
proposing
that
this
would
work
would
be
that
we
can
provide
a
set
of
default
offers,
which
are,
is
an
array
of
offers,
that's
associated
with
the
facility
use
product.
So
here
a
30-minute
higher
is
10
quid,
but
then
for
individual
slots.
B
We
can
also
provide
offers
so
for
this
11
o'clock
slot.
There's
a
separate
array
of
offers
and
a
30
minute,
higher
we've,
actually
15
quid
so
we'll
end
up
documenting
I
think
that's
actually
going
into
the
booking
spec,
actually,
because
this
is
where
it's
most
most
relevant,
but
the
process
by
which
a
client
will
find
the
offer
that
is
most
applicable,
but
broadly,
it
will
be
unless
those
and
offers
array
as
associated
with
individual
slots,
you
would
use
the
offers
that
are
associated
with
the
product
right.
B
B
G
D
B
The
moment
we're
largely
using
existing
existing
terms
from
schema.org,
so
I
think
I'd
have
to
go
away
and
have
a
look
to
see
whether
they
incorporate
that
or
whether
this
new
we'll
need
to
put
in
but
I
think
perhaps
apart,
that
kind
of
discount
or
variable
pricing
would
would
be
stuff
that
we
probably
need
to
consider
as
part
of
the
maybe
as
part
of
the
booking
booking
work,
because
it's
a
visit,
there's
a
whole
range
of
additional
rules
and
requirements.
B
I
think
around
the
processing
of
offer
data,
because
what
I'd
find
you're
gonna
choose
the
client
will
have
to
choose.
You
know
offers
that
apply
to
the
user.
It
might
be
priced
age
range,
specific
pricing,
member,
a
non-member
pricing
office
might
be
available
for
time
periods
and
there,
as
well
as
other
kind
of
pricing
arrangements.
That's
about
a
whole
separate.
G
A
B
This
needs
to
change
based
on
mileage
discussion,
so
we're
going
to
be
calling
this
an
individual
facilities
so
that
you
can
a
client
can
more
easily
distinguish
between
these
products
that
are
about
the
use
of
an
individual
court
or
pitch
versus
those
are
for
just
use
of
a
broader
set
of
facilities
that
aggregated
level.
But
you
can
see,
we
can
starts,
do
things
by
attach
images
of
the
individual
pitch
those
other
provinces
that
we
can
put
in
to
describe.
You
know,
services,
etc.
B
The
only
difference
here
is
for
the
location,
we're
referring
to
a
sports
activity
location,
so
the
main
tennis
court,
which
is
then
contained
in
the
leisure
center.
Could
you
could
you
say
again?
Well
that's
the
difference
between
a
facility
use
and
individual
facility
years,
yeah
I'm
gonna
go
back,
I'm
gonna,
go
back
to
my
service,
I
mean
adjacent.
Is
there
a
difference?
B
Is
there
any
way
to
tell
whether
you
are
in
an
individual
or
it
would
be
I'd
need
to
change
this
example,
but
it'll
be
a
different
type
so
for
for
an
individual
one,
it
will
say
type
individual
facilities,
okay,
fine,
when
you're
harvesting
in
and
feed
or
you're
fetching
it
from
an
API.
You
will
be
able
to
clearly
distinguish
your.
B
Okay,
but
other
than
the
kind
of
the
change
having
different
type.
The
structure
of
the
products
in
terms
of
the
JSON
is
going
to
be
very
similar,
it'll
just
be
a
different
type
and
then
a
slightly
different
information
in
the
location
because
will
be
information
about
the
individual
facility,
so
the
court,
and
then
it
will
say
where
that
Court
is
located.
So
in
this
case
is
in
the
center.
B
So
Nick
and
I
had
a
bit
of
a
discussion
about
this
earlier
about
whether
you
know
pros
and
cons
of
kind
of
doing
it
in
this
way.
But
I
think
again
this
this
isn't
about
the
facility
proposal
for
say
this
is
something
that
we
use
exactly
the
same
structure
in
describing
event
locations.
So
if
we
want
to
rethink
that,
we
should
be
doing
that
as
a
kind
of
separate
separate
proposal,
rather
than
con
again
putting
any
blockers
in
our
way
of
moving
forward.
B
So
I
think
that
is
it
in
terms
of
like
the
examples
that
worth
highlighting
now,
because
there's
a
few
edits
I
need
to
put
into
them
kind
of
won't
show
the
year
this
yet,
but
I'm
really
I.
Think
based
on
the
you
know
that
they're
kind
of
reviewing
the
the
analysis
that
we've
done
before
reviewing
the
feedback
that
we've
had
there
are
only
some
relatively
minor,
amends
to
the
existing
draft
in
order
to
move
this
forward.
B
Specific
product
information
will
be
documenting
how
to
use
the
hours
available
property
from
schema.org
to
publish
opening
hours
information
and
then
changing
the
way
that
we
do
availability
so
that
we
more
closely
match
what
we're
doing
with
events
so
we'll
end
up
with
remaining
uses
and
maximum
uses,
rather
than
using
the
event
status,
property
which
we've
been
using
so
far.
So
it's
quite
small
changes
and
stuff
that
I
can
I
can
put
into
the
spec
pretty
quickly.
So.
B
Some
of
the
other
proposals
that
have
come
in
whilst
we've
been
discussing
facilities,
there's
quite
a
few
of
the
changes
that
people
are
requesting.
So
what
I'm
going
to
suggest
we
do
use
that
time
for
is
to
just
look
at
those
proposals
and
maybe
agree
some
priorities,
but
which
ones
to
tackle.
One
of
the
things
that
I'm
keen
for
us
to
do
is
to
make
some
changes
to
the
specification
to
be
a
bit
more
prescriptive
around
certain
ways.
Some
of
the
data
is
published
to
make
it
more
consistent
and
easier
to
validate.
B
So
we've
got
some
work.
That's
that
we've
started
around
creating
a
date
validated
tool
that
would
be
good
to
get
a
spec
updated
in
in
parallel
of
delivering
that
we're
going
to
be
looking
for
some
extra
help
to
do
some
of
the
technical
work
on
that,
so
there
will
be
I'll
circulate
the
list,
we're
going
to
be
looking
to
get
just
to
get
a
developer
or
a
couple
of
nodes
help
us
out
with
some
of
that
technical
word.
B
So
that's
in
terms
of
kind
of
next
steps,
the
only
thing
to
mention,
whilst
we've,
unless
you've
got
a
few
minutes
left
in
the
core,
is
we're
also
going
to
be
putting
up.
We've
got.
We've
been
working
on
a
new
developer
site
to
place
a
bit
more
detail
around
data
model,
documentation,
examples
bit
of
guidance
and
tutorials.
It's
still
a
work
in
progress,
but
if
you
want
to
take
a
look,
it's
a
developer,
open
active.
B
B
So
we
made
our
completely
what
we
are
doing
is
there
are
a
few
people
that
have
expressed
interest
in
moving
forward
with
the
activity
list.
So
what
we're
going
to
do
is
schedule
a
workshop
similar
to
what
we
did
with
to
kind
of
kick
start
the
booking
work
of
actually
getting
people
in
a
room
and
because
having
a
ability
to
have
kind
of
face-to-face
to
go
through
things
in
a
bit
more
detail.
I
think
will
help
us
progress
that
work.
The
actual
kind
of
technical
side
of
of
describing
activity
list
is,
is
already
in
place.
B
You
know
we
have
the
schemer
support
to
do
that.
What
needs
to
be
what
we
need
to
bottom
out
is
how
we
collaboratively
maintain
this
list
across
the
community,
which
is
a
slightly
different
kind
of
type
of
work
that
we've
been
doing
so
we're
gonna,
get
some
people
in
the
room
to
kind
of
to
schools,
discuss
how
that
that
will
we
move
that
forward?
B
A
Yeah
another
another
noticed,
as
is
in
here
be
time-
might
mention
this
earlier,
but
just
so
everyone's
on
the
call
and
everyone
active
will
be
implementing
the
way
of
the
specs
at
between
this
conversation
when,
when
these
are
enough
and
circulated
that
Tom
and
and
play
they're
gonna,
do
some
quick
updates
to
the
Gladstone
adapter
and
then
that's
going
to
go
in
to
have
an
active.
So
we
should
have
the
data
from
their
published.
According
to
this
spec,
we
did
a
quick
check
earlier
and
it
looks
like
yeah.
A
B
That's
great
yeah,
it
was
giving
general
updates
and
we
are
continuing
to
work
on
the
the
booking
specification.
So
the
the
developing,
the
team
Chris,
whose
basic
finished
of
initial
piece
of
work
around
the
developer
site,
is
now
starting
to
work
on
the
editors
draft
of
the
booking.
Spec.
There's
a
few
changes
that
we
need
to
put
in
that
to
make
sure
that
it's
it's
coherent
enough
to
then
be
able
to
bring
it
to
this
group
and
the
rest
of
the
community
to
start
having
a
few
more
detailed
technical
questions
around
it.
B
B
Well,
don't
forget
if
you,
if
you
do
have
any
questions
in
the
meantime,
then
feel
free
to
get
in
touch
with
neither
nickel
myself
or
you
know,
send
an
email
to
the
main
list.
So
we
can
have
a
discussion
if
you've
got
changes
proposed
changes
to
the
spec
there's
a
you
can
go
and
file
proposals
on
github.
We
start
to
kind
of
put
together
a
template
around
that
to
make
sure
that
we're
capturing
enough
detail
so
that
we
can
start
to
have
productive
conversations
on
github,
but
also
here
in
this
group
as
well.