►
From YouTube: OpenActive W3C Community Group Meeting / 2019-07-03
Description
Routes Use-Case Workshop Preparation
Call notes available at https://w3c.openactive.io/meetings/2019-07-03-routes-workshop-preparation
A
A
A
A
A
A
A
What
we're
tentatively
calling
roots,
1.0
and
2.0,
so
the
point
of
roots
1.0,
is
to
get
roots
data
published
in
a
kind
of
minimal,
viable
product
way,
with
the
idea
that
we'll
revisit
questions
at
the
end
of
this
calendar
year,
scoping
out
matters
in
more
detail
and
getting
a
more
fine-grained
perspective
on
roots.
There's
a
lot
of
questions
that
are
up
in
the
air
with
regard
to
the
technical
aspect
of
it.
So
the
idea
is
just
to
be
able
to
ground
it
and
what
people
are
actually
doing
with
the
roots.
Right
now,.
A
And
here
you
should
be
able
to
see
a
bunch
of
links
to
the
agenda.
The
user
story
templates
the
use
case
templates
and
the
data
model
in
progress,
a
point
on
nomenclature.
It
seems
as
though
for
the
standards
work
and
for
the
open
data
Institute
generally,
there
are,
as
far
as
I
can
tell
like
three
different
senses
of
the
word
use
case
for
chelating
right
now.
A
A
A
So
goals
a
clear,
concise
set
of
use
cases
for
the
first
route,
specification
and
initial
scoping
of
use
cases
for
the
second
iteration
of
food
specification
routes,
2.0
I
guess
my
first
point
would
be:
does
anybody
have
any
feedback
on
those
goals?
Do
you
think
there
should
be
any
goals
added
to
that,
or
should
there
be
some
modification
to
how
they're
framed
there.
A
A
Okay
I'll
take
I'll.
Take
silence,
is
a
good
sign
there.
So
then,
at
one
of
the
day
is
fairly
straightforward
introductions.
Of
course,
then,
moving
on
to
user
stories,
which
is
those
high-level
specifications,
I
talked
about,
and
that
really
is
basically
just
a
brainstorming
session.
It's
people
trying
to
think
of
everything
that
users
want
to
do
with
their
data.
I.
A
A
Because
there's
I
think
some
kind
of
market
differentiation
or
segment
differentiation
between
casual
users
between
very
serious
users
and
what
order
you
address
needs
in
so
once
we've
got
all
the
user
stories
down
the
question
of
which
ones
we
need
to
address
now
and
which
ones
we
can
leave
for
the
future.
I
think
it's
going
to
be
the
harder
part
of
that
work.
A
Then,
once
we've
done
that
filtration
work
and
worked
out
which
stories
we
need
to
address
most
urgently,
we'll
spend
essentially
the
remainder
of
the
day,
breaking
that
down
into
finer
grained
detail
of
what
we
actually
need
to
do
in
order
to
support
those
user
stories.
That's
the
use
cases,
part
I'm,
hoping
that
we'll
take
no
more
than
an
hour
and
15
minutes.
I
think
that
might
be
a
little
bit
optimistic,
but
you
know
the
day
is:
is
scheduled
to
end.
A
A
A
There's
a
whole
bunch
of
different
ways
that
you
can
do
this
and
I
understand
that
in
software
design,
of
course,
there's
a
lot
of
argumentation
about
which
particular
form
of
words
you
use
to
describe
a
user
story.
So
I've
listed
out
some
examples
on
this
document.
You
know
as
an
X
second
Y,
so
that
I
said
in
order
to
X
I
Y
I
can
Z
this
kind
of
thing.
A
I've
never
seen
anyone
attempt
this
before.
Actually
I
haven't
seen
any
explicit
acknowledgment
that,
in
fact
the
form
of
words
doesn't
matter
very
much.
Does
anyone
have
any
particular
feedback
on
this
way
of
doing
things?
I
think
user
stories
are
quite
widely
employed
in
different
ways
and
I'd
be
curious
to
know
whether
anybody
on
the
call
has
got
any
particularly
strong
objections
or
advocacy
for
any
one
particular
way
of
doing
this.
A
A
Getting
the
more
specific
requirements
out
of
that
and
breaking
them
down
I
think
is
a
little
bit
difficult
in
software
design.
There's
a
lot
of
methodologies
for
how
you
do
that
I
think
our
task
is
probably
a
little
bit
easier,
in
fact,
because
we
don't
actually
need
to
build
an
application
which
is
fantastic
and
then
so
that
means
we
don't
have
to
worry
too
much
about
things
like
application
flow.
You
know
when
user
Z
does
X
what
Y
follows,
what
sequence,
etc,
etc.
A
A
A
It's
just
three
three
cells
along
the
top
information
need
supported
by
which
attribute
in
the
data
model.
If
any,
what
kind
of
value
you
think
would
go
into
the
attribute
and
any
notes
that
anybody
might
have
so
to
take
a
look
at
an
example
here,
as
a
parent
of
young
children,
I
can
find
fun,
easy
trails
that
we
can
all
participate.
So
that's
the
user
story.
A
A
Things
get
a
little
more
problematic
with
the
difficulty
of
the
trail,
which
is
certainly
something
that
you
want
to
know
if
you're
the
parent
of
a
young
child,
but
what's
meant
by
that,
could
be
a
little
bit
more
nuanced
than
something
like
length.
So
you
might
be
thinking
of
the
grade.
How
steep
the
trail
is.
You
might
also
be
thinking
of
whether
it's
muddy,
whether
there's
narrow
bridges.
B
A
Have
to
be
crossed,
you
know
how
much
agility
you
have
to
have
in
order
to
get
through
the
trail
are
their
child
from
these
features
nearby
changing
rooms,
that
kind
of
thing
other
scheduled
child
activities
so
on
and
so
forth.
So
it's
fairly
freeform
and
I
think
fairly
intuitive
to
go
through
this
way.
A
The
supported
by
attribute
field
I'm,
getting
from
a
little
summary
spreadsheet,
I
made,
which
is
just
summarizing
in
its
sparest
possible
form.
Lee's
original
proposal
for
how
routes
were
to
be
described.
Some
of
the
additional
suggestions
that
have
made
been
made
since
then,
and
that's
it
and
actually
in
some
cases
it's
not
entirely
clear
what
the
semantics
of
those
attributes
would
be.
So
I've
made
a
couple
of
descriptions
or
examples
of
values
that
might
slot
in
there,
and
that
is
basically
that
we
spend
some
time
breaking
down
the
use
cases.
A
We
take
a
check
to
make
sure
that
we've
got
everything
covered
as
much
as
best.
We
can
I
write
up
the
results
of
the
meeting
and
then
I
draft
a
specification
that
supports
the
use
cases
of
the
user
stories
that
we've
selected
as
important
to
address
at
the
moment
and
I
certainly
dissolve
pretty
quickly.
So
by
the
end
of
July
I'm,
aiming
to
have
the
first
draft
specification
out
and
ready
for
comment
and
by
the
end
of
August.
B
A
A
I'm
not
sure
how
much
we
want
to
encode
that
distinction
or
where
we
want
to
include
that
distinction
and
so
I'm,
hoping
that
getting
a
kind
of
pragmatic
sear
on
that
will
help
make
that
decision
easier.
Basically,
okay,
thanks
I,
do
you
have
do
you
have
thoughts
or
nothing
you'd
like
to
share,
or
are
you
happy
to
review
later.
B
My
personal
preference
would
be
it'd,
be
separated
out
and
then
maybe
there'd
be
an
attribute
in
the
in
the
model
to
point
to
that
end,
point
of
that
particular
route,
something
like
that.
That
would
be
great
because
then
you
could
basically
mash
up
a
lot
of
different
routes
to
create
bigger
routes
as
well
or
you
know
more
complexed
or
varying
routes
for
difficulty
or
urban
versus
rural.
That
sort
of
thing.
B
I'd
be
pointed
to
the
to
the
root
the
root
object,
or
you
know
the
so
you've
got
the
specification
which
outlines
what
the
what
the
template
is
or
what
the
class
is
and
then
you'll
earn
your
love
an
instantiation
or
they
won't
Excel.
Actually
that
particular
route
will
live
at
an
end
point
which
you
can
link
quickly
easily
reference.
Okay,.
B
So
you
could
have
I
guess,
excuse
me
an
opportunity
model
event
which
actually
points
to
a
couple
of
different
routes,
because
it
crosses
or
is
it's
I
suppose
American
is,
is
a
might
be
one
or
am
trying
to
think
of
the
is
there's
a
room
that
happens
every
year
from
I,
think
London
or
every
two
years
down
from
London
to
Brighton
and
it's
over
two
days.
It
has
a
number
of
different
routes
that
you
can
take
there.
B
So
you
can,
you
know
mash
those
mash
those
together
but
or
you
might
I
suppose
a
what's
the
other
one
like
an
iron
mine
or
a
triathlon.
You
might
have
different
routes,
they
could
take
there
as
well.
So
there
might
be
an
event,
but
it
can
point
to
the
different
parts
of
the
routes.
So
people
can
get
an
understanding
of
how
that
part
of
the
reach
will
be
formed.
You
know,
will
it
be
get
caught?
Will
it
be
hard?
B
A
B
B
A
Yeah
yeah
I
mean
as
I
say
it
was
it's
really
about
getting
the
user
stories
to
maybe
guide
some
of
those
decisions.
It's
not
gonna
give
us
complete
guide
so
yeah
how
you?
How
do
you
compose
one
route
out
of
multiple,
smaller
parts
of
a
route
is
probably
something
that
this
isn't
going
to
address?
May
give
us
a
sense
of
priority
about
whether
we
do
this
now
or
what
five
or
six
months
time
but
yeah.
We
can
certainly
review
that
in
light
of
what
we
need
to
do
right
now
could.
D
I
give
another
use
case
absolutely
so
that
is
very
much
there's
an
array
of
routing
data
and
opportunity
data
and
any
given
upset
of
opportunity
data
can
reference
a
bunch
of
route
data,
possibly
mixing
and
matching
in
different
ways.
The
counter
example
I've
got
is,
if
there's
a
route
which
is
which
has
events
on
at
certain
times,
so
it
might
be
very
busy.
For
example,
if
there's
runners
or
cyclists
on
some
route,
you
might
actually
want
to
know
when
the
route
is
best
available
to
avoid
those
times.
D
A
A
Yeah,
you
I,
don't
think
you'd
ever
want
to
get
those
two
things
absolutely
separated.
You
have
to
be
able
to
link
between
them
yeah
and
that's
I,
the
question
of
scheduling
and
avoiding
times
a
little
when
things
will
be
just
absolutely
unusually
busy.
I
think
that's
already
come
up
on
the
issue.
Hasn't
it
want
to
wait,
but
so,
if
you
could
well,
you
were
going
to
be
attending
the
the
workshop
tomorrow.
Weren't
you
yes
very
much
so
right
so
yeah.
A
A
A
Unrelated
there,
okay,
so
yes,
if
you
could,
if
you
could
bring
that
use
case
up
again
or
the
users
yeah
set
of
requirements
up
again
tomorrow,
that
would
be
that
would
be
hopeful
yeah
and
it's.
It
is
sometimes
nice
I
think
to
to
do
this
as
a
user
story,
so
it's
kind
of,
as
you
know,
as
a
participant
in
running
group,
or
something
like
that:
I
want
to
access
a
trial
at
a
time,
that's
not
particularly
being
used,
etc,
etc.
A
Yeah.
We
can
certainly
flesh
that
flesh
that
out
in
more
detail
you
the
other
point
that
I
would
make.
Also
given
that
were,
this
is
actually
something
that's
happening.
Tomorrow
is
I've
made
the
data
model
in
progress
document
that
spreadsheet
listing
out
the
attributes
that
have
been
proposed
so
far,
I've
made
that
editable
by
everybody.
A
So
if
you
want
to
jump
on
that
and
you've
got
a
bee
in
your
bonnet
or
something
you
just
think
would
be
a
particularly
good
idea,
you'd
like
to
see
it
for
fronted
tomorrow,
just
hop
in
that
document
and
add
it
there
and
it
will
definitely
come
up.
I
will
be
updating
the
github
issue
with
everything
that
happens
at
the
workshop
tomorrow
into
horse,
it's
relevant
to
that
particular
thread,
but
just
indicate
that
you
want
to
flag
something
up
for
tomorrow.
The
data
model
in
progress
document
is
a
good
place
to
do
that.
A
B
A
I
think
I
would
just
actually
added
it.
Then
it
is
a
couple
of
tables
and
one
of
them
labeled
like
original
suggestion,
or
something
like
that.
Yeah
yeah-
additional,
if
you
just
keep
on
adding
to
the
additional
with
whatever
you
think,
is
appropriate
that'll,
be
fine,
they're,
very
they're,
very
much
working
documents.
You
know
this
is
this,
isn't
intended
to
just
be
dressed
for
the
mill?
So
whatever
you
do,
there
is
just
going
to
be:
okay,
okay,.
B
A
A
But
that
was
more
of
an
intuition
than
anything
else.
So
I
talked
to
Izzy
at
Sport
England
and
put
out
an
open
call
on
the
mailing
list
about
market
research
or
market
conceptualizations
that
we
have-
and
it
seems
like
the
most
influential
document
in
that
area-
is
something
called
getting
active
outdoors,
which
Sport
England
worked
with
the
outdoor
industries
association
on.
So
that
gives
a
fairly
fine-grained
of
market
segmentation,
I.
Think
of
eight
groups
that
it
looks
out
there
and
also
looks
at
people
who
fall
out
all
fall
out
of
those
groups.
A
The
people
who
are
not
that
active
or
prevented
from
or
do
not
have
the
motivation
to
get
active
outdoors
and
those
questions
are
delved
into
in
a
little
more
detail
in
the
report
that
I've
linked
to
here
them.
The
annual
monitor
of
engagement
with
an
actual
environment
that
the
government
Commission's.
A
I
think
it
would
be
useful
when
we're
looking
at
user
stories
to
think
about
which
group
of
people
were
catering
for
just
to
make
sure
that
we've
got
pretty
good
coverage,
that
the
groups
of
people
listed
in
the
getting
active
out
for
segmentation
are
quite
diverse
and
I.
Don't
think
we
have
to
cater
to
everybody,
but
I
think
if
we
find
that
there's
some
particular
group
of
people
Fortin
we're
not
catering.
We
need
to
be
aware
of
of
why
we're
not
doing
that,
and
the
answer
could
be.
They
already
have
all
the
information
they.
A
A
So
it's
worth
looking
at
the.
Why
not
sections,
and
the
impediments
and
barriers
section
of
the
monitor
of
engagement,
to
make
sure
that
the
user
stories
and
use
cases
that
were
coming
up
with
address
some
of
the
issues
that
are
flagged
up
there,
because
there's
no
Mis,
there's
some
value
of
us
in
us
addressing
the
needs
of
people
who
are
already
quite
active,
but
that's
not
where
the
clearest
big
wins
live.
So
it'd
be
helpful.
A
If
you
could
review
that
and
there'll
be
some
time
to
review
that
tomorrow
at
the
meeting
are
there
any
other
documents,
I
should
be
adding
to
that
list.
I
didn't
I
got
a
couple
of
emails
from
people
who
said
they've
got
some
materials
that
aren't
in
the
public.
Are
publicly
disclosable,
unfortunately,
but
I
couldn't
find.
C
A
A
Okay
and
that's
that's
about
it
for
the
agenda
tomorrow
as
I
say
all
the
outputs
will
be
published
and
available
for
comment.
We
will
be
cracking
on
pretty
fast,
so
the
the
window
for
getting
comments
on
outputs
is
going
to
be
pretty
small,
but
yeah
I'll
get
them
out
there
just
as
soon
as
I
as
I
can,
after
the
outcome
of
the
meetings.
A
So,
there's
just
one
other
slight
point
that
I
just
would
have
flag
up
for
attention.
It's
nothing
urgent,
but
the
difficulty
level,
a
discussion
we've
it
has
been
rumbling
along
for
the
last
month
or
so
how
it
relates
to
roots
is
kind
of
an
interesting
question.
A
difficult
route
is
not
quite
the
same
thing,
perhaps
as
a
difficult
physical
activity.
A
So
if
you've
got
any
thoughts
on
that
and
how
you
would
prefer
to
see
roots
address,
difficulty
level,
add
them
onto
issue
either
under
the
roots
issue
or
on
to
the
difficulty
level
issue.
That's
that's
issue
82,
just
to
get
your
thoughts
out
there,
because
that
will
get
folded
into
the
spec
over
the
course
of
the
next
month.