►
From YouTube: IETF112-ASDF-20211112-1430
Description
ASDF meeting session at IETF112
2021/11/12 1430
https://datatracker.ietf.org/meeting/112/proceedings/
A
In
the
participants
list,
so
now
it's
off
offpost,
so
let's
get
going
so
welcome
to
this
meeting
here
for
the
asdf
working
group
at
iatf112,
and
there
is,
I
realize
there
is
actually
the
wrong
date
on
the
slide
here.
I
need
to
forgot
to
change
that,
so
I'm
nicholas
vadell
and
with
me,
of
course,
we
have
michael
richardson.
A
So
this
is
the
note.
Well,
the
high
level
thing
you
will
be
recorded,
or
you
are
recorded
already
remember,
to
be
nice
and
be
professional.
We
have
a
slightly
expanded
set
of
this
one
in
a
moment
and
remember
that
the
ipr
guidelines
of
iitf
is
in
effect
the
link.
Is
there
as
well
for
all
the
material
relating
to
asdf.
A
There
is
the
link
on
the
repo
we're
working
on
github
and
there's
also
the
links
for
the
to
the
notes
for
today,
where
michael
is
taking
taking
notes
and
michael,
is
also
acting
as
jabra
scribe.
A
A
A
It's
basically
about
you
know
treating
your
colleagues
with
respect,
speak
slowly,
limit
use
of
slang,
dispute
ideas
by
using
recent
arguments,
use
best
engineering
judgement,
find
best
solution
for
whole
internet
and
contribute
to
the
ongoing
work
of
the
group
in
the
iedf,
and
so
this
is
what
you
need
to
keep
in
mind
when
you
participate
in
this
meeting.
We
try
to
be
polite
to
each
other,
and
if
you
need
more
information,
there
is
the
rfc
up
there.
A
A
We
will
continue
with
the
working
group
status
update
and
then
continue
with
the
main
meet
of
the
meeting,
which
is
the
sdf
getting
sdf
ready
for
working
group.
Last
call
after
that
we
have
a
couple
of
new
work
items
or
related
work
that
we
will
sort
of
be
looking
at
and
we
will
sort
of
try
to
work
out
how
to
fit
them
into
the
bigger
sdf
story
on
protocol
mappings
instances
and
relationships.
A
Finally,
we
are
looking
at
the
asdf
milestones.
We
do
have
a
pretty
packed
agenda,
so
we
will
be
moving
along
at
the
brisk
pace,
so
an
admin
I
mentioned
all
this
already,
so
you
don't
there's
nothing
special
here,
decisions
on
mailing
lists
and
work
on
github
and
we
tried
to
do
in
addition
to
these
meetings
at
the
not
the
physical
ifdfs
but
the
virtual
physical
idfs.
We
also
do
virtual
interims
and
we
have
had
a
couple
so
far.
A
A
So
on
a
related
thing
to
asdf
is,
of
course,
the
one
data
model
and
the
the
one
data
model
was
the
activity
that
kicked
off.
This
work
initially
created
in
2018
to
harmonize
iot
data
models
across
multiple
ecosystems
such
as
ocf
and
ipso
and
bluetooth,
etc,
and
this
group
had
two
main
objectives:
one
was
it:
it
came
out.
Two
main
objectives
came
out
of
this
one
was
this
common
format
for
defining
data
and
interaction
models,
and
this
resulted
in
sdf,
which
were
of
course
working
in
this
group
here,
and
the
other
part
is
developing.
A
B
Yeah,
thank
you.
So
there
are
a
few
things
we
have
to
do
to
become
ready
for
working
plus
call.
Of
course
there
is
the
draft
itself
and
we
also
need
to
do
some.
Administrational
things
identify
a
document
shepherd
that's
usually
done
by
the
working
chair.
So
if
you
want
to
say
anything
about
that,
please
do.
A
I
we
have
a
proposal,
at
least
for
for
a
case
of
cornbread,
to
be
the
shepherd.
I
just
checked
with
him,
so
I
haven't
been
able
to
propagate
the
information,
but
so
I
think
that
will
that
will
work
out
well,
he
has
read
this
back
and
so
on
and
he's
happy
to
take
it
on.
B
Okay,
so
can
you
put
the
name
in
the
notes
please?
So
the
other
thing
we
need
to
do
is
work
on
the
draft
and
there
are
some
nine
issues
and
two
pull
requests
on
the
repository
at
this
point,
and
there
are
a
couple
actual
change
requests.
B
B
There
is
some
tools,
work
that
needs
to
be
completed
because
appendix
b
is
generated
out
of
appendix
a,
and
there
are
limitations
in
that
tool
and
there's
also
potential
future
work
that
we
will
be
talking
about
in
the
last
20
minutes
of
this
work
group
meeting,
which
we
don't
have
to
complete,
but
we
probably
should
look
at
it
to
make
sure
we
don't
paint
ourselves
into
a
corner
here
by
doing
something
in
the
base
draft
that
makes
the
future
work
harder.
B
So
there
are
two
change
requests.
So
let's
talk
about
the
first
one:
pull
request,
45
stupid
that
ari
isn't
here
we
had
a
last
minute
thing
getting
in
the
way,
so
we
have
much
less
experience
with
action
and
event
performances,
then,
with
properties
affordances.
B
So
right
now,
in
sdf
1.1
we
have
a
single
data,
type
definition
for
the
input
and
a
single
definition
for
the
output
and
that
that
is
often
a
little
bit
unwieldy,
because
it's
very
likely
that
your
action
will
have
more
than
one
input,
so
pull
request.
45
suggests
that
maybe
we
make
the
the
object
that
we
would
use
to
carry
all
these
different
parameters,
implicit
again
next
slide,
please
so
for
the
input
side,
it's
quite
usual
to
have
multiple
parameters.
B
B
So
the
the
what
are
currently
property
names
will
be
some
other
kind
of
sdf
name
for
the
parameters,
but
that's
not
probably
not
really
a
big
change.
So
we
had
some
discussion
in
the
last
few
hours
about
that
and
we
weren't
quite
as
sure
anymore
whether
this
is
actually
needed.
So
my
request
would
be
for
for
people
to
look
at
the
issue
in
more
detail
or
if
you
already
have
experienced
this
a
little
bit
of
inconvenience.
B
B
B
It
would
be
possible
to
do
something
like
that.
The
the
problem
is
that
I
haven't
seen
a
good
proposal,
how
we
could
continue
to
use
json
pointers
in
the
straightforward
way
that
we're
using
them
now
once
we
do
that,
because
the
json
pointers
would
actually
have
queries
in
them
with
with
prefixes
that
are
defined
in
the
spec,
the
json
pointer
points
into,
and
this
is
getting
a
bit
ugly.
B
So
this
is
an
issue
right
now,
it's
not
a
specific
pull
request.
B
So
if
you
think
that
this
issue
is
important
to
address,
then
we
should
have
a
discussion
on
how
we
could
actually
make
something
work
that
addresses
the
issue.
B
C
What
is
that?
Why
do
people
need
to
have
to
emit
into
multiple
namespaces?
What
is
this?
What
is
the
pull
on
the
other
side?
To
doing
that,
I
understand
what's
difficult
for
us
to
do
it,
but
I
understand
why
do
people
want
to
do
it.
B
Yeah,
so
I
think
one
can
can
come
up
with
a
lot
of
use
cases,
but
they
are
not
that
strong.
So
imagine
you
are
writing
a
translation
from
an
ecosystem.
B
Model
and
want
to
to
factor
out
some
data
type.
That
actually
is
interesting
enough.
That
you
want
to
put
it
into
a
common
library.
Then
you
cannot
have
a
single
file.
That
does
these
two
things
and
some
people
would
argue
yeah.
That's
exactly
what
we
want.
We
want
that.
You
write
two
files
because
one
goes
into
the
common
library
and
the
other
one
is
the
thing
model
that
you
are
just
creating.
B
C
B
Yeah,
so
a
translator
should
probably
be
able
to
to
consume
multiple
sdf
models
and
translate
it
into
something
that
that
is
made
might
be
multiple
models
or
a
single
model
on
the
ecosystem
side.
So
it's
not
necessarily
a
one-to-one
translation
and
that
may
be
yeah.
It
may
require
doing
additional
control
files
that
control
these
interrelationships
and
so
on.
So.
A
B
A
B
B
This
choice
makes
it
hard
to
do
that,
which
is
just
one
instance
of
a
larger
problem,
which
is
that
we
we
are
using
the
grammar
to
these
to
describe
the
input
to
the
processing
model,
but
the
processing
model
actually
has
several
steps
which
could
be
called
resolution,
steps
that
generate
the
thing
that
really
needs
to
conform
to
this
grammar,
so
that
that's
a
limitation
that
that
tools
will
have
to
struggle
with.
So
they
cannot
simply
validate
input.
B
They
might
have
to
do
resolution
first
before
they
actually
know
whether
everything
that's
required
is
present
in
in
the
document,
because
it
has
been
pulled
in
using
sdf,
ref
yeah.
So
that's
one
area
where
we
might
want
to
try
to
have
some
ideas,
but
unless
people
have
ideas
how
to
solve
this,
it
probably
will
stay
that
way.
B
This
this
comes
up
in
in
translator,
building
if
you
have
an
enum
or
something
in
in
a
source,
ecosystem
and
you're.
Translating
this,
and
you
essentially
have
to
blow
up
the
attributes
that
come
with
this
enum
into
the
branches
of
the
the
sdf
choice.
So
it's
it's
not
beautiful,
but
it's
also
not
really
killing
us.
B
Yeah
there
are
a
number
of
tasks
that
need
to
be
done
before
we
can
last
call
this
like
do
we
use
the
optional
commas
in
cdl
and
do
our
json
text
examples?
Actually,
all
parse
can
we
add
some
automated
checks
and
so
on
and
of
course
we
should
try
to
collect
more
editorial
reviews
by
by
people
who
are
reading
this
for
the
first
time
and
and
may
be
be
having
trouble
understanding
some
some
of
the
wording
that
we're
using.
B
B
There's
also
a
little
bit
of
tool
work
needed
so
that
there
is
one
issue
that
describes
how
to
actually
make
the
the
co-occurrence
constraints
of
the
json
schema
inspired
part
of
the
ctdl
a
little
bit
more
tight.
But
we
cannot
do
this
at
the
moment,
because
the
tool
that
translates
cdl
into
json
schema
org
doesn't
support
this
this
kind
of
structure.
So
we
we
will
need
to
fix
this
scenario
or
do
it
by
hand,
but
that's
really
not
something.
I
would
want
to
do
way
too.
Many
way
too
much
potential
for
errors.
B
Okay,
so
there
are
a
little
set
of
items
that
are
not
in
the
the
next
future
work
block,
but
that
that
maybe
we
should
look
at
do
we
want
to
do
this
now
or
leave
it
for
future
work.
One
is
that
we
have
a
version
field
in
the
info
block.
B
We
all
know
that
versions
are
hard
and
versions,
usually
give
us
much
less
than
they
do.
But
if
we
have
a
version
of
you,
then
it
should
have
at
least
some
reason
for
existence
and
right
now
it's
not
really
defined
how
you
would
use
that
there
is
a
suggestion
that
that
it
starts
with
an
rfc,
339
or
iso
8601
date.
B
So
you
can
order
versions
lexicographically,
but
we
may
want
to
make
a
tighter
definition
of
what
the
version
field
would
be.
So
that's
one
thing
we
want
to
look
at
and
the
other
thing
we
may
want
to
look
at
is
when
we
are
combining
multiple
sdf
files
or,
more
generally,
if
we
are
building
sdf
files
out
of
multiple
ecosystem
sources.
B
How
do
we
combine
the
information
in
there
so
right
now?
There
is
only
one
copyright
entry
in
in
the
info
block
by
the
way
there
is
no
no
license
field
in
the
oh,
there
is
a
license
field
in
the
info
block,
but
it's
not
fully
defined
yet
and
so
on
and
by
the
way,
the
the
ops,
a
working
group
is
working
on
a
similar
thing
for
mud
files,
so
they
also
try
to
get
this
metadata
more
more
precisely
defined.
So
you
have
ownership
and
licensing
statements
in
yang.
B
D
Hi
carson
thanks
just
to
comment
on
that,
yeah
that
this
is
a
draft
that
you
and
I
are
writing
and
it's
been
accepted
as
a
working
group
draft
over
knobs
areawg
and
the
intent
at
least
is
for
it
not
simply
to
be
used,
as
you
know,
for
mud
files,
but
rather,
if
you
have
stationary
or
static
json
that
that
you're
concerned,
you
know
you
need
you
need
to
have
a
licensing
statement.
You
just
sort
of
slap
this
in
and
and
it
should
be
general
along
those
lines.
B
Yeah,
so
we
may
want
to
be
compatible
with
this
either
literally
compatible
or
at
least
culturally
compatible.
So
people
will
be
able
to
extract
that
information
in
that
form,
and
that's
probably
something
that
that
we
want
to
pay
a
little
bit
of
attention
to
next.
B
Breadcrumbs
so
we
have
these.
These
processing
model
steps
where
we
we
put
together
specs
out
of
multiple
sources,
and
one
observation
was
that
when
we
do
this,
we
lose
the
information
what
sources
these
actually
came
from,
of
course
that
hurts
in
the
info
block,
as
I
already
said,
but
of
course
you,
you
also
would
like
to
be
able
to
to
find
out
what
what
kind
of
thing
is
this
here?
What
kind
of
property
action
event
is
this
here?
B
Did
this
come
from
this,
or
did
this
come
from
the
other,
so
keeping
some
some
more
more
comment,
level
information,
there's
a
pull
request
for
that
which
maybe
doesn't
quite
have
the
right
shape
yet
and
when
we
later
come
to
mapping
files,
there's
also
there's
also
a
consideration
that
we
may
want
to
keep
information
about
where
parts
of
the
specification
came
from.
B
Of
course,
you
can
just
put
it
into
the
comment
fields,
but
then
you,
you
will
have
a
hard
time
tracing
it
back
so
having
a
little
bit
more
structured
representation
would
be
good.
B
We
may
want
to
write
up
a
little
bit
more
of
our
own
guidelines.
We
used
when
writing
this
spec.
So
when
the
next
version
is
generated,
we
remember
what
those
guidelines
were.
So,
for
instance,
there
is
an
old
issue
that
asks:
when
do
we
use
the
term
sdf
xxx
and
when
do
we
just
use
a
naked
xx?
So
why
is
it
unit
and
not
sdf
unit?
B
B
Yeah,
for
instance,
that
we
have
this
alter
alternation
between
user
defined
names
and
and
sdf
defined
names,
which
we
don't
in
the
info
block,
which
has
an
exception
to
that,
but
everywhere
else
we
do
and
this
this
is
essentially
an
artifact
of
of
the
the
fact
that
jason
has
limited
expressibility.
B
B
Yeah
so
let's
look
at
timelines
and-
and
I
brought
some
rose-colored
glasses
for
you
to
look
at
those
timelines.
B
Everything
I
have
talked
about
here-
we
can
do
this
here
and
if
this
turns
into
substantive
changes,
then
we
probably
want
to
have
another
implementation
graph,
which
would
be
sdf
1.2.
So
people
can
actually
touch
their
tools
and
converters
and
so
on
to
make
sure
they
actually
work
with
the
next
version.
B
We
don't
make
substantive
changes,
then
we
can
continue
calling
this
sdf
1.1
and
don't
have
a
transition
in
the
tool
space,
and
if
we
have
the
implementation
draft
this
year
we
probably
will
have
a
few
units
to
fix,
and
then
we
should
be
able
to
do
a
work
group
last
call
in
mid-january
and
should
be
able
to
process.
The
working
group
call
comments
up
to
well
early
february
or
something
and
if
shepard
and
ad
are
fast,
we
could
actually
have
an
iitf
last
fall
during
february.
B
B
So
this
is
what
I
want
to
achieve
here
and
we
will
have
to
see
whether
we
we
can
make
it
do,
but
I
think
we
should
not
take
yeah
and
authors
are
fast
francesca.
Indeed,
we
should
think
about
whether
we
take
up
and
any
significant
changes
that
would
jeopardize
this
timeline
here.
A
So,
thank
you
kirsten.
I
mean
this
sounds
great,
sir.
Was
there
anyone
in
the
queue?
No?
This
sounds
really
great.
Thank
you
for
making
all
this
progress.
Do
you
think
that?
Because
we
had
these
the
first
ones
on
this
pr45
and
the
namespace
issue,
I
guess
we
can
resolve
them
within
that
shouldn't
be
a
show
stopper
that
needs
to
be
resolved
somehow,
but
they
are.
They
are
not
really
show
stoppers
right.
A
Great
out
of
this,
do
you
think
we
should
have
interim?
A
B
B
Can
schedule
them
now
and
if
we
decide
we
we
got
by
without
them
we
can
just
cancel
them.
A
Yeah,
so
let's,
let's
figure
out
how
to
scale
them
afterwards.
I
think
we
can
do
that
with
a
doodle
or
something
great,
no
comforter
comments
on
this
or
questions.
A
I
hope
everybody
will
read
the
specification
and
figure
out
lots
of
questions,
so
we
can
stretch
them
quickly,
great,
let's
move
on
then
I
think
we're
actually
ahead
of
schedule
here
for
a
couple
of
minutes.
So
that's
really
good.
A
So
we
we
talked
before
about
sort
of
things
that
is
related
to
the
basic
sdf
spec,
but
it's
sort
of
extending
it
slightly.
So
a
couple
of
topics
has
come
up
and-
and
this
is
the
first
one-
carson
go
ahead.
B
Yeah
so
early
in
the
development
of
sdf,
we
found
out
that
there
is
some
ecosystem,
specific
information
that
the
ecosystems
want
to
put
into
the
sdf
model,
which
makes
it
hard
to
actually
have
harmonized
models,
because
each
time
an
ecosystem
starts
to
use
a
harmonized
model.
We
would
have
to
add
information
to
to
that.
B
Data
that
actually
hook
into
the
main
document
in
the
html
document
or
the
xml
document
in
this
case
and
provide
additional
information,
and
we
have
discussed
these
for
a
while
and
and
have
been
thinking
about,
applying
css
concepts
or
something
like
that
to
it.
But
actually
it
turns
out
that
the
the
what
we
need
seems
to
be
much
simpler,
and
I
have
tried
to
write
this
up
in
a
first
draft
before
this
meeting.
B
So
it's
structurally
still
in
sdf
spec.
But
it's
not
what
you
actually
would
would
harmonize
in
an
organization
like
1dm.
It
just
has
information
for
from
one
or
more
ecosystems
added
to
the
base
harmonized
specification,
so
a
mapping
file
essentially
would
start
with
the
same
info
block
and
the
same
namespace
management,
namespaces
and
default
namespace
sections
that
you
have
in
a
normal
sdf
spec.
But
the
rest
would
just
be
a
sequence
of
pairs
or
a
map
actually
in
the
json
object
that
maps
a
joys
adjacent
pointer
into
the
sdf
spec
to
new
qualities.
B
That
would
be
added
at
this
point
in
in
the
spec.
So
it's
like
a
set
of
editing
instructions,
except
that
the
amount
of
editing
you
can
do
is
is
limited
there
and
that
that's
all
pretty
obvious.
I
mean
this
should
work
very,
very
easily.
B
B
So
here's
an
example
where,
where
we
have
an
ipso
mapping
for
for
an
sdf
specification-
and
if
so
has
these
these
object
and
resource
ids,
so
that's
something
that
is
really
specific
to
to
ips
so
oma
lightweight
mtm.
So
it
should
really
be
the
purview
of
of
those
ecosystems
to
define
these
additional
qualities.
It
should
not
be
something
that
they
have
to
run
to
to
the
asdf
working
group
or
fill
in
a
registry
with
stuff
each
time.
B
B
So
next
slide.
We
did
the
same
thing
for
the
web
of
things
thing
models
we
didn't
do
it
for
the
thing
descriptions,
obviously,
because
that
has
instance,
information,
which
is
a
separate
item
on
our
list
today
and
yeah.
We
immediately
fell
into
the
trap
here
of
using
the
wrong
namespace,
because
the
namespace
really
should
be
the
namespace
of
of
the
model
that
we
are
augmenting
and
the
the
namespace
that
is
listed
here
is
actually
the
one
in
which
the
terms,
titles
and
descriptions
are
defined.
A
B
B
Okay
yeah,
so,
but
my
my
diagnosis
at
the
moment
is
we
haven't
painted
ourselves
in
a
corner,
yet
we
we
can
make
these
mapping
files
work
and
they
can
be
simple
and
the
next
step
will
be
using
them
in
more
converters.
B
Well,
the
the
one
thing
where
they
touch
the
main
thing
where
they
touch
is
in
the
area
of
qualities.
How
do
we
maintain
this
quality
space
and
similar
to
units
where
we
have
sdf
defined
values
and
other
values?
We
might
want
to
do
the
same
thing
for
quality
names
so
that
that
actually
changes
the
the
data
model
of
sdf
somewhat,
but
in
in
a
limited
way.
I
think.
A
A
But
okay,
there
is
nothing
here.
At
least
that
prevents
us
from
moving
on
with
sdf
specification
asses.
B
A
I
guess
people
are
burnt
out
after
a
full
week,
then
we
move
on.
A
Yeah
we
had
a
bitter
problem
because
ari
was
supposed
to
present
this
and
he
had
to
drop
at
the
last
minute
for
from
other
non-work
stuff.
I
think
so.
Well,
let's
see
I
can
maybe
it's
do
you
want
to
talk
to
it
kirsten
or
I
can.
A
B
Resources
and
links-
it's
probably
a
good
idea
to
think
about
how
links
would
improve
our
situation
in
sdf
and
yeah.
Looking
at
the
the
way
we
are
using
links,
we
already
have
them
in
in
sdf,
ref
and
so
on,
but
maybe
we
should
have
a
little
bit
of
a
wider
look
at
this
and
there
are
some,
of
course,
some
implicit
links,
the
parent-child
relationship
within
the
tree
structure
of
the
sdf
specification.
That's
obviously
a
form
of
link.
B
B
I'm
always
wanted
wanting
to
say
things,
but
this
is
not
the
right
word,
so
so
concepts
are
linked
in
more
interesting
ways
than
just
inclusion
and,
for
instance,
the
if
we
have
a
heater
there's,
maybe
a
boiler
somewhere
that
we
we
want
to.
That
has
a
temperature
that
we
want
to
read
of
that
boiler
or
if
there
is
a
switch,
a
light
switch,
then
probably
there
is
a
light
somewhere.
B
B
So
we
have
to
be
really
careful
about
what
kind
of
link
we
are
really
talking
about
and
when
we
have
a
link,
then
of
course
you
want
to
have
a
link
relations
with
that
that
describe
what
this
link
is
about
and
in
the
web
world
we
have
a
link
relations
registry
and
that's
essentially
the
predicate
of
an
ontology.
If
you
look
more
closely
at
it
and
you
may
want
to
put
in
other
information
like
cardinality
and
so
on,
and
what
fits
into
the
target
position
for
the
link
and
so
on.
B
So
let's
look
at
the
example
on
the
next
slide,
so
here
we
have
a
robot
arm
that
is
somehow
highly
related
to
some
other
robot
arm.
So
these
arms
are
not
just
there
and
like
shipping
ships
in
the
night,
but
they
need
to
know
about
each
other,
or
at
least
that
in
this
example
arm
a
needs
to
know
about
arm
b.
So
you
want
to
be
able
to
say
that
there
is
a
relation
here
to
something
that
is
of
sdf
type
sdf
thing:
robot
arms
sdf
object
rb.
B
B
So
the
the
instance
relations,
for
instance,
might
be
a
light,
switch
controls,
a
particular
light,
and
that
relation
is
something
like
like
a
property
in
in
some
way,
but
it's
also
an
affordance.
You
would
exercise
in
a
different
way
than
a
normal
property.
So
if
you
know
the
light
switch
is
on
or
off
that
that's
of
a
different
quality,
then
you
know
knowing
what
light
that
light
switch
actually
is
controlling.
B
B
So,
in
a
thing
description,
they
didn't
have
to
do
the
the
intellectual
work
of
separating
out
qualities
that
describe
a
specific
instance
and
qualities
that
are
similar
enough
between
all
these
instances
that
you
might
want
to
put
it
into
a
class
yeah,
so
class
kind
type
in
since
next
slide.
We
we
need
to
work
on
on
the
words
we're
using
for,
for
this
there's
only
a
limited
number
of
english
words
and
many
of
them
have
connotations
or
previous
uses
that
make
them
difficult
to
use.
B
B
Tree
structure
of
the
model,
so
we
could
have
the
ability
to
give
identities
identifiers.
Whatever
two
instances,
we
could
describe
the
the
purpose
of
life
relations
between
the
instances
yeah,
I
don't
understand
the
last
bullet.
Of
course
you
want
to
be
able
to
to
put
all
the
qualities
that
are
in
what
thing
description
into
this
instance
definition.
A
A
A
B
Yeah
next
slide
yeah
I'm
trying
to
take
her
yeah
okay,
so
this
looks
almost
the
same
like
what
we
already
had.
But
the
point
is
here
now
we
have
a
specific
name
or
id
for
the
thing
for
the
instance,
so
the
instance
is
is
not
an
instance
of
a
specific
state
of
the
thing
which
is
yet
another
way
of
of
going
down
one
one
turtle,
but
it's
it's
the
description
of
the
instance.
So
it's
on
the
same
level
as
what
thing
description
and
we
would
have
the
vocabulary
here
to
do
this.
B
E
So,
just
right
back
on
that
last
slide
is
a
good
segue,
where
he
says
instance
of
I
think
what
the
main
difference
between
what
ari
would
would
was
proposing
and
what
I'm
proposing
and
different
approaches
that
not
so
different.
E
E
E
So
you
can
either,
as
carson
said,
make
a
thing
and
make
everything
sub
parts
of
the
thing
or
do
something
that's
a
little
more
level
and
not
so
hierarchical,
and
we
find
that
very
often.
We
need
to
do
the
hierarchical
thing
and
can't
just
make
it
all
level,
because
also
we
have
to
describe
communication
between
things
and
and
how
they're
connected
not
so
much
communication,
always
in
the
digital
form,
but
how
they're
connected
in
the
application
graph.
E
So
objects
are
connected
and
related,
and
so
this
is
a
way
to
basically
make
your
application
graph,
portable
and
retargetable.
So
I
could
cast
it
on
to
retarget
it
onto
oma,
lightweight
m2m
objects,
just
by
filling
in
the
object
links
to
to
at
runtimes
or
at
generation
time.
When
I
generate
the
actual
runtime
thing
and
put
protocol
bindings
in
at
that
time,
I
would
generate
the
actual
links
and
assign
the
namespace
ids
if
I
needed
to,
if
they
weren't
already
done
and
then
do
the
on
the
air
schemas
and
protocol
binding.
E
E
I'll
just
see
questions
at
the
end,
so
I
wanted
to
also
talk
about
a
little
bit
about
the
language
specific
features
that
we're
talking
about
and
what
we
only
need
to
do
is
more
than
just
breadcrumbs.
There
are
places
where
we
need
to
use
the
json
pointer
to
an
sdf
definition
in
specific
ways
that
aren't
just
expanding
it
like
sdf
ref
does,
but
rather
to
use
it
in
relations
and
in
the
composition
that
I
was
just
talking
about
to
build
application
graphs.
So
really
sdf
is
the
best
thing.
E
You
know
the
dependency
here
on
our
our
first
release
would
be.
Do
we
really
want
to
keep
calling
it
sdf
ref,
because
sdf
ref
from
doesn't
really
capture
the
meaning
in
my
opinion,
and
we
really
need
to
think
about
whether
we
want
to
say
sdf
expand
or
something
like
that,
and
you
know
we
have
this
discussion
and
you
know
maybe
it's
too
late
and
we
can't
really
rename
sdf
ref,
but
really
if
there
is
a
last
opportunity
it's
now
and
the
window
is
going
to
close
with
1.2,
so
it's
kind
of
too
bad.
E
We
already
use
it
so
much,
but
actually
I
think
it
might
make
sense
to
use
sdf
ref
for
the
thing
that
is,
does
not
do
expansion
and
invent
a
new
term
for
the
one
that
does,
but
we
need
more
discussion
on
this
next
slide.
Please,
okay,
another
feature
the
semantic
links
is,
I
see
them.
They're
semantic
links,
they're,
subject,
predicate
object,
triples
and
you
know
their
web
links
work.
That
way
too
so
subject
is,
though,
always
pretty
much
the
present
definition.
We
don't
necessarily
need
a
context
override
or
quads
or
anything
like
that.
E
One
sdf
object
to
another,
and
sometimes,
if
you're,
for
example,
lightweight
m2m,
you
just
need
to
constrain
what
kind
of
objects
you
can
point
to
when
you,
when
you
build
your
instance
graph,
your
implementation,
so
a
lot
of
it
is
is
using
these
references
in
links,
but
but
wanting
to
be
able
to
describe
it
with
a
predicate
that
says,
you
know,
target
type
or
something
like
that
right,
so
also
they
can
be
external
references,
though,
that
are
just
any
old
uri,
so
we
want
to
be
able
to
integrate
with
rdf
using
this
pattern
as
well.
A
E
Protocol
binding
yeah-
this
is
just
okay,
carson
already
covered
this,
so
this
is
basically,
but
I
wanted
to
say.
One
thing
is
that
I
did
an
experiment
where
I
I
used
the
web
of
things:
protocol
binding
vocabulary
as
a
sdf
extension
using
the
vocabulary,
extension
technique,
similar
to
what
almost
identical
to
what
carson
showed
earlier
and
then
used
that
to
generate
tds,
and
that
was.
I
found
that
to
use
it
as
an
annotation
on
sdf
and
then
use
it
in
the
generations
to
be
very
good
workflow.
I
think
that's
the
last
slide.
E
B
But
apart
from
that,
I
think
we
have
very
similar
ideas,
and
I
think
that
the
what
thing
description
is
is
really
a
nice
benchmark
that
we
can
use
here,
because
it
is
at
the
instance
level,
and
we
can
make
sure
that
that
the
the
levels
of
turtles
we
we
built
here
actually
is
able
to
reach
down
to
that
thing
description.
So
let's
have
that
interim.
A
Okay,
thank
you,
and
that
was
the
last
of
our
presentations.
I
think
that
actually
segues
quite
nicely
to
your
setting
up
the
next
interims,
michael,
michael,
rich
or
something
I
gave
you
two
seconds.
C
Into
the
channel
into
the
jabber
and
into
the
minutes,
a
doodle
poll
for
virtual
interims
in
december
january
and
february,
so
we'll
pick
one,
not
not
sorry.
We're
gonna
pick
three
values
from
that
that
there
are
several
weeks
and
I
believe,
if
I'm
not
mistaken,
I
have
picked
the
hour
before
the
one
dm
meeting,
which
I
recognize
is
early
for
michael
koster
and
the
hour
afterwards,
which
is
now
getting
into
late
in
europe
on
the
monday
or
the
tuesday
of
several
weeks
in
each
month.
C
So
please
pick
them
appropriately,
assuming
that
we
will
pick
three
values
in
there
and
it
sounds
like
we
really
want
a
december
meeting
a
virtual
interim
and
that
we
possibly
might
cancel
or
skip
january
depending
on
how
well
we're
doing
with
shepherding
and
other
things,
but
that
we
absolutely
want
a
february
virtual
interim
to
deal
with
any
issues
arising
from
a
possible
working
group.
Last
call
that
might
have
occurred
after
the
occurred
in
january,
and
we
had
previously
done
90-minute
meetings.
C
I
think
we
should
try
to
stick
to
more
frequent
60
minutes
and
get
right
into
things.
Yes,.
A
C
A
Well,
two
seconds
right,
just
a
quick
thing
here,
milestone
review:
we
are
developing
sdf
according
to
milestone.
We
are
slightly
we're
supposed
to
be
sending
it
on
on
in
september.
A
We
are
on
track,
but
with
a
slight
delay,
of
course,
and
during
this
work
well
identified
additional
interesting
work
like
the
one
we
just
discussed
on
on
protocol
mappings
and
relationships
and
instances,
and
we
need
to
figure
out
whether
that
fits
within
the
big
document,
a
simple
extension
so
that
or
whether
we
actually
need
to
have
more
complicated
extensions,
which
would
then
sort
of
be
beyond
the
scope
of
of
the
asdf
group.
A
But
if
that
happens,
we
will
start
looking
at
the
sort
of
need
to
recharter
and
of
course,
we
would
also
like
to
be
around
long
enough
to
that.
We
could
have
at
least
one
face-to-face
meeting
during
the
lifetime.
A
You
thank
you
all.
Thank
you
for
attending
have
a
great
you
know,
final
hour
and
a
half
of
iotf
meetings,
it's
time
and
see
if
some
of
you
on
your
dreams
and
some
of
you
at
the
next
face-to-face
meeting
or
whatever,
whatever
happens
with
that
time.
Thank
you
very
much.
Bye,
great.