►
From YouTube: OpenActive W3C Community Group Meeting / 2020-08-26
Description
The topic for this call was further work on the Dataset Site Specification.
Slides and a summary of the call can be found at https://w3c.openactive.io/meetings/2020-08-26-dataset-site-specification-cont.
A
The
topic
of
the
call
is
the
data
set
site
specification,
it's
just
the
three
of
us,
so
it
could
be
a
fairly
short
call,
especially
since
one
of
the
main
actions
that
comes
out
of
it,
I
think,
is
just
for
me
to
ask
you
guys
to
review
the
stuff.
I've
written
and
I'll
send
out
a
call
to
the
community
more
broadly
to
to
do
that
as
well
later
on.
So
it
might
be
fairly
quick
order
of
business,
but
we
shall
see.
A
A
A
The
consensus
was
that,
given
that
there's
a
template
already
provided
by
our
tooling,
which
satisfies
the
conditions
for
you,
it
does
no
harm
to
make
more
things
required
or
recommended
than
optional,
because
essentially
it's
you
know.
If
you
use
our
tooling,
you
get
all
that
stuff
for
free,
so
the
specifications
a
little
tighter
than
it
was
before.
A
C
A
A
Micro
data
type
things
in
the
specification
itself.
If
it's
given
that
it's
already
there
and
the
json
are
already
specified
for
the
json,
it
seems
potentially
redundant
to
put
that
in
micro
data,
but
I'd
be
interested
to
hear
your
thoughts
on
that.
Obviously
people
get
it.
You
know
free
without
effort
if
they
use
all
the
templates
and
so
on
and
so
forth,
but
putting
in
the
specification
as
a
recommendation
seemed
possibly
too
strong.
B
Yeah,
I
guess
the
thing
we
mentioned
on
the
last
call
was
about
whether
there
are
other
tools,
specifically
those
in
that
kind
of
open
data
community
that
like
well.
I
can't
remember
the
names
of
them
there's
loads
of
them,
but
they,
but
they
are
the
kind
of
standard.
It's
been
a
while
this.
This
the
kind
of
standard
open
data
tooling
that
like
passes
data,
sets
things
that
power
data.gov
and
things
like
that,
which
I'm
going
to
rapidly
try
and
use
the
cache
of
google
to
remember
the
names
of.
A
Yeah,
if
you
could,
that
would
be
good,
because
I
did.
I
did
I
sort
of
raised
this
generally.
Actually,
at
the
odi
saying
what
is
you
know,
what
is
the
general
perception
of
the
currency
of
those
kinds
of
tools,
because
I
think
about
it
as
sort
of
emerging
to
a
large
extent
out
of
out
of
semantic
web
work
and
maybe
less
relevant
today
than
it
was
five
or
six
years
ago?.
B
So
that's
probably
why
they've
decided
to
do
this
one
as
well,
but
I
would
be
interested
so
data
press
for
a
long
time
was
a
company
a
startup.
I
don't
know
how
they're
doing
now
that
did.
Oh,
they
still
go
they're
still
getting
so
they
kind
of
I
think
they
compete
with
sanat.
Is
it
sinatra
or
some
something
like
that?
D
B
I
think
actually
we
introduced
them
to
to
london
sport,
that's
what
that's
how
that
came
about
so
years
ago.
They
were
looking
at
london
support,
we're
looking
for
a
way
of
publishing
their
data,
and
so
we
introduced
them
to
tom,
because
tom
was
a
date.
It
was
a.
There
was
a
startup
in
the
cohort
of
startups.
That
was
the
same
as
the
as
I'm
in
which
was
a
startup
in
the
odi
accelerator
back
five
years
ago,
before
open
active
was
taken
on
by
the
odi
formally,
and
so
there
was
the
yeah.
B
B
That
is
the
name
of
the
open
source
portal
and
that's
the
big
popular
one,
and
they
are
also
the
same.
I
think
I
think
data
press
is
based
on
c
can
because
c
is
open,
source
and
and
c
can.
Ck
am
is
a
competitor
to
another
one
which
we'll
find
the
name
of
which
is
the
one
that
data
press
is
committed
to,
but
they've
got
their
they've
got
proprietary
software.
B
B
B
B
That's
around
the
north,
apparently
now
not
just
leads,
and
so
I
suppose
it's
it's
really
how
much
we
want
to
enable
these
kind
of
organizations
to
promote
the
data
as
well
as
google,
and
I
guess
it
comes
down
to
whether
these
socrata
and
datapress
and
secant
are
all
using
the
same
json,
ld,
scheme.org
stuff,
which
obviously
google's
promoting
and
google's
using
because
that's
it's
like
almost
the
entire
ecosystem
is
google?
Isn't
it
schema.org
run
by
google,
google,
then
using
that
and
pulling
into
google
search
for
their
data
certain
search
engine?
A
B
B
A
I'm
just
not
clear
given
that,
given
that
all
the
information
that
would
be
presented
in
the
structured
data,
markup
is
also
present
in
the
json
ld
and
given
that
the
largest
part
of
the
ecosystem
prefers
it
to
be
in
the
json
ld
and
given
that
json
ld
is
also
parsable
by
people
who
are
outside
of
that
ecosystem.
I'm
just
not
sure
what
value
that
kind
of
micro
formatting
stuff
is
adding.
B
B
Yeah
yeah
right
right,
so
it's
almost
then
so
that
creates
some
additional
accessibility.
So
it's
almost
like.
Is
it
worth
somewhere
recognizing
that
as
a
maybe
it's
just
a
line
in
the
spec,
then
that
just
says
you
know
micro
formats
such
as
or
or
you
could
you
could
put
well,
it
depends
on
like
how
much
you
wanted
to
include
it.
B
The
the
ci
hasn't
picked
it
up,
so
it's
not
being
published
on
github
pages.
Oh
okay,
that's
weird
kind
of
prohibited
for
just
quickly
I'll
have
to
check
it
then
no
worries
but
yeah.
What
I
can
read
is
a
markdown
that
I
can
see
you've
just
put
in
there
yeah,
so
you've
got
properties
in
the
list.
So
I
guess
it's
a
question
of
whether
we
you
you
could
have
a
properties.
B
You
know
you've
got
a
property,
take
status
type
notes,
whether
there's
it's
useful
to
have
an
equivalence,
for
you
know
the
way
that
you
know
the
way
that
in
I
don't
know,
if
you
you,
you
remember
looking
at
this,
but
in
d
cat
two
there's
like
a
there's
like
a
little
table
of
equivalence
between
schema.org
and
dk
yeah.
So
is
it
worth
it's
just
having
like
a
little
a
little
cheeky
table
somewhere
near
the
appendix
like
they
have,
which
is
just
like
if
you're
going
to
do
this,
this
is
our
recommended.
B
A
That
makes
that
makes
sense.
I
mean
this
is
exactly
it
is
that
I
wrestled
with
that
yesterday
and
when
I
started
putting
it
into
the
main
table
kind
of
saying
here
are
the
properties
that
we
would
recommend
you
communicate
in
the
human
readable
part.
It
started,
making
not
an
unreadable
mess
of
it.
Yeah.
B
A
B
B
A
B
But
I
mean
you:
could
the
equivalence
table
could
literally
just
be
properties
of
property
rather
than
you
know
need
to
go
into
the
html
structure
of
it.
You
know,
could
just
be
this
property
is
the
same
as
this
other,
because
it's
basically
dcat.
I
think,
because,
because
what
we're
really
saying
there
is
the
d-cap
properties
which
we're
using
to
in
the
micro
data
which
is
dkan
are
equivalent
to
these
properties
in
the
in
the
json,
so
it
so.
B
B
Given
that
that's
I
mean,
although
a
lot
of
it,
I
think,
would
probably
still
be
decaf
v1
but
you're
you're,
basically
because
the
problem
with
that
mapping
in
the
dcap
v2
spec
is
it
predates
the
editions
we're
adding
now
for
web
api
stuff
so
having
the
same
in
our
spec
would
be
quite
a
good
one
and
also
quite
nice
that
we
can
point
people
to
it
and
say:
hey:
we've
got
a
map
in
here.
If
you
you
know,
decap
people
are
thinking
about
it.
A
Yeah,
I
guess
I
guess
that's
nice,
because
it
does
make
more
explicit
the
link
as
well,
because
it's
that's
kind
of
it's
detectable
in
the
current
documentation,
but
it's
not
really
foregrounded.
So
I
suppose
that
would
at
least
make
the
the
relationship
with
decatur
clearer
if
it
did
nothing
else,.
A
Okay,
that's
that's
quite
a
doable
action,
so
the
web
api
endpoint
descriptions.
Essentially
this
is
just
a
more
specific
request
for
a
review.
Most
of
writing.
The
specification,
of
course
was
was
essentially
deriving
the
specification
from
the
template,
but
that
wasn't
true
with
regard
to
the
web
api
booking
stuff,
because
we
don't
have
that
in
existence.
B
B
B
B
D
A
A
C
B
But
which
is
annoyingly
the
only
real,
like
the
thing
that
the
validator
has
like
sorry,
the
the
test
suite
has
some
code
that
references
this
stuff
and
that's
the
only
property
that's
referenced,
because
it's,
the
only
important
thing
to
know
is:
what's
the
actual
root
of
the
thing,
but
but
interestingly,
the
clarifications
that
we've
added
there.
So
so
tim,
I
I'm
looking
at
your
example.
B
This
was
the
whole
debate
that
we
were
having
in
that
rfc,
because
one
of
the
guys
from
science
on
schema
was
was
talking
about
using
web
api
as
a
a
replacement
for
open
api.
The
kind
of
the
machine,
readable
description
format,
the
swagger,
what's
right,
right,
swagger!
So-
and
this
is
this
big
debate
we
have
had
so
actually
this.
B
A
A
B
B
A
D
B
B
More
we've
got
to
refine
the
spec
itself
a
few
times
to
get
it
to
kind
of
see
our
stage
so
sounds
like
this.
I
mean
between
us
us
refining
this,
and
you
know
it
sounds
like
he's
happy
with
conforms
to
really
the
only
thing
he's
likely
to
change,
which,
unfortunately,
is
that
thing
that's
embedded
in
all
the
implementations
is
the
endpoint
url,
but
you
know
that's
just
I
mean
at
the
end
of
the
day.
That's
the
difference
between
endpoint.url,
which
I
think
is
what
he's
proposing
and
endpoint
url.
A
B
Yeah,
I
guess
that's
yeah.
Well
I
mean.
Is
it?
Is
it
worth?
What
are
you
kind
of
thinking
in
terms
of
process
here?
I
wonder
whether
it's
worth
this
kind
of
pinging
around
the
version
that
we've
got,
I'm
just
thinking
about
how
we
did
it
with
the
booking
thing
like
before
we
get
to
cr,
it's
almost
making
sure
that
everything's
quiet
in
the
issues
do
you
know
what
I
mean
like
all
the
issues,
so
maybe
maybe
almost
before
we
before
we
label
it
cr
is
is.
B
A
Yeah,
sorry,
sorry,
that
is
the
proposal
yeah,
sorry
that
was
ambiguous,
but
yeah
I
was
thinking,
leave
it
as
it
is
right
now
on
0.1
or
we
could
do
0.2
or
something
right
request
feedback.
I'm
just
wondering
about
what
the
what
the
deadline
for
that
should
be,
because,
obviously,
if
I
send
out
a
request
for
feedback
right
now,
it's
going
to
sit
in
people's
inboxes
and
everyone's
going
to
ignore
it.
B
B
A
I
think
the
cadence
is
pretty
rapid
in
that
yeah.
You
know,
most
of
the
tooling
is
already
there.
In
fact,
I
think
that
you
know
we're
not
going
to
without
unless
something
really
horrendous
came
up,
we're
not
going
to
be
making
major
changes
to
it.
In
fact,
right
yeah,
most
of
the
rest
of
it
actually
is
reflected
in
the
schema.org
discussion.
So
again,
that's
relatively
solid,
so
I
would
like
to
move
it
forward.
I
think,
fairly
quickly
and,
as
you
say,
sort
of
pretty
live
really
that.
B
A
You
know
people
surprisingly
change.
We
acknowledge
that
you
know
it
happens
on
github,
so
everybody
can
see
it,
but-
and
also,
I
think
this.
The
circle
of
people
who
are
going
to
be
interested
is
pretty
small,
like
you're
the
most
authoritative
commentator,
there's
going
to
be
other
implementers
who
are
interested
and
informed,
but
probably
don't
see,
changes
to
this,
as
you
know,
threatening
their
you
know,
business
model
or
or
their
right
very
much.
B
Yeah
right
sure,
yeah
well
so,
in
which
case
potentially
we
could
put
a
deadline
in
rather
than
for
comments
to
be
complete,
but
more
for
a
bit
like
with
with
what
dan
did
with
his
kind
of
version,
10
deadline.
It's
almost
like.
Is
it
the
point
where
we
can
draw
a
cr
line?
Therefore,
do
all
comments
not
just
need
to
be
made,
but
also
concluded?
You
know
by
x
day
so
have
we
could
we
could
get
to
the
point?
A
B
Second
october,
okay,
yeah
yeah,
sure
yeah.
That
makes
sense,
so
we
can
then
that
we
can
get
a
lot
of
this
going
before
that
and
then
would
schema
integrate
those
changes
and
then
everything
should
be
ready:
sort
of
on
rails,
really
yeah
yeah.
That
sounds
good
it'd
be
interesting,
but
anyone
from
schema
is
going
to
come
across
into
our
repo
and
start
looking
at
it.
B
A
B
D
Okay,
cool.
I
had
a
question
just
about
you
know.
As
with
the
data
specifications,
until
people
start
to
actually
implement
slash,
publish
against
specifications,
you
can
never
be
quite
sure
whether
they've
got
some
logistical
flaws
in
them.
That's
covered
by
the
real
world,
I'm
just
wondering
if
there's
I
I've
been
just
nosing
around
the
c-can
and
stuff.
While
we've
been
on
the
call,
I
wondered
if
there's
a
way
to
test
it
out
in
existing
tooling,
to
make
sure
that
we
haven't
expect
something.
B
Yeah,
so
from
what
I
understand
of
the
tooling-
and
I
know
that
open
data
certificates
project
that
the
odi
has
as
well
is
one
of
these
and
there's
buttons
in
c.
Can
you
compress
which
basically
are
if
you,
if
you
click
the
button
and
give
it
the
url,
it
will
suck
the
the
mess
data
in
and
then
it
can
index
it.
So
you
can
then
have
the
categories
and
the
title
searchable.
B
C
B
The
community,
so
we
we
could
kind
of
reach
out
to
to
chris
and
see
if
him
or
his
whoever
one
of
his
colleagues
is
managing.
That
instance
would
be
interested
to
try
and
I
mean
actually
they've
got
open
sessions
which
is
using
the
latest
template
they've,
just
updated
it
a
week
ago
or
two
weeks
ago.
So
we
could
ask
them
to
index
their
own
data,
see
if
they
can
do
it
as
an
exercise
that
would
at
least
cover
c-can.
A
B
B
A
Yeah
it'd
be
kind
of
useful
exercise
from
from
the
other
side
as
well
in
gauging
how
maintained
those
tools
are
and
how
relevant
they
are.
I
suppose
things
like
d-cad
and
so
on
and
so
forth
might
not
be
intelligibly
supported
in
them.
Yeah.
Okay!
So
sorry,
I'm
just
what
are
they?
What
are
the
concrete
actions,
so
chris
you're
going
to
experiment
with
you're
going
to
reach
out
to
london
sport,
or
is
that
something
nick
was
happy
to
do.
A
B
A
B
Yeah
that
sounds
great
okay.
Well,
the
only
other
question
I
had
was
we
had
a.
We
had
a
thing
about
conformance
certificates
before
and
like
referencing
features
that
are
implemented
in
the
booking.
Spec
I
mean
it
was.
It
was
kind
of
two
things.
It
was
conformance
to
something
some
something
that
said
that
kind
of
proved
conformance,
but
it
was
also
a
way
of
saying
these
are
the
features
that
are
implemented
right.
B
Yeah,
that's
right
so
in
the
in
the
in
the
issue.
Sorry,
in
the
repository
there
is
a
kind
of
some
very
rough
kind
of
attempt
at
doing
some
jason
ld
thing
for
a
conformance
certificate
that
you
could
link
to
that.
Basically
would
say
that
I've
certified
that
this
implementation
has
these
features
and
tests
passed
for
them.
That's
basically
what
it
says.
B
I
mean
yeah,
whether
that,
however,
you
run
that
tool,
there
might
be
lots
of
ways
of
running
it,
whether
you
run
it
yourself,
whether
you
get
you
know,
gold
stamped
by
someone
else
running
it
for
you
or
all
the
rest
of
it.
So
just
wonder
in
terms
of
integrating
that
into
this
and
whether
yeah,
how
did
that?
How
that
could
I
mean?
B
Basically
I'm
just
thinking
if,
if
the
features
of
the
booking
spec
and
the
main
reason
to
do
this,
is
it
although
there
could
be
features
of
open
data
too,
to
be
fair,
just
thinking
where
this
could
best
live
like?
Is
this
something
that
maybe
should
be
incorporated
into
the
booking
spec,
in
fact,
as
an
appendix
of
some
sort?
A
B
Oh,
the
the
the
data
set
site.
Sorry,
the
this
suite
does
support
the
does
output
this
stuff.
It's
just
that
we
haven't
formalized
the
this,
the
json
ld
for
it,
but
the
well.
Actually,
I
can
see
I'm
I
may
have
a
look,
I
think,
yeah,
because
so
the
test
we
already
outputs,
a
certification
which
is
what's
used
for,
which
is
what
the
it's
kind
of
running
on
a
ci
at
the
moment
against
itself.
B
Well,
so,
no
well
what
sorry?
What
a
moment
was
that
the
specification,
so
the
the
tooling
at
the
moment
supports
outputting
the
certification
and
the
and
and
I'll
check
if
it
does
the
json
ld.
I
can't
remember
because
that's
kind
of
just
a
rough
sketch,
but
but
it
supports
that
that
stuff
coming
out,
and
so,
if
we
add
more.
B
B
All
implementations,
so
obviously
the
tests,
the
test
suite,
has
well
okay,
more
correctly,
the
features
so
there's
a
feature
table
and
the
test
suite
supports
certain
features.
Some
of
those
features
are
booking
features.
Some
of
those
features
open
data
features.
So
obviously
the
number
of
features
will
increase
as
the
test
suite
is
built
out,
but
I
suppose,
as
far
as
a
spec
goes,
those
features
are
just
ids.
B
A
I
think
that
this
is
a
matter
for
a
separate
call,
because
this
is
really
about
an
entire
ecosystem.
This
is
really
about
how
the
publishing
framework
as
a
whole
fits
together,
and
it
makes
sense
to
try
to
keep
it
tight.
I
mean
we
do
want
the
pieces
to
fit
together
to
join
quite
cohesively.
Absolutely.
B
B
Yeah
that
sounds
good
about
that
yeah,
and
actually
it
would
be
good
to
get
the
if
that
is
the
subject
of
the
next
chord
it'd
be
good
to
get
some
of
the
booking
people
who
are
interested,
especially
when
they're
back
from
leave,
because
I
suspect
I
can't
remember
who
it
was
on
the
last
call.
That
said
it
I
feel,
like
someone
said
yes,
it
would
be
useful
to
have
features
listed,
so
they
knew
which
which
what
to
expect
from
from
booking
endpoints.