►
From YouTube: OpenActive W3C Community Call / 2020-07-01
Description
The Opportunity API
- Opportunity API original proposal summary 2018
- Initial Implementation
A
There
we
go.
Can
everyone
see
the
slides,
yep?
Okay,
great
so
back
in
about
2018,
nick
and
lee
started
developing
together
the
opportunity
api?
So
this
was
a
specification
for
an
api
that
would
allow
people
to
query
for
particular
bits
of
data
rather
than
using
the
rpde
harvesting
method,
which
is
currently
the
only
way
to
really
publish
opportunity.
Data
right
now.
A
A
So
it's
difficult
for
the
consumer
to
consume
harvesting
harvested
data
simply
because
you
need
to
download
everything
then
query
it,
but
the
trade-off
is
that
it's
very
easy
for
the
publisher
and
we
talked
a
little
bit
in
the
last
call
about
the
rpde
specification
and
just
how
easy
it
made
it
to
publish
our
pde
feeds,
because
everything
could
be
cached
in
a
very
lightweight
and
effective
way,
but
simultaneously.
That
makes
the
rpd
method
of
publishing
a
little
bit
inflexible
in
that.
Obviously,
if
you're
going
to
cache
it,
it
can't
change
very
much.
A
So
it
doesn't
support
advanced
querying
slicing
of
the
data
set
in
various
ways
very
very
well,
but
it
does
make
it
easy
to
maintain
a
publishing
framework.
The
difficulty,
I
think
is
while
we've
got
opportunity,
publishers
on
board
in
reasonable
numbers,
consumption
has
been
tricky,
and
I
ran
into
this
myself.
Working
on
harvesting,
where
consuming
the
entire
ecosystem
of
publishing
is
extremely
heavyweight.
A
A
A
And
then
there's
also
the
fact
that
we'll
be
getting
a
feed
normalization
service
delivered
in
the
first
couple
of
weeks
of
august.
So
what
this
work
is
if
people
aren't
familiar
is
open.
Data
services
are
currently
building
a
harvester
that
goes
around
to
all
of
the
sites
listed
on
the
status,
page
harvests
it
and
then
republishes
it
in
a
normalized
form,
which
basically
means
flattening
the
various
hierarchies
that
are
used
to
represent
the
data
into
into
a
flat
representation.
A
A
A
A
Filtering
kind
of
querying
sorting,
so
it's
basically
just
ways
of
getting
out
the
data
and
presenting
it
in
in
different
ways:
partial
responses,
that's
an
issue
for
not
getting
complete
opportunity
records,
but
just
the
fields
that
you
particularly
want
to
keep
the
bandwidth
minimal.
But
it's
basically
it's
a
search
api.
A
A
I
think
yeah.
I
think
that
was
fine.
I
mean,
I
suppose
the
question
is
under
the
rubric
of
requirements
that
are
bits
of
a
range
of
responses
from
infinite
requirements
to
actually
there
is
no
requirement
so
so
shoot
well.
Actually,
if
you,
if
you
could
first
answer
the
question
as
asked,
which
is
you
know,
is:
is
this
basically
a
search
api,
that's
being
described
here
or
is
it
just
that
this
is
a
partial
representation
of
of
envisaged
functionality.
C
I
guess
both
the
the
the
so
so
I
guess
maybe
maybe
it's
helpful
to
start
with
background
that
could
be
useful
here.
What
where
this
repository
came
from
what
was
going
on
and
then
maybe
into
the
kind
of
now
it
might
be
a
nice
flow.
So
the
opportunity
api,
as
described
here,
started
out
life
as
a
as
an
idea
that
we
would
in
order
to
get
booking
and
other
things
working.
C
We
would
need
to
have
a
way
of
interrogating
in
real
time
some
of
the
opportunities
in
the
in
in
the
database
in
a
way
that
wasn't
using
harvesting
as
the
booking
spec
evolved.
It
became
clear
that
this
wasn't
a
requirement.
This
wasn't
a
prerequisite
for
booking,
so
we
could
get
away
without
this
building
block
if
you
like,
and
we
could
move
straight
to
booking
previous
versions
of
the
booking
spec
before
1.0.
C
That
will
have
to
start
the
beginning
of
that
cycle.
So
I
guess
that's
that's
where
it
came
from,
and
I
suppose
it's
the
other.
The
other
thing
to
to
note
is
that
this
didn't
come
from.
It
definitely
didn't
come
from
anything
to
do
with
helping
data
consumers
to
do
what
they
need
to
do
for
the
ecosystem
better.
So
this
this
this
is
not
designed
as
a
way
of
making
harvesting
easier
or
solving
the
harvesting
problem.
C
I
think
it's
really
really
important
to
know
and
like
properly
crystallize,
that
the
reason
that
harvesting
is
the
way
this
works
is
because
it
needs
to
work
that
way,
and
I
think,
if
we
don't
have
that
clearly
agreed,
then
as
a
just
on
a
technical
level.
I
think
the
thing
to
probably
should
do
is:
go
back
to
first
principles,
get
a
whiteboard
and
look
at.
C
Why
harvesting
has
to
exist
and
is,
is
by
far
the
easiest
way
for
the
whole
ecosystem,
consumers
and
and
providers
not
just
for
providers
and,
and
that
has
to
do
with
scaling.
It
has
to
do
with
how
open
source
sorry
open.
Open
data
works
not
needing
to
have
api
keys,
reducing
the
various
entry
for
the
ecosystem,
a
whole
bunch
of
stuff
around
around
that
and
the
the
way
that
the
harvesting
allows
you
to
do
some
of
the
things
that
you
know
taking
subsets
of
the
data
and
everything
else
using
built-in
filtering.
C
You
know
the
big
systems
have
barely
implemented.
What
we
already
have
and
the
small
systems
can
barely
afford
to
implement
what
we've
already
asked
them
to
implement,
and
so
with
with
it.
That
being
that
that
the
case
that
actually
it
then
is
really
important
to
minimize
the
amount
of
time
and
effort
and
cost
on
those
systems
and
also
with
the
point
last
week
that
was
made,
I
think,
is
really
important
to
highlight
again.
C
And
so
I
think
I
think,
there's
basically
my
suggestion
here
is
that
I
think
there's
a
really
strong
technical
case
to
be
made
for
why
harvesting
is
the
best
approach
for
the
ecosystem
overall
for
consumers
for
providers
for
everyone?
I
think
that
may
be
somewhere
to
start
with.
So
we
know
what
kind
of
problems
we're
solving
with
this,
and
I
think
the
thing.
The
reason
that's
important
to
understand
is
because
I
think,
a
really
bad
a
danger
here.
C
I
really
see
a
danger
is
if
we
create
this
specification
and
start
promoting
it
to
people
alongside
the
existing
specifications
and
give
them
more
work
to
do.
I
think
we're
going
to
have
a
real
there's,
a
real
risk
here,
that
we
undermine
our
efforts
to
get
uptake
of
booking
to
get
conformance
to
the
modeling
spec,
because
we'll
be
busy
telling
everyone
to
implement
another
api.
C
When
I
actually
just
don't
think
the
demand
from
consumers
is
there,
I
think
it
it's
technically
a
nice
idea,
but
when
you
get
into
the
which
consumers
and
like
let's
name
them
and
talk
about
them,
actually
want
this
and
they
and
they've
got
challenges
with
the
harvesting
model.
And
then
let's
talk
to
those
consumers
and
say
what
are
your
challenges
because
all
the
I
mean
the
harvesting
model
is
old
enough.
Now
that
we've
got
most
of
those
problems
solved,
and
so
it
really
is,
I
think,
a
case
of
looking
at
the
real
reason.
C
We
need
this
and
so
from
an
ecosystem
perspective,
just
to
separate
this
out
from
ecosystem
perspective.
I
don't
think
this
is
needed.
I
don't
think
this
helps
us
move
anything
forward
at
all,
however,
from
having
a
good
open
source
harvester's
point
of
view,
which
is
what
we're
focused
on,
obviously
in
the
short
term,
building
that
I
think
there's
a
huge
value
in
having
a
well-defined
api.
That's
standardized
because
it's
open
source
and
it
might
as
well
use
something
that
is
standardized.
C
And
so
I
think,
if
we
can
create
this
api
with
the
harvester
really
in
mind
and
obviously
more
general
thinking
around
it
as
well,
but
that
that
being
what
it's
really
its
primary
purposes
for
and
then
crucially,
having
got
that
far.
Maybe
we
stop
at
beta
because
it's
not
worth
investing
a
huge
amount
of
energy
and
getting
the
whole
ecosystem
and
having
another
massive
meeting
with
90
people
in
it
to
try
and
get
full
consensus
on
a
new
spec,
because
that's
massive
and
open
active
hasn't
published
a
brand
new
spec
in
years.
C
So,
rather
than
going
through
all
of
that
massive
effort
for
the
sake
of
a
very
small
open
source
bit
of
software,
I
think
focusing
ourselves
on.
Let's
create
this
as
a
kind
of
beta
thing
or
whatever.
It
is
like
rough
thing
that
we
can
do
for
that
open
source
bit
of
software
to
make
that
as
useful
as
possible,
and
then,
let's
definitely
not
try
and
push
uptake
on
this
downstream
to
all
of
those
providers
who
have
barely
implemented
the
things
we've
already
given
them
like
that,
would
completely
squash
progress
today.
I
think
so.
C
If
we
can
separate
this
out
and
really
focus
on
the
short-term
objectives
of
the
harvester,
I
think,
rather
than
getting
too
caught
up
and
risk
the
ecosystem
over
having
a
much
bigger
thing
here.
That
might
distract
everybody,
especially
when
people
like
david,
everyone
active,
are
saying
these
specs
people
just
want
to
pile
in
on
the
ad
features
all
over
the
place.
That's
just
on
the
booking
spec,
let
alone
a
whole
new
spec
people
are
getting
to
the
point
with
us
now
they're
like
come
on
open
active.
C
If
we're
going
to
be
forced
to
implement
all
this
stuff,
there
needs
to
be
a
limit
to
this,
so
I
think
if
you've
got,
if
we
wanted
to
get
consensus
on
a
new
api
and
you've
got
all
90
people
in
the
room,
I
think
you
get
unanimous.
No,
let's
stop
this
crazy
stuff,
like
we
can't
put
any
more
in
contracts.
That's
too
much.
We've
barely
got
what
we've
already
got
there,
so
I
just
I
just
rhythm,
don't
think
we're
gonna
get
consensus
on
a
new
api
or
anything
like
that
from
the
whole
community.
C
A
That
yeah,
I
think,
yeah.
The
purpose
of
this
is
to
have
some
kind
of
sustainable
interface
to
the
harvester
as
it
exists,
and
one
that's
easy
to
scaffold
up
into
some
kind
of
specification
in
future.
So
the
intention
was
not:
let's
get
an
api
ready
by
march
2021.
That
would
be
much
much
too
much
work,
but
I
think
it
is
possible
to
get
a
workable
beta.
A
And
I
think
it
would
be
useful
to
consult
groups
like
this
in
order
to
make
sure
that
that
beta
is
as
useful
as
possible.
No,
I
wasn't.
I
wasn't
seeing
this
as
like:
let's
change
the
entire
ecosystem.
That
said,
I
think
I
want
to
have
something
that
can
be
plausibly
implemented
by
publishing
organizations
as
well
as
well
as
causally
consumed,
without
necessarily
having
it
ratified.
As
a
as
a
specification.
C
C
If
this
is
a
technical
thing,
then
100
behind
you,
you
definitely
need
to
make
sure
we've
thought
all
the
angles
through,
because
that's
the
point
of
making
a
generic
specification
whatever
it's
for,
but
just
like
really
clearly
delineating
that
from
strategy
and
this
becoming
any
massive
strategic
pillar
of
anything
that
we're
doing,
because
I
think
that's
where
we
kind
of
run
into
things.
Yeah
I
mean
I
would
like
to
see.
A
A
I
think,
there's
a
problem
that
developers,
I
think,
tend
to
assume.
There's
an
api.
You
know,
leaving
aside
rpd
being
an
api,
the
assumption
of
developers
going
in
is
that
there
will
be
something
that
looks
like
an
api
and
there
there
isn't
one
and
therefore
you
then
have
to
get
into
a
rationale,
conversation
about
why
there's
no
one
and
so
on
and
so
forth.
So
I
think
I
think
it
likely
hold
on
here.
A
D
A
C
C
I
just
I
think
I
think
it's
really
important
to
dig
into
those
assumptions,
because
I
think
each
one
of
those,
I
think,
there's
a
good
debate
to
be
had
about
those
things
like
developers,
finding
it
not
intuitive
that
there's
no
api.
You
know
things
like
that.
It
makes
data
exploration,
difficult
or
things
like
that.
C
There's
kind
of
limitations
imposed
by
it.
I
suppose,
because
I
I
guess,
having
worked
with
different
developers
on
this,
I
I
totally
understand
that
they're
saying
where's
the
api,
the
reason
they're
saying
where's
the
api
is
often
because
they
don't
understand
this
ecosystem
they're
plugging
into
it's
not
like
there's
not
like
a
single
interface.
They
can
connect
to
the
whole
of
open
active
because
we're
talking
about
an
entire
industry's
worth
of
data,
and
so
a
lot
of
people
come
into
this
and
think.
Oh,
the
open,
active
app,
it's
a
platform.
C
Isn't
it
you
guys
are
a
platform?
Well,
obviously,
it's
it's
not
a
platform
and
that
I
guess
is
fundamentally
what
it
what
it
isn't.
Obviously,
the
with
the
the
great
harvester
tool
we
have
that
will
make
it
easier
to
access
it
like
it's
a
platform
and
that's
where
you
can
say:
oh
there's
an
open
source
tool.
You
can
use
like
an
api
if
you
want
one,
but
I
think
that's
quite
different
from
saying
so
there's
an
api
option.
You
can
plug
this
tool
in
if
you
need
it.
C
That's
quite
different
from
saying,
like
you
know,
let's
change
the
the
structure
like
totally
changed
the
structure
or
even
you
know
that
whole
strategic
pillar
idea,
I
guess,
is
the
is
the
thing
it
doesn't.
I
think
that's
where.
Maybe
that's
that's,
like
a
point
of
of
like
something
to
kind
of
really
understand
where
those
assumptions
are
coming
from
this
leading
to
it
becoming
a
pillar,
because
I
just
think
I
think
if
we
really
went
through,
we
could
literally
name
all
the
organizations
we've
spoken
to
and
exactly
what
their
issues
are.
A
I
think
I
think
we're
agreeing
with
each
other
again
in
a
way,
I
think
we're
looking
at
two
different
sides
of
one
coin
in
that
I
think
you're
right
that
once
you
talk
developers
through
the
ecosystem
idea,
the
fact
that
we're
not
a
platform,
the
fact
that
it's
an
ecosystem
change
the
need
for
a
harvester
becomes
apparent.
I
think
the
difficulty
is
that
that
funnel
gets
quite
narrow,
the
more
the
longer
that
conversation
has
to
go
on
that,
I
think
everyone
we
engage
with
and
everyone.
C
That
might
be
a
good
assumption
to
test
sorry.
That
might
be
a
good
assumption
to
test,
because
I
think
I
think,
though,
my
reading
on
this
and
and
from
the
discussions
I've
had
as
well.
I
think
it's
the
case
that
it
is
complicated
and
people
do
go
well.
I've
got
to
integrate
with
the
whole
ecosystem,
that's
complicated,
but
I
think
it
doesn't
matter
if
it's
an
api
or
a
whatever.
If
you've
got
30
endpoints
to
integrate
with
of
any
type
that's
going
to
be
complicated,
then
it's
going
to
put
people
off.
C
A
So
yes,
if
what
you're
trying
to
do
is
harvest,
then
a
harvesting
model
makes
perfect
sense.
If
what
you're
not
trying
to
do
is
harvest.
If
you
want
to
integrate
with
a
small
number
of
publishers,
if
what
you're
not
trying
to
do
is
harvest
and
what
you
want
to
do
is
simply
integrate,
then
a
harvester
model
doesn't
make
sense
and
right
now
we
only
support
one.
C
Of
those,
so
I
guess
my
question
is
which,
like
what
concrete
example,
do
we
have
of
a
publisher
that
when
really
they
get
into
the
detail
of
this
decide,
they
only
want
to
consume
one
or
two
feeds,
because,
generally,
even
with
a
sport,
that's
got
one
main
feed
like
running.
Those
things
exist
in
our
parks
exist
in
like
a
number
of
other
feeds,
because
a
good
good
gym.
So
every
sport
we've
got
like
whatever
way
you
slice
the
data.
C
If
you
want
it
geographically,
if
you
want
to
buy
sport
because
of
the
diversity
of
the
ecosystem,
you
you
always
end
up
with
more
than
one
feed
from
every
use
case.
I've
seen
I
just
I
guess,
I'm
really
interested
in
like
where's
the
what's
the
concrete
like
I
just
want
to
integrate
with
one
system
example.
I.
D
Think
it's
not
that
from
what
I've
heard,
at
least
from
people
it's
not
that
they
necessarily
only
want
one
feed.
Also,
sorry,
my
teams
is
going
crazy,
so
there's
gonna
be
like
loads
of
pinging
notifications,
but
it's
more
a
case
of
not
knowing
what
might
be
in
those
feeds.
I
think
that's,
maybe
something,
and
maybe
that
that's
where
I
maybe
I
might
be
coming
at
this
from
a
completely
different
incorrect
angle,.
C
Yeah,
so
I
think
that's
very
fair
and
that's
a
completely,
I
think,
that's
a
totally
different
thing,
and
I
know
that
there's
plans
to
sort
the
harvester
solves
that
and
also
that
the
idea
we've
got
about
a
dashboard
with
all
the
data
on
it
can
solve
that.
Those
things
are
about
surfacing
the
information
a
bit
more.
Clearly,
if
you
like,
so
it's
like
the
difference
between
changing
the
way
that
we're
showing
the
map
of
the
roads
and
changing
the
roads
themselves,
because
the
the
infrastructure,
which
is
the
data
from
structure,
is
the
roads.
C
That's
what
we've
built
with
the
harvesting
model.
We've
got
those
roads
in
place,
obviously
they're
expensive
to
build
they've
taken
a
long
time
to
lay
down.
Maybe
people
can't
see
all
the
roads,
we
need
a
better
map
and
that's
what
you
know
having
this
kpi
dashboard
will
be
great,
there's
a
map
you
can
go
to
that
road
or
this
road
and
that
one
goes
faster
than
that
one
goes
slower.
But
at
this
point
saying
actually
we
don't
want
roads.
C
We
want
tunnels,
let's
dig
everything
up
and
like
do
the
tunnels
instead
or
even
put
tunnels
underneath
the
roads,
it's
well,
you
can
get
there
by
the
roads
anyway,
and
no
one
that
I've
seen
has
said
the
roads.
Don't
work
for
me
because
I
you
know
it's
it's
because,
because
when
you
get
into
the
detail
of
it,
that's
what
they
need.
I
suppose
that's
that's
the
difference.
Do
you
know
what
I
mean
sure
I
mean.
A
I
think
again
it's
about
how
you
filter
different
conversations.
So
you
know
I've
had
a
fair
number
of
discussions
that
are
like
yeah.
Maybe
I
want
to
integrate
with
more
than
one
feed,
but
I
only
am
interested
in
badminton
out
of
those
feeds.
What's
the
harvester
way
of
going
about
that?
Well,
I
page
through
all
of
the
data,
and
I
write
a
filter
that
that
says
not
badminton,
throw
it
away,
badminton
keep
it
and
if
I'm
trying
to
harvest
a
gll
feed,
let's
do
this
for
36.
C
To
48
hours:
well,
that's
that's
different,
because
the
gll
feed
has
got
all
of
time
in
it
and
there's
another
problem.
We
have
with
the
feeds
which
is
being
addressed
and
was
talked
about
in
the
last
call,
which
is
making
sure
you
can
only
extract
useful
information
from
the
next
right,
temporally
right,
yeah,
right,
temporary
and,
and
that
I
think,
totally
agree
with
that
problem.
That
definitely
can
be
solved.
But
I
don't
again
know
that
that
needs
to
be
digging
up
the
roads.
You
said
I
mean,
I
think,
that's
that's.
A
Equally,
I
think,
there's
a
fair
number
of
organizations
that
would
be
interested
in
essentially
integrating
with
their
own
systems,
but
in
an
open
way.
So
you
can
say
you
know
I
am
publishing
all
of
gll's
data.
I
would
also
like
to
write
a
little
app
that
only
harvests
gll's
data,
so
at
the
same
time
that
the
data
is
out
there,
the
ecosystem.
I
want
just
my
particular
organization
to
be
represented
via
an
app
or
something
like
that
again,
the
harvesting
model.
C
Right
well,
so
I
think
I
think
this
is
a
okay,
so
if
we
really
get
into
that
use
case,
so
that
is
okay,
that's
a
good
use
case,
so
there's
gll,
who
might
want
to
integrate
with
only
gll
and
use
their
own
data
right
if
sys,
so
that
requirement
has
been
there
for
a
very
long
time
and
for
those
systems
that
have
that
requirement,
because
their
customers
have
that
requirement.
They
already
have
their
own
apis
that
are
built.
C
People
have
integrations
against
those
apis
and,
I
suppose,
most
importantly,
there's
very
little
value
in
standards
when
you're
only
integrating
with
one
endpoint.
So
if
gll
is
only
integrating
with
gll,
what
value
is
there
in
legend,
rewriting
that
api
to
match
a
standard,
because
the
only
one
integrator
that
connects
to
them
doesn't
need
to
see
anything
different?
Oh
because
this
is
part
of
the
value
of.
A
There's
actually
a
huge
value
to
that
and
in
conversations
about
booking.
In
fact,
this
comes
up
quite
a
bit
that
organizations
that
are
already
themselves
amalgamating
information
from
a
number
of
parties
have
got
a
messy
internal
data
harvesting
setup
and
are
grateful
that
there
is
a
model
already
published
that
they
can
use.
A
So
if
you've
got
a
messy
internal
kind
of
booking,
engineered
infrastructure
and
you're
already
integrating
with
four
or
five
different
people
using
four
or
five
slightly
different
bookings,
but
de
facto
specifications
that
evolved
over
time.
It's
actually
tremendously
helpful
to
be
given
a
unified
pattern
for
dealing
with
this
that
the
the
standard
aspect
is
actually
valuable
to
organizations
because
it's
a
standard
and
it
gives
them
a
template
to
work
against.
C
Suppose
it
comes
back
to
you
know
who
who's
asking
for
what
are
the
use
cases
and
and
ultimately,
how
does
it
get
more
people
active
because
I
totally
get
there's
an
argument
for
standards
are
good
because
they're
well
designed
if
you
have
a
standard
for
something
it
probably
means
that
people
have
thought
it
through
and
plugging.
And
you
know
if
you
obviously
we're
we're
standard
geeks
on
the
score
right.
We
love
standards,
so
we
went
around
and
said:
what
can
we
standardize
in
the
technical
infrastructure
of
the
sport
ecosystem?
C
Is
it
our
job
to
help
those
organizations
are
doing
those
internal
integrations,
and
is
it
part
of
our
message
and
is
it
part
of
our
you
know
the
things
that
were
pushing
through
in
in
the
contract
et
cetera,
to
try
to
get
those
things
to
happen
because,
like
I
can
see
what
I
can
see
that
there's
I
get
basically
the
challenge
I
have
is
that
those
people
don't
seem
to
be
the
people
that
would
want
to
connect
with
open,
active
and
get
more
people
active.
Oh.
A
C
A
A
There
are
organizations
that
are
interested
in
publishing
a
significant
volume
of
opportunity,
data
that
they're
getting
from
various
sources
and
our
and
there's
more
than
one
organization.
I'm
thinking
of
here.
That's
precisely
two:
they
harvest
data
from
a
variety
of
sources
and
then
they
republish
it
for
selected
clients,
but
would
be
interested
in
republishing
more
widely
and
find
value
in
the
standards
as
giving
them
a
sort
of
input
and
output
interface.
C
A
A
C
See
but
this
just
this
seems
like
it's,
I
mean,
that's,
that's
solving
an
internal
problem,
for
I
mean
ultimately,
they
can
just
they
can
externalize
the
data
that
they
want
to
publish
openly
as
a
feed
right,
and
that
would
be
fine.
There's,
no
reason
why
they
couldn't
do
that
and
it
would
be
trivial
for
them
to
do
so.
So
I
I
don't.
I
still
don't
understand
what
problem
we're
solving
so
we're
solving
a
two-fold.
A
Problem,
if
you
imagine
an
organization
that
is
collecting
a
bunch
of
opportunity
data,
essentially
so
it's
essentially
in
the
in
the
I'm
in
role
right
for
a
bunch
of
other
organizations
in
a
somewhat
different
ecosystem
right.
So
it's
not
the
kind
of
leisure
center
world
that
the
diamond
is
in
it's
in
a
different
range.
A
It's
reprocessing
it
and
it's
and
it's
publishing
it
and
right
now
say
all
of
those
organizations
are
making
their
data
available
in
a
variety
of
bespoke
formats
and
they're
losing
a
lot
of
time
because
they
have
to
collect
that
information
you
know
might
be
uploaded
via
spreadsheet
might
be
other
some
kind
of
feed
model.
However,
those
organizations
are
making
their
data
known.
That
has
to
be
ingested
by
the
I'm
in
like
organization,
and
then
it
has
to
be
republished
in
some
way
by
the
I'm.
C
C
A
C
Sure
yeah,
yeah,
okay,
but
so,
but
I
think
that
maybe
we're
talking
about
two
different
things
here,
because
if
that's
about
making
so
if
there
are
middlewares
that
exist
other
than
I'm
in
which
they
already
are
right
and
they
want
to,
they
want
to
use
a
standard
search
api,
then
it
yeah
completely
makes
sense
like
middleware's
adopting
a
standard
search
api.
I
mean
to
be
clear.
C
The
I'm
in
guys
have
contributed
in
large
part
to
the
api
we're
discussing
here,
so
this
is
coming
from
iman's
original
thinking,
a
lot
of
it
right.
That's
where
a
lot
of
this,
and
in
fact
the
reason
it
came
about
was
partly
because
of
I'm
in
saying.
Is
that
something
that
would
be
useful
and
then
oh?
Does
it
fit
with
booking
as
well?
So
it
was
all
yeah.
So
so
that's
that's
why
it
exists,
and
that's
I
sure
it
being
useful
in
a
beta
form
is
the
same
thing
around
the
reason.
C
C
In
I
mean
that
would
be
the
same
as
I'm
in
going
and
collecting
a
bunch
of
private
feeds
themselves
that
only
they
have
access
to
and
publishing
them
themselves,
which
obviously
they
don't
do,
and
so
I
mean
if
we
want
to
get
into
the
world
of
allowing
people
to
have
closed
access
to
data
and
mixing
closed
data
in
and
then
yeah.
I
guess
that
possibility.
A
Exists
already,
though,
right
I
mean
you
could
also
implement
a
feed
model
and
say
well,
nobody
knows
about
the
existence
of
this
feed,
we're
harvesting
this.
You
know
privately
in
accordance
with
the
specification,
but
we're
just
not
making
it
public.
It's
not
submitted
to
the
status
page.
I
mean
that
you
know
that
could
also
happen
there
is.
There
is
a
difficulty
that
presumably
you
would
want
to
have
an
authorization
key
of
some
kind
for
any
api,
so
it
well.
I
guess.
C
My
deeper
concern
here
is
that
I
feel
like
we,
the
principles
of
open,
active
around
making
sure
all
data
is
open
to
be
published.
I'm
not
sure
if
the
scenario
outline
there
is
is
in
keeping
with
those
principles.
It
sounds
like
what
what
we're
really
doing
is
is
saying
to
so
someone
someone
can
republish
their
data
from
a
bunch
of
closed
sources
and
and
make
that
data
open
from
from
them
onwards,
right
which
is
not.
D
Okay,
I'm
gonna
ask
a
really
stupid
question,
but
maybe
it's
not
stupid
today
is
that
kind
of
what
emd
does,
though,
or
is
it
different
because
they
are,
I
guess,
the
the
one
true
source
of
that,
like
the
people
people
put
in
their
sessions
into
class,
want
to
direct.
Is
that
how
that's
different
it's
a
great.
C
So
currently,
emd
has
three
well
if
you
count
book
when,
although
that's
kind
of
moving
and
migrating
at
the
moment,
but
two
to
three
open
data
sources,
two
different
booking
systems
that
they
have
and
they
pay
for
themselves
and
one
which
is
a
partner
which
is
book
when
so
they
have
three
raw
feeds
which
anyone
can
consume
and
then
emd
class
finder
consumes
the
data
and
other
data
and
produces
their
front
end.
And
so
the
key
thing
there
is
the
raw
data
is
the
open
data.
C
There's
no,
I
mean
what
emd
could
have
done
and
I
don't
think
would
have
been
in
the
principles
of
open
activity.
You
know
what
we're
gonna
collect
all
the
data
ourselves
in
the
in
private
feeds
and
we're
going
to
then
publish
stuff
openly
when
we
want
to
and
not
when
we
don't,
which
then
what
that
does
is.
It
gives
emd
an
advantage
over
other
activity
finders
because
it
means
that
some
stuff
only
goes
into
emd
and
then
some
stuff
goes
to
everyone.
A
We
allow
leisure,
centers
and
so
on
in
principle,
not
to
expose
some
of
their
stuff
as
open
data.
Right
I
mean
if
you've
got
you
know,
the
typical
business
case
would
be.
You've
got
some
courses
that
are
underperforming
and
therefore
you
expose
those
as
open
data
and
then
you've
got
others
that
are
oversubscribed,
and
so
in
principle
you
wouldn't
publish
those.
I
mean,
that's
always
been
a
possibility
right,
but.
C
It's
different
to,
but
that's
different
from
having
a
some
kind
of
aggregator
anywhere
on
the
internet.
That's
using
private
data
instead
of
open
data
and
their
private
data,
in
addition
to
open
data.
But
then
it's
what
we
used
to
call
open
washing
it's
the
idea
that
you
say:
oh
yeah,
we're
compliant
with
open,
active
great.
C
C
You
can
get
easier
access
to
the
data,
but
that's
very
different
from
the
only
way,
because
that's
where
we
came
from
before
open
active,
the
only
way
to
access
certain
data
was,
if
you
had
the
right
agreement
with
the
right
person,
you
took
the
right
hand
at
the
right
meeting
and
that's
what
creates
all
the
friction
around
innovation.
So
we
want
to
be
ready
but
hold
on.
I
mean,
doesn't.
A
C
C
Basically,
if
you've
got
like
a
random
yoga
instructor,
they
want
their
stuff
everywhere
right,
it
shouldn't
depend
on
who
shook
hands
with
who,
in
the
middle
as
to
where
that
information
can
end
up,
and
I
guess,
if
you
take
that
as
the
principle
and
then
kind
of
work
backwards.
That's
where
you
end
up
with
like
the
reason
we
don't
want
these
random
data
silos
and
and
closed
data.
A
One
of
them
is
essentially
to
say
if
you
are
a
company
that
has
private
contractual
arrangements
to
republish
data,
if
you
are
not
published,
if
you
are
not
republishing
all
of
your
data,
you
can
republish
none
of
it
with
open
standards,
and
this
seems
to
be
independent
of
the
question
of
a
harvester
right.
I
mean
again
there's
the
enforcement
of
a
an
api
key,
but
it
seems
like.
C
C
I
guess
it
depends
on
the
business
model
of
the
middle
there
as
well.
I
think
it's
probably
it's.
Probably
it's
probably
actively
not
helpful
for
a
middleware
to
have
the
stuff
to
standardize
their
endpoints
to
match
every
other
middleware
right,
because
that
means
the
switching
cost
is
lower.
That's
we
business
model,
so
I
don't
I
can't
see.
I
guess
I
mean.
C
By
doing
that,
because
they're
going
to
be
sitting
in
between
anyone
who
wants
to
use
the
data
and
the
data
source,
and
so
we
you
know
that
that
could
definitely
happen
tomorrow.
I
mean
like
yeah,
I'm
in
could
start
doing
that
tomorrow,
right
and
and
and
pull
in
all
that
data
and
then
and
then
say
to
people.
You
can
only
access
it
through
us
and
and
really
clamp
down
on
that,
but
obviously
the
problem
with
that
is
like
I
said
that
that
is
kind
of
undermining
the
value
of
the
open
ecosystem.
C
So
I
think
a
conversation
to
be
had
there
is,
if
someone
is
telling
you,
whoever
you-
are
contractual
anonymous
provider
that
that
this
person
this
this
middleware
can
solve
your
open
data
problems
by
making
your
making
your
data
open
in
this
way,
but-
and
maybe
you've
missed
what
the
connective's
doing.
So.
I
I'm
worried.
A
That
this
isn't
terribly
useful
because
I
think
again,
because
I'm
not
comfortable
citing
such
parties,
but
I
think,
there's,
I
think,
there's
some
false
premises
involved
there.
I
think
I
think
the
number
of
organizations
that
perceive
themselves
as
having
open
data
problems
is
actually
fairly
low.
A
C
I'm
just
trying
to
think
how
to
take
this
on
usefully
well,
I
feel
like
until
we
can
really
get
into
the
detail
of
these
assumptions.
However,
we
validate
them,
it's
especially
difficult
when
obviously
they're
anonymous,
for
whatever
reason
I
think
it's
really
difficult
to
to
have.
Is
that
because
I
think
I
think
the
the
difference
right.
I
think
I
really
do
think
if
we
take
the
wrong
road
here,
we're
going
to
erode
what
we've
built
today,
like
I
said,
I'm
in
makes
one
different.
C
You
can
start
seeing
a
very
different
ecosystem,
I'm
not
saying
I'm
in
word,
but
I'm
saying
that
if
everyone
does
that
and
we
let
that
slip,
we
spend
a
lot
of
time
trying
to
reinforce
open
values
in
an
ecosystem
that
everyone's
looking
to
try
and
extract
value
from
right.
And
so
it's
dif.
It
is
difficult
to
hold
the
open
line,
but
I
think
it's
necessary
if
we
want
the
bigger
the
bigger
win
here.
C
So
I
think
it's
just
it's
just
really
making
sure
that
we
don't
accidentally
undermine
our
efforts
today
by
especially,
if
there's
an
anonymous
scenario,
we
can't
fully
explain
which
doesn't
really
help
me
feel
comfortable
with.
You
know:
there's
a
lot
of
open,
good
stuff
happening
over
here
and
there's
some
anonymous
person
in
the
corner.
That
wants
to
do
something
to
extract
value
from
someone
we
don't
know
who,
but
let's
rewrite
our
standards
for
them
like
it
feels.
A
A
A
My
supposition
is
that
it
would
be
useful
to
have
this
option
open
in
future
and
it
would
be
possible
to
readily
develop
a
kind
of
prototype
data
to
illustrate
how
this
might
be
done
going
forward.
It's
not
that
I
want
to
use
this
as
some
sort
of
way
of
strategically
reorienting
the
entire
open
active
initiative.
It's
about
giving
another
means
of
access,
and
it's
and
it's
a
well-established
pattern.
I
mean
this
was
on
the
table
as
something
to
be
done
in
2018.
A
C
Well,
I
think
it's
quite
different,
though
we
weren't
we
weren't
talking
about
an
alternative
to
the
harvesting
model
then,
and
we
weren't
talking
specifically
about
allowing
api
keys.
This
is
see
I
mean
this
is
a
danger
here
right
we
get
into
a
place
where
you
can
legitimately
publish
open,
active
data
behind
an
api
key
where
you
can
control
who
can
consume
that
data.
That's
what
this
allows
so
is
is,
is
the
issue
simply
with
the
api
key.
A
C
It
a
bit
I
mean,
maybe
if
it's
a
strategic
pillar,
that's
my
question.
I
guess,
if
it's
a
strategic
pillar,
that
means
it's
part
of
something
that
we're
going
to
be
pushing
to
people
to
do.
If
it's
just
a
beta.
Like
I
said
at
the
beginning,
that's
a
different
story
like
well
up
for
doing
this
as
a
beta
exercise.
I
guess
I
guess
within
40
minutes.
A
And
I
you
know
I
then
mistakenly
and
speculatively,
and
probably
just
let
us
down
a
path
that
we
shouldn't
have
gone
down
but
speculatively.
Yes,
I
think
this
would
be
a
valuable
thing
to
have,
and
not
just
for
shadow
organizations
but
because
you
know,
as
a
consumer,
it's
very
easy
to
write
a
client
that
will
query
an
api
and
you
can
take
little
sips
of
the
data
and
it's
kind
of
a
nice
a
custom
way
to
work.
A
It's
much
more
lightweight,
so
you
know,
I
think
I
think,
there's
a
benefit
in
it
so
speculatively.
Yes,
I
think
this
would
be
very
valuable
to
have
as
a
strategic
pillar
in
open
active,
but
I
do
not
see
pursuing
that
prior
to
march
2021
as
something
that
would
be
prioritized,
because
we
just
don't
have
the
time.
As
you
say,
it
is
a
major
effort.
A
C
That
makes
sense,
so
I
guess
the
fundamental
question
here
is
people
say
at
the
moment
there's
contractual
obligations
on
people
to
publish
their
data
according
to
open
standards.
That
stuff
is
around
making
the
harvesting
stuff
the
building
and
harvesting
so
rpde
and
the
modeling
spec
and
building
and
booking
right.
Those
two
things
so
just
to
confirm
we're
not
saying,
hopefully
under
any
circumstances
that
someone
could
tick
those
contractual
boxes
by
implementing
only
an
opportunity,
feed
an
opportunity,
api
behind
an
api
key
and
not
publishing
an
open
feed.
This
is
like
an
addition.
A
It
was
only
ever
you
who
mentioned
the
contractual
issue
and
that
certainly
would
not
be
something
that
I
would
look
to
have
you
know
it
would
never
approach
the
level
of
formality,
I
think,
to
write
it
into
a
contract.
You
have
to
have
you
know
a
specification
and
it
has
to
be
a
ratified
specification
and
it's
clear
that
we
can't
get
to
that
point
by
march,
2021,
absolutely
so
yeah.
A
The
idea
of
writing
this
into
contracts
had
never
entered
my
mind
and
yeah.
I
certainly
you
know.
As
you
say,
it
would
be
unrealistic
to
do
so,
and
I
wouldn't
yeah.
That's
that's
off
the
table.
I
mean,
I
suppose,
potentially
you
know
see
what
happens
in
2021
2022.
You
know
other
people
might
take
it
in
that
direction,
but
there's
certainly
nothing
that
I'm
envisaging
at
all.
C
A
Yeah-
and
I
think
actually
like
I
said
earlier-
I
think
maybe
I
just
added-
I
muddied
the
waters
a
bit,
but
I
I
think
actually
we're
basically
agreeing
with
each
other.
You
know
it's.
I
think
it
would
be
good
to
have
as
solid
a
beta
as
possible
as
a
kind
of
sustainability.
Point
really.
You
know
here's
here's,
what
it
would
look
like.
Here's
work
that
was
begun
in
2018,
which
is
now
brought
to
some
kind
of
usable
state
of
completion.
C
We
have
the
adopted
model
that
we
have
in
terms
of
you
know
lack
of
api
keys,
the
reason
that
we
push
open
first,
the
reason
the
md
we
did,
what
they
did.
The
reason
all
these
things
have
happened
for
sustainability
to
make
sure
that
we
don't
have
a
situation
where
in
2021
or
two
or
three
someone
says
oh,
hang
on.
C
I
think
there's
always
going
to
be
that
challenge,
because
anyone
looking
at
this
will
think.
How
can
I
commercially
squeeze
something
out
of
it?
I
know
I'll
be
the
only
one
that
doesn't
do
open
in
this
game
of
people
who
are
all
trying
to
do
open
and
they'll
be
the
suckers,
because
I'll
be
the
one
doing
the
clothes
stuff
and
that's
that's
always
the
case.
There's
always
gonna
be
someone
who
tries
to
be
closed
in
an
open
market
in
order
to
leverage
some
kind
of
advantage,
and
so
it's
almost
just.
C
How
do
we
make
sure
that
we
cement
this
in
a
way
that
we
can't
later
on,
get
strategically
undone
and
undermine
all
the
good
work?
That's
happened
here
because
kind
of
the
information
left
the
building.
If
you
like,
and
then
the
new
people
come
in
and
go,
I
don't
know
what
why
why
we've
got
open
licenses
on
this
stuff,
like
there's
open,
feed,
end
points
we
just
put
api
keys
on
them,
just
get
them
to
charge
whatever
they
want.
That's
fine,
you
know,
and
then
certainly,
but
surely
it
all
kind
of
winds
back
sure.
A
A
But
that
said,
there
needs
to
be
some
kind
of
query
interface
on
the
harvester
and
it
makes
sense
to
have
it
in
a
robust
kind
of
way
and
so
here's
another
there's
another
call
scheduled
for
this
discussion.
So
I
guess
we
can
get
down
to
the
nitty-gritty.
I'm
conscious
we've
got
exactly
one
minute
left
and
that
nick
and
I
have
been
talking
for
almost
exactly
29
and
a
half
of
each
of
that.
D
We
will
try,
we
will
like.
Obviously
the
principles
of
open
are
absolutely
fundamental
to
how
we
make
sure
that
what
we
have
created
kind
of,
as
you
say,
disintegrate
before
our
eyes,
like
and
as
part
of
the
sustainability
work
like
how
we
make
sure
that
this
continues
as
open
and
not
just
continues,
but
there's
loads
of
money
and
api
keys
or
whatever
else
magical
locks
and
whatever
else
wizards
in
the
way
and
will
be
like
a
key
consideration.
So
yeah,
although
we
haven't,
maybe
answered
that
today,
I
think
it's
it's
definitely
something.
D
A
Okay,
I
think
on
that,
on
that
good
note,
I
will
thank
everybody,
I'm
glad
we
were
at
least
entertaining
and
I'll
see
you
all
two
weeks.
Hence
when
I
believe
the
schedule
is
the
scheduled
topic,
is
the
data
set
site
specification?
So
that's
going
to
be
pretty
meaty.
Have
your
have
your
technical
hats
on.