►
From YouTube: IETF-T2TRG-20220519-1300
Description
T2TRG meeting session at IETF
2022/05/19 1300
https://datatracker.ietf.org/meeting//proceedings/
A
C
Yes,
I
think
so
yeah
by
the
way
can
I
control
the
changes
of
slides
or
you
need
to
do
that.
Okay,
good.
D
D
Exactly
exactly
actually
and
milani
if
you're,
okay,
I'll
revoke
the
screen
sharing
for
a
second
I'll,
try
to
share
the
agenda
page.
D
D
A
D
D
Okay
but
yeah,
let's,
let's
get
started,
and
while
we
wait
for
others
to
join
so
the
agenda
for
today-
and
this
was
really
a
draft
agenda
that
we're
very
happy
to
bash
now
in
the
in
the
beginning
of
the
meeting,
we
had
at
least
four
different
items
that
we
could
continue
the
discussions.
First
was
this
id
information
model
standards
description,
the
work
that
milan
has
been
driving
for
quite
some
time,
but
we
haven't
had
a
chance
to
discuss
it
for
for
a
moment.
D
Another
thing
that
would
have
been
on
discussions
in
various
tinting
archie
or
I
was
this
documentation
of
the
learnings
of
the
iot
data
online
design,
especially
versioning.
D
So
we
have
been
doing
quite
a
lot
of
that
work
in
the
stf
context
and
earlier
before,
we
have
noticed
that
there
are
recurring
things
that
are,
you
know
good
learnings
from
this
activity.
That
would
be
very
good
to
document.
It's
not
like.
We
have
the
final
truths,
but
at
least
we
have
some
good
ideas
on
things,
taking
considerations
so
how
we
could
get
going
on
on
that
activity.
D
Then
we
had
two
weeks
ago.
I
think
doing
research
group
work
meeting
on
topic
of
digital
twins
and
idf
technologies.
In
that
meeting
we
already
noted
that's
okay,
a
few
things
we
didn't
have
time
to
discuss
that
we
could
perhaps
follow
up
in
in
this
meeting
and
then.
Finally,
if
we
have
time,
we
could
be
talking
about
the
sdf
future
evolution.
So
stf
has
been
a
recurring
topic
in
the
industry
meetings,
especially
looking
looking
beyond
the
asdf
group
charter
on
what
should
the
sdf
contain
and
what
should
be
doing.
E
D
D
D
There
should
be
controls
at
the
bottom
of
the
slides,
for
you.
C
D
C
So
this
is
the
quick
update
on
the
work
on
iot
standards,
normalized
description
or
whatever.
We
want
to
call
it,
and
it's
been
going
on
for
a
while.
As
already
pointed
out,
I
think
it's
been
almost
a
year
since
the
last
update,
so
the
new
news
is
that
version
two
of
the
paper
has
been
posted.
I
read
it
up
quite
significantly,
it's
basic
same
basic
idea,
but
but
it's
a
pretty
printed
and
some
things
I
added
and
sections
sort
of
rearranged
and
and
that
version
is
posted
on
the
wishy
github.
C
So
it's
it's
available
for
view
and
I'll
have
to
work
with
custom
to
to
move
it
to
cram
down
later
and
then
get
away
from
the
xml
encoding.
But
I
didn't
have
the
time
for
that.
It's
arcane
tools,
as
you
know
anyway,
so
the
nutrition
label
is
now
entitled
and
I'll
mention
a
bit
later.
Why
you
know
we
may
want
to
keep
it
so
for
today
the
decisions
we
need
to
make
harry
and
carsten
actually
most
larry
and
I
have
been
discussing
when
and
where
to
publish
it.
C
C
Yeah,
I'm
sort
of
fuzzy
on
on
the
distinction
between
the
two.
I
I
fuse
them
in
my
mind,
but
never
mind
that,
and-
and
the
call
to
action
for
today
is
basically
please
please,
please
provide
feedback
as
you'll
see
later.
The
paper
is
structured
in
the
introductory
discussion
of
data
models
and
information,
modeling
and
presentation
which
all
of
this
group
knows,
and
so
you
can
ignore
that
part.
C
You're
welcome
to
comment
on
it,
but
just
please
review
the
questions
and
more
or
less
the
categories
along
which
we
propose
to
describe
the
standards
for
commonality,
and
that's
a
very
easy
and
quick
read.
So
I
would
appreciate
comments
it's
on
pages
11
through
16,
in
the
pdf
version
for
those
who
want
to
skip
the
rest
and
contributions
are
solicited,
as
we
said
before,
co-authors
are
welcome.
C
Acknowledgements
will
be
given
to
people
who
comment
you
know,
depending
on
the
level
of
contribution
we'll
do
one
or
the
other,
but
basically
it's
meant
to
be
a
group
paper,
not
my
thing,
since
it
has
been
a
year
since
we,
the
last
update,
almost
just
to
remind
you,
the
notion
was
to
create
a
informational
paper
draft
that
describes
key
features
of
iot
data
standards,
mostly
those
referring
to
infrared
infinite
metamodels
in
a
consistent
manner,
so
basically
have
a
set
of
categories,
some
sort
of
categorization
and
some
key
questions
to
address,
in
common
terms,
with
the
notion
of
being
helping
to
understand
the
landscape
of
these
standards.
C
For
those
who
are
not
intimately
involved
in
defining
them
and
to
give
a
high
level
sort
of
description
in
a
common
format,
because,
as
you
know,
that
they
have
their
own
sort
of
nomenclature,
terminology
and
approach,
and-
and
at
least
my
experience
has
been
very
difficult
to
compare
across
them-
requires
a
lot
of
reading
and
digging
on
terminology
before
you
can
start
to
do
that
which
is
frustrating
for
for
those
who
are
marginally
involved.
I
think
they
give
up
sooner
than
they
should
so.
C
The
idea
was,
by
doing
this,
to
to
basically
be
usable
to
researchers
and
iot
practitioners,
not
the
sdo
people
who
work
on
an
sdo
and,
of
course,
share
the
common
frame
and
reference
that
has
been
evolved
over
the
meetings,
and
they
all
understand
each
other
more
or
less.
At
least
they
use
the
same
terms
and
and
by
the
rest
of
the
world.
C
Not
necessarily
specifically
excluded
were
not
to
describe
the
details
of
inner
working
of
the
proposal,
just
the
general
categories
that
are
outlined
later,
and
it's
not
meant
to
be
a
judgment
in
terms
of
you
know
what
is
better
than
the
other,
or
anything
like
that.
C
It's
basically
just
to
understand
them
by
having
them
explicit,
explicitly
state
their
choices,
that
they
have
made
the
design,
chases
and
scope
and
approach-
and
this
was,
I
think,
I
don't
know
between
castell-
I
don't
remember,
but
one
of
us
suggested
both
of
us
to
basically
think
of
it,
like
the
nutrition
label
that
you
have
on
the
food
package
that
tells
you
sort
of
in
a
standard
way.
What
are
the
ingredients?
C
C
Mentioned
was
actually
published
on
a
public
domain
on
archive
or
archive,
depending
how
you
spell
your
greek
in
march
of
2018.
It
was
more
like
okay,
let's
do
this
thing
and
they
published
a
draft
of
their
ideas
of
how
the
standards
should
be
described.
Then
they
had
group
activity.
I
know
microsoft
was
involved
also
in
a
number
of
researchers
from
different
organizations,
and
then
they
collated
the
results
and
published
a
paper
on
that
in
in
this
issue
of
cacm,
and
I
also-
and
they
mentioned
there-
and
I
have
noticed
on
archive.
C
So
the
action
plan
that
I
propose-
or
at
least
I
partly
tend
to
follow,
is
is
to,
as
I
said,
solicit
feedback
and
revise
based
on
on
wishy
feedback
and
make
it
available,
probably
as
an
iatf
draft.
We
kind
of
it's
written
in
that
format.
So
so
it's
an
easy
thing
to
do,
and
I
was
thinking
of
possibly
putting
it
on
an
archive
repository
which
has
a
bit
wider
reach
among
the
researchers,
but
I'm
not
sure
whether
duplication
would
help
or
hurt.
C
Whatever
the
group
is
on
some
things
like
this
or
reference
architectures,
I
have
a
draft
iot
reference
architecture
that
I
want
to
put
there,
but
it
the
main
point
would
be
to
get
the
group
consensus
and
opinion
on
some
topics
that
are
of
interest
or
recently
edge
computing.
I
don't
know
how
many
papers
and
definitions
you
have,
or
rather
papers
that
talk
in
detail
about
edge
without
specifying
what
they
mean.
There's
at
least
half
a
dozen
different
interpretations.
C
C
And
finally,
my
final
foil
is
just
in
terms
of
what's
in
the
paper.
As
I
said,
the
draft
is
written.
It's
basically
has
introduction
and
overview
statement,
definition
of
data,
standard
models
and
practices,
or
rather
the
approach
in
terms
of
object-oriented
data
attributes,
thing
types,
object,
types
etc,
which
this
audience
knows.
C
So
you
can
skip
that
unless
you
just
want
to
comment
on
on
the
phrasing
and
then
the
suggested
list
of
items
categories
along
which
to
describe
standards
with
some
with
a
few
paragraphs
on
each
of
what
is
meant
into
that
category
and
how
to
approach
describing
it.
So
it's
basically
objectives
and
purpose
of
of
the
thing
there
are
more
details,
but
there
is
a
domain
of
usage.
C
One
of
the
problems
I've
seen
is
that
some
stos
have
very
ambitious
goals
in
terms
of
domain
of
usage,
how
wide
domain
they
tend
to
cover,
but
they
actually
defined
object
types.
A
much
narrower
domain,
so
it
would
be
nice
to
define
what
has
been
defined
and
what
are
the
future
targets
for
the
domains.
It
would
help
to
understand
it
better
and
the
environmental
assumptions
I'm
suggesting
basically
what's
assumed
to
be
in
place
to
make
a
particular
specification
work
in
terms
of
serialization
protocols,
communication
protocols,
if
there
are
security
assumptions,
etc.
C
Some
of
them
make
implicit
assumptions
that
are
not
stated,
which
makes
it
difficult.
It's
good
to
make.
Those
explicit
and
also
sort
of
by
inference
indicate
or
explicitly
articulate
what
is
not
defined
and
basically
is
left
to
the
implementers
to
fill
in
when
implementing
a
particular
approach
and
the
terminology
in
terms
of
the
common
categories
commonly
used
versus
the
one
that
they
use
if
they
deviate
like
ipso
uses
resources
for
what
the
other
called
attributes
and
stuff
like
that,
and
there
is
also
would
be
nice
category-
I
I
don't
know
what
to
call
it.
C
We'll,
probably
rephrase
that
of
more
interest
to
potential
adopters
than
the
general
audience,
such
as
metadata
handling.
I'm
not
sure
metadata
handling
could
probably
go
into
the
general
category
in
the
sense
of
there's
a
lot
of
need
for
metadata
in
iot
system
implementation
and
some
of
the
metadata
comes
into
life
in
the
implementation
actually
in
commissioning
and
installation
phase,
such
as
structural
relationships
between
things
and
some
standards
define
the
metadata
certain
metadata
as
part
of
their
object
definitions.
C
But
the
question
here
is:
okay:
what
do
you
do
with
others?
If
you
want
to
add
more
data
data,
can
you
make
it
like
an
orthogonal
overlay
or
basically
how
you
deal
with
it,
because
what
they
define
is
quite
rudimentary
in
in
terms
of
actual
implementation
and
the
other
more
implementation
oriented
stuff
is
creation
of
new
object
types?
How
are
new
object
types
created?
C
Basically,
do
you
have
to
wait
for
the
standard
group
to
define
it
in
order
to
use
it,
or
can
you
propose
new
one
and
crowdsource
it
like,
for
example,
ocf
and
haystack
do
also
development
considerations,
basically
such
as
tools
or
languages
to
use
other
reference
implementations
and,
if
so,
what
they
are
always
to
be
found
and
and
possibly
licensing
terms
in
terms
of
do
you
have
to
be
a
member
of
the
group?
Do
you
have
to
pay
to
use
the
license
definition,
or
is
it
public
licensing
terms?
C
D
Okay,
very,
very
good
thanks
a
lot
milan!
Maybe
a
first
question:
have
you
now,
do
you
have
a
kind
of
first?
You
know
kind
of
stable
version
of
the?
What
to
do
don?
Have
you
actually
applied
this
yet
to
any
of
the
models
out
there
and
see?
How
does
it
look
like.
C
I
have
sort
of
done
the
paper
application
of
that,
but
I
would
really
need
to
work
with
with
people
who
are
more
closely
involved
with
stos,
like
I
have
done,
based
on
the
reading
ocf
and
empty,
but
it's
not
in
the
paper.
It's
it's
in
my
notes.
B
Yeah,
I
think
it
would
be
a
good
idea
to
actually
schedule
a
set
of
interviews
at
some
point
in
time
where
we
get
actual
experts
for
the
various
seos
and
ecosystems
to
to,
and
we
together
fill
this
in
because
a
lot
of
these
things
you
you
only
really
can
find
out
if
you
talk
to
an
actual
expert
and
if
you
actually
talk-
and
it's
not
just
enough
to
send
them
something
to
fill
in
because
they
will
fill
in
something
that
that
comes
from
the
their
perspective
and
that's
not
actually
useful.
B
But
I
think,
since
you
already
have
something
written
up,
it
should
be
possible
to
do
these
interviews
and
I
would
certainly
be
interested
being
part
of
that
interviewing
approach.
C
B
Well,
even
if
we
share
that
draft
with
them,
that
doesn't
mean
they
understand
what
we
mean.
So
essentially
we
need
to
run
the
the
actual
interview
in
a
way
that
doesn't
really
assume
anything,
but
I
think
it's
also
yeah,
because
you
see
to
to
give
them
the
current
state
of
the
document
beforehand,
without
asking
them
to
to
necessarily
react
to
that
before
we
have
talked
to
each
other.
C
I
agree
by
the
way
in
this
paper
that
I
mentioned
data
sheets
for
data
sets.
They
did
exactly
that
and
they
actually
in
the
paper,
have
a
description
of.
I
think
two
models.
Basically,
two
data
sets
that
have
been
described
along
this
line,
so
it
should
be
part
and
parcel
of
this
thing
when
we
are
done
with
it.
B
Yeah
one
can
do
this
in
a
very
researchy
way,
with
some
some
coding
of
various
items
and
so
on.
B
So
I
I
once
supervised
the
phd
thesis
where
that
actually
was
done
and
it
was
extremely
useful.
But
I
think
we
want
to
keep
this
at
a
slightly
lower
level
of
effort,
and
so
I
think
we
we
essentially
after
each
of
these
interviews.
We
should
do
two
things.
One
add
the
information
from
the
interview
and
to
look
at
the
structure
of
the
document,
whether
we
have
learned
something
about
how
this
project
can
be
improved
and
then
go
to
into
the
next
interview.
C
E
I
did
have
something
else
in
mind
and
I
was
wondering
whether
it
would
be
appropriate
to
go
beyond
just
the
sdos,
because
we
only
have
a.
I
honestly
only
have
a
few
sdos
that
people
are
going
to
be
looking
at
if
they're.
Looking
at
you
know,
I'm
you
know
I
okay
the
table
the
table
I
made
years
ago
that
had
like
16
columns
in
it
most
of
those
aren't
really
viable
candidates
that
they,
just
they
were
just
there
for
sort
of
technical
backup.
E
C
B
B
So
it
might
also
be
interesting
to
see
what
their
make
or
take
decisions
have
been
so
where,
where
did
they
actually
import
things?
And
where
did
they
go
ahead
and
define
their
own
thing?.
B
That's
actually
true
for
for
all
the
groups,
because
all
the
groups
of
course
have
seen
what's
happening
around
them
and
have
been
importing
things
from
from
other
places,
and
so
it's
a
really
complicated
web
of
make
or
take,
and
I
think
one
could
learn
a
lot
from
from
actually
examining
that
network.
E
So
that
was
really
my
thought
as
a
person
entering
this
space.
That
would
be
my
motivation.
I
would
want
to
be
making
those
decisions,
so
this
information,
I
would
expect-
would
really
help
me
get
a
lot
closer
to
being
able
to
make
those
make
or
take
decisions
that
I
would
be
making
like
in
my
own
product
or
startup
or
whatever.
C
E
C
Way,
michael
for
what
is
worth,
I
was
fiddling
with
my
lge
tv
recent
model
and
I
was
fiddling
with
home
settings
trying
to
get
something
to
work,
which
of
course
it
didn't.
But
it
asked
me
for
the
list
of
ocf
certified
devices
that
I
may
have.
So
I
got
a
chuckle
out
of
that
at
least
it's
getting
to
some
extent
and
it's
lg,
not
samsung.
So
there's
an
effort,
samsung.
E
Is
on
the
with
matter
now
yeah
I
would,
I
would
guess,
and
not
really
doing
much
with
those
cf
in
terms
of
their
own
stuff
but
yeah.
That
is
great
news.
Thanks,
yeah.
B
E
B
Good
milan,
I
think
we
we
should
find
some
some
time,
maybe
in
about
10
days,
to
actually
discuss
how
how
to
progress
on
this.
B
So
this
is
a
very,
very
helpful
input,
but
I
think
we
will
probably
yeah
re-spin
this
a
few
times
and
then
change
the
structure
in
the
form
of
it.
A
few
times
before
we
can
say:
okay,
let's
adopt
this
as
a
research
group
document,
and
actually
I
I
like
being
an
author
of
a
draft
before
adoption,
because
it's
my
decision
how
I
change
the
draft
once
it
is
adopted.
B
D
Good
indeed,
and
then
of
course
like
you
know,
it
makes
a
lot
of
sense
to
publish
that's
a
individual
draft
rather
soon
and.
A
D
The
so
he
just
gets
the
visibility,
and
then
we
can
talk
about
the
research
group
craft
stage
later,
but
no,
but
very
interesting
and
and
and
like
when
it
comes
to
the
interviews.
You
know
I
mean,
of
course
you
know
if
someone
was
very
well,
but
you
know
I'd
be
happy
to
also
you
know
reflect
on
those
together.
C
About
the
background,
it
helps
because
few
people
have
like
you
guys
and
michael
is
an
exception
of
having
an
experience
across
several
definitions
and
seos
and
stuff
like
that.
When
you
do
a
single
one
you
get
to
get
caught
in
in
the
vortex
of
that
particular
group
and
terminology
and
group
think,
and
it's
difficult
to
step
out
and
compare
to
others.
But
that's
why?
Having
a
few
people
on
the
interview
beyond
other
than
just
from
the
group
would
be
great.
D
Yes,
very
good
so,
but
for
the
actual
follow-up
discussions.
Should
we
talk
about
the
logistics
for
for
a
minute
so
with
the
next
bit
and
we'll
probably
say
an
individual
draft,
then
call
for
the
discussions
on
that
and
I
guess
they
discuss
with
a
design
team
or
whatever
what
I
call
it
smaller
meeting
and
would
then
milan
be
the
one
to
invite
that.
B
Yeah,
I
hope
milan
can
can
wear
the
head,
as
we
would
say,
but
of
course
several
people
will
will
be
necessary
to
to
move
this
forward
so
having
something
like
a
group
of
authors
or
a
design
team.
If
not
all,
of
the
the
design
team
people
want
to
be
authors
would
be
a
good
thing,
and
I
think
we
should
start
meeting
after
memorial
day
so
in
week
22nd
and
get
get
some
some
progress.
There.
B
Okay,
I
had
one
one
technical
thing
that
I
just
need
to
mention.
The
word
metadata
is
very,
very
difficult
because
it's
like
talking
describing
the
world
in
terms
of
labels
on
containers
or
something
like
that.
It's
can
be
very
different
things,
so
I
think
we
we
need
to
have
terminology
for
metadata,
and
so
we
can
stop
using
that
term
metadata,
because
it's
just
such
a
wide
term.
C
Have
a
lot
of
opinions
on
that,
but
it
should
be
more
explicitly
articulated
in
the
paper.
I
just
thought
through.
I
I
did
it
from
my
own
frame
of
reference,
which
is
not
necessarily
shared
needs
to
be
explained
because
there's
a
lot
of
nuances,
there
there's
metadata
as
attributes
defined
within
the
standard
specification
and
then
a
bunch
of
it
that
you
can
add
later
something
like
haystack
and
anyway,
it
should
be
more
clearly
defined.
I
I'll
definitely
do
that
and
then
as
a
starting
point,
and
then
we
go
from
there
good.
D
Great
thanks:
I
think
we
have
a
good
way
forward
here
then,
shall
we
move
to
the
next
topic?
Absolutely
okay,
thank
you,
milan,
because
the
next
one
would
be
this
documenting
learnings
on
iot
data,
about
design
and
versioning
and
karsten.
Can
you
take
the
lead
here.
B
Yeah,
but
I'm
I'm
not
really
very
well
prepared,
so
we
we
have
had
within
the
last
two
years
or
three
years.
Actually,
we
have
had
various
discussions
about
versioning
and
you
even
can
can
find
slides
about
versioning
in
the
visual
repository,
and
it
seems
like
since
that
term
comes
up
again
and
again,
and
there
even
is
a
as
a
regular
design
team
in
the
net
mod
working
group
which
which
defines
yang
that
discusses
versioning
of
yang
modules.
B
They
have
been
meeting
every
week
for
like
three
years
now,
this
they're
not
done
so.
I
think
this
is
a
very
interesting
subject
and
I
think
there
are
some
areas
where,
where
I
think
we
we
now
have
some
relatively
stable
knowledge
about
which
approaches
work
and
which
don't-
and
there
are
other
areas
where
we
have
very
different
views.
But
I
think
those
examining
those
differences
can
actually
be
quite
useful.
B
B
Writing
a
draft
that
tries
to
collect
information
that
that
we
already
have
documented
in
some
form,
but
that
seems
to
me
that
we
need
to
do
this
next
and
I
I
tried
preparing
something
for
this
meeting,
but
the
the
wealth
of
of
various
pieces
that
we
already
have
put
together
here
was
a
bit
more
than
I
could
handle
for
this
meeting.
B
So
my
question
really
would
be
who
would
be
comfortable
with
actually
throwing
things
out
in
a
wiki
and
who
would
be
more
comfortable
running
this
as
a
normal
internet
draft
activity,
of
course,
in
on
the
individual
level?
First,
until
we
have
enough
information
that
we
start
agreeing
and,
of
course
the
the
the
objective
would
not
be
to
define
the
one
and
final
ultimate
solution
to
the
visioning
problem,
but
to
have
terminology,
so
we
can
discuss
different
versioning
approaches
in
a
way
that
allows
us
to
to
describe
their
benefits
and
and
perils.
E
We
want
to
sort
of
try
to
explain
a
few
different
ways
of
managing
evolution
of
artifacts
and
not
just
maybe
not
even
just
versioning,
because
like
when
I
was
at
smart
things,
we
didn't
version
things,
we
just
updated
the
thing
and
if
we
broke
it,
we
made
a
new
thing
and
that's
you
know
it's
not
versioning,
it's
like
specifically
not
versioning,
but
that
would
be
part
of
it
too.
Anyway.
It
seemed
feels
to
me,
like
kind
of
the
wiki
approach,
might
be
a
better
way
to
get
started.
B
B
So
yeah,
I
think
doing
this
in
in
a
very
unstructured
way,
is
maybe
the
best
way
to
to
capture
the
brainstorming
kind
of
aspect.
B
Yeah,
there
are
two
talks
that
are
linked
from
that
page,
that
I
think
klaus
talk
is
missing
and
then
we
can
fill
that
in.
D
Good
point
I
actually
uploaded
uploaded
the
slides
recently
because
we
forgot
to
upload
them
originally.
B
B
B
D
Actually,
one
thing
about
what
on
on
the
contributions
I
mean
clark:
klaus,
do
you
think,
would
it
be
possible
to
write
a
paragraph
in
intro
on
the
one
slider
that
you
made?
It
might
be
a
bit
out
of
context
for
someone
who
hasn't
been
part
of
the
discussions.
F
From
my
point
of
view,
I
can
report
two
bits
from
what
is
done
in
practice
and
one
is
sometimes
people
don't
seem
to
care
at
all,
so
they
have
no
no
versioning
or
evolution
scheme
for
their
data
models.
They
just
fix
whatever
they
want
to
change
and
those
who
actually
do
care
do
some
variant
of
what
I
describe
in
my
slides.
B
Yeah,
I
think
that
that
versioning
is
an
area
of
software
design
where
we
have
a
really
heavy
influence
of
process
configuration,
so
people
describe
how
it
should
be
run
and
now
how
not
how
it
actually
will
be
run,
and
so
there
is
a
big
gap
between
them
in
this
gap,
of
course,
destroys
all
the
wonderful
properties
that
that
the
original
design
ahead
and
replaces
them
by
by
some
some
ugly
realities.
B
So
that's
my
main
take
off
of
the
area
of
versioning.
It's
really
easy
to
come
up
with
a
pristine,
beautiful
scheme,
but
the
first
time
it
meets
reality.
It's
not
going
to
survive.
F
What
I've
mostly
seen
in
reality
is
that
there's
an
initial
set
of
data
models
that
people
create
usually
an
extensive
set,
and
then
that
suffices
for
for
the
next
couple
of
decades,
and
maybe
they
do
some
some
backwards
compatible
additions
or
so
or
sometimes,
when
there's
a
big
change
needed,
something
like
we.
We
want
to
change
from
integers
to
floating
point
in
all
our
sensor
properties
and
they
they
just
fork
the
whole
thing
and
do
this
bulk
update
and
call
it
second
generation
or
whatever,
but
the
in
practice.
F
D
B
D
Sorry
yeah,
I
I
think
there
are
two
parts
of
that
one
is
that,
like
okay,
you,
let's
say
a
substantial
new
requirements
come
and
that's
why
you
need
to
change.
The
other
part
is
like
whoops
that
was
a
bad
design
or
like
oops.
We
made
a
mistake-
and
I
I
I've
seen
both
and
and
they're
supervising
many
of
the
of
the
second
one,
and
you
can,
even
quite
after
using
some
models
for
10
years.
D
B
Was
it
actually
it's
a
third,
a
reason
for
a
change
and,
and
that's
actually,
when
you
try
to
merge
in
other
stuff?
I
think
ocf
has
a
lot
of
experience
with
that
aspect.
Fortunately,
they
did
this
before
they.
They
actually
cast
their
their
models
in
stone,
but
for
something
like
like
one
dm
when
when
they
try
to
get
a
new
ecosystem
to
join,
somehow
there
will
be
a
need
to
accommodate
the
the
special
features
of
that
ecosystem.
B
D
D
D
So
I
guess,
would
it
be
the
matter
of
starting
the
wiki
page
drafting
some
of
these
thoughts
down
taking
a
follow-up
in
one
of
the
upcoming
wishing
meetings
and
as
you
see
where
we
are.
B
B
C
D
Let
us
give
a
quick
recap
on
the
digital
twins
meetings
that
we
had
a
couple
of
weeks
ago.
We
had
their
two
main
topic
areas:
one
was
from
the
work
done
in
the
dtc
consortium
and
then
one
was
the
work
done
at
the
ietf.
D
D
That
work
was
mostly
about
modeling
relationships
between
nodes,
and
the
idea
would
be
that
the
nodes
would
be
nodes
in
system
would
be
announcing
the
profiles
they
can
consume
and
serve,
and
then
you
have
this
system
of
systems
you
and
the
persistence
would
look
up
the
models
create
uses
in
the
context,
and
you
would
be
able
to
determine
features
about
the
system
based
on
these
relations,
for
example,
about
trustworthiness
and
the
dtc
folks
who
presented
this.
D
Their
idea
would
be
to
standardize
some
of
these
descriptions
at
the
ietf
and
they
were
uploading
these
early
ideas
in
the
context
of
the
indian
research
group.
D
There
is
an
early
draft
about
this
that
hasn't
been
published
yet,
but
if
I
understood
correctly,
the
next
step
for
them
would
be
to
publish
that
and
then
get
a
bit
of
feedback
thousand
things
within
rg
and
then
take
it,
for
example,
in
the
dispatch
to
the
ietf
side.
If
there
are
needs
to
be
for
standardization,
there
was
a
somewhat
likely
discussion.
Multiple
features
of
that
proposal,
especially
around
discovery
and
dnssd,
and
whether
dnsd
could
be
a
good
solution.
D
Some
discussion,
but
there
is,
you,
know
real
time
for
static
info
where
the
in
estimate
could
be
more
on
the
former
and
the
connects
on
the
ladder.
Some
questions
on
scalability,
etc.
But
I
guess
the
next
steps
here
are
we're
waiting
for
that
draft
to
be
published
and
then
take
the
discussion
from
there.
B
So,
while
you're
talking
about
the
nssd,
there
is
an
interesting
discussion
going
on
in
animal
right
now,
where
they
actually
are
looking
again
at
using
resource
directory
and
to
do
their
discovery
and
probably
need
some
way
of
interaction
between
existing
dns
ssd.
B
I
cannot
call
them
directories,
but
that's
what
they
really
are
and
something
that
that
is
based
on
core
resource
directory.
So
if
you
are
interested
in
this,
maybe
you
should
peek
into
the
anime
working
group.
So
this
is
a
bit
of
topic
on
digital
twins,
but
I
think,
since
the
nssd
came
up,
I
think
that's
useful
pointer.
D
Great
thanks,
carson,
there's,
no
more
comments
or
questions
this.
I
could
jump
to
the
idf
work
so
for
the
idf
rtf
related
work
around
these
that
wins
carson
gave
an
a
short
introduction
to
the
work
happening
at
the
network
management
research
group
on
network
digital
twins
and
then
on
the
idf
side,
work
we're
doing
on
sdf
in
the
1dm
and
asdf
groups.
D
Then
we
had
two
more
specific
presentations
around
using
iedf
technologies
for
big
dot
means
one
was
around
digital,
twin
definition,
language,
so
the
language
that
is
used
on
the
azure
platform
for
describing
digital
twins
and
in
particular,
how
we
can
be
converted
to
sdf
and
through
sdf
to
the
other
models
that
we
have
been
working
on
and
short
summaries
that,
like
eighty
percent
of
things
not
easily
as
it
tends
to
be
across
across
different
languages
and
models
in
different
ecosystems.
D
But
then
there's
a
remaining
20
percent.
That
needs
a
bit
more
attention,
but
overall,
it
seems
to
be
sdf
seems
to
be
quite
good
fit
for
this
kind
of
digital
twin
languages
like
like
ptdl,
and
one
thing
that
was
pointed
out
that
this
doing
this
work
together,
like
what
we'll
be
doing
now
with
the
dvd
of
works
of
azure,
it
seems
to
be
a
good
opportunity
to
drive
cause
of
consolidation
of
the
language
features.
So,
like
we've
been
discussing
that
hey,
this
kind
of
thing
is
facing
sdf.
D
D
One
particular
thing
that
was
identified
missing
in
sdf
today
is
this
more
complex
relationship
information,
so
the
bddl
has
a
specific
definition
style
for
that.
So
the
suggestion
from
from
battery
who
was
presenting
this
work
would
be
to
define
this
extension
as
a
new
idf
trap
and
that's
planned
to
be
published.
Someday
soon.
D
Also
michael
mentioned
about
his
work
on
property
crabs
here
that
we
didn't
have
a
chance
to
discuss
in
more
detail.
That's
one
of
the
topics
we
could
actually
discuss
now
here
in
this
wishy
meeting.
D
Then
there
was
a
another
technical
topic
around
building
digital
twins
with
inter-provided
technologies,
where
being
shao
presented
his
work
on
building
a
digital
twin
systems
and
in
particular
there
we
they
have
been
experimenting
with
the
use
of
sdf
and
sentiment
for
bits
of
transition,
so
sdf
for
describing
classes
of
devices
and
linkedin
instances
and
then
send
the
ml
for
feeding
in
the
data
to
the
digital
system
and,
as
pinpoint
out,
seems
to
be
a
quite
good
match
so
far
in
the
early
exploration,
and
in
that
context
we
also
talk
quite
a
bit
about
the
different
needs
for
models
for
south
phone,
so
be
able
to
describe
devices.
D
D
E
E
Yeah
so
so-
and
I
do
have
some
code
examples
that
I
could
show
if
we
really
need
to,
but
I
think
it's
probably
easy
enough
to
explain
that
I
was
trying
to
apply
as
sdf
to
model
a
digital
twin
ontology
that
that
we
use
at
passive
logic.
We
call
it
quantum
ontology,
which
is
basically
it's
kind
of.
E
You
know
it
kind
of
spends
a
lot
of
descriptive
effort
on
physics
and-
and
you
know,
modeling
things
at
that
level-
a
complete
physics
model,
and
it
also
spends
a
lot
of
descriptive
effort
on
buildings
and
how
buildings
work
and
how
the
important
features
of
building
constructions
with
regard
to
ventilation
and
energy,
and
things
like
that
so
they're
pretty
abstract
models.
But
basically
what
I
wanted
to
do
is
it's
just
simple
object:
property
model
that
the
technology
requirements
aren't
very
complex.
E
You
know
rdf
would
probably
work
or
something
like
that,
but
as
it
turns
out,
it's
probably
going
to
be
implemented
in
swift
code.
You
know
internally,
but
we
need
you
know.
We
need
something
to
you
know
a
json
format
or
whatever.
So
I
was
looking
at
sdf
and
it's
it's
really
pretty
much
objects
and
properties
would
would
do
it,
except
that
the
linkages
are
needed
so
when
the
linkages
are
essentially
what
other
thing
are
you
pointing
at
what
it's
really
almost
like
a
web
link?
It's
like
what
are
the?
E
What
are
the
things
you're
pointing
at?
What's
the
relationship
to
that-
and
you
know,
starting
with
something
like
structural
relationships
like
this
thing-
is
this
this
you
know,
actuator
is
part
of
a
valve
assembly.
You
know,
and
the
valve
assembly
contains
the
actuator,
so
simple
structural
relationships
and
how
things
are
connected.
You
know
this
this.
This
pump
is
connected
to
this
valve
through
this
pipe.
So
you
know
describing
these
connections
and
you
know,
and
then
there's
more
more
to
it
like
describing
mathematical
operations
and
things
like
that
that
we
need
to
do
as
well.
E
So,
but
it's
a
small
set
of
predicates.
It's
not
predicate
driven
like
rdf,
and
so
that's
why
I
said
rdf
is
not
really,
you
know
the
first
choice
here,
but
you
could
do
it
in
rdf,
but
but
it's
not
really
predicate
driven
in
the
same.
In
the
same
way
that
you
would
construct
a
large,
you
know
rdf
model,
it's
more
like
a
meta
model
like
a
web
of
things,
model
where
you
could
use
rdf,
but
you
only
have
a
small
number
or
what
we're
doing
in
iot
schema
or
even
sdf
itself
for
that
matter.
E
So
a
small
set
of
types
and
things
like
enums
are
useful,
but
the
connection
was
really
the
the
thing
that
would
be
useful
to
standardize
and
what
I,
what
I
found
with
that
and
some
other
experiments
was
that
what
what
wanted
to
do
was
be
able
to
describe
the
basic
relationships
between
types
and
what
was
allowed.
You
know
what
can
not
be
allowed
to
contain
another
thing
and
what
can't
so,
the
basic
structural
constraints.
E
As
well
as
he
wanted
to
be
able
to
describe
an
instance
graph
using
the
same
tool-
and
I
think
that's
something-
we
have
not
gone
into
yet
with
sdf,
but
it's
something
that
comes
up
quite
a
bit
and
we
even
last
week
have
a
graduate
student
from
portugal
phd
student
from
portugal
wanting
to
use
sdf
to
describe
instances
and
wants
protocol
bindings
and
wants
all
this
stuff
now
so
anyway,
the
the
idea
is,
you
want
to
be
able
to
describe
instances
as
well
so
in
in
driving
toward
a
format.
E
But
that's
really
two
two
pointers,
because
you
need
the
type
constraint
or
types
that
can
be
pointed
to,
and
then
you
also
need
the
pointer
to
an
actual
instance
of
an
object,
so
in
sdf
that
would
be
a
json
pointer
for
now
or
it
could
be
a
json
path.
Expression
at
some
point,
but
right
now
we
just
say
json
pointer.
E
So,
essentially,
you
need
two
slots
for
pointing
to
things,
one
for
the
type
and
one
type
constraint
or
set
of
types
or,
however,
that
works
with
nsdf
there's
a
way
that
it
works
and
the
actual
instance
when
you
construct
an
instance
graph.
So
even
if
you
do
basically
an
ontological
graph
that
would
just
fill
in
the
type
constraints
and
cardinality
and
in
sdf
we
have
kind
of
limited
cardinality.
So
that's
one
thing:
there's
an
opportunity
for
improvement.
There
cardinality
constraints.
E
E
Maybe
it
can
be
a
uri
if
it's
a
unique
relationship
and
then
so
I
started
constructing
some
of
these
graphs
and
then
I
realized
there
were
some
cases
where
in
when
you're
modeling,
something
there's,
there's
additional
information,
that
sort
of
target
attributes
or
link
properties,
and
so
there's
a
there's
another
category
that
can
be
used
as
link
properties
or
target
attributes
and
property
graphs
are,
when
you
say,
property
graph,
there's
an
actual
spec
that
it
says:
here's
what
a
property
graph
does
or
whatever.
E
But
I'm
talking
more
generally
here
about
a
link
that
can
contain
additional
properties
on
the
link.
So,
in
addition
to
a
type
or
relationship
type
or
having
a
row,
it
can
have
some
properties
that
that
go
on
the
link
and
I
think
lately
people
have
even
relaxed.
I
was
looking
at
nottingham's
last
thing
and
it
looks
like
they're
kind
of
saying
that
even
target
attributes
and
link
attributes
are
not
much
different
and
don't
have
to
be
distinguished
that
much
that's
kind
of
what
I
read
from
a
statement
and
not
made
in
that
draft.
E
So
I
kind
of
agree
with
that.
So
we
don't
really
need
to
separate
target
attributes
from
link
attributes,
but
anyway
I
created
a
data
structure
with
force
four
slots
and
that,
depending
on
how
you
use
that,
that's
where
the
extension
is
so
sdf
relation
would
be
a
way
of
building
it
into
the
language.
E
I
found
that
really
what
I
could
do
is
build
it
in
as
a
property,
and
you
could
you
could
actually
make
it
as
an
exposed
property
of
the
object,
but
that
might
not
always
be
the
case,
so
a
language
extension
may
be
maybe
suitable
and
that's
for
something
like
relationship
the
thing
that
really
is
missing,
though
the
basic
thing
that
would
allow
you
to
do.
This
is
exposing
the
sdf
pointer
type
to
the
user
and
then
having
the
user,
be
able
to
point
to
other
definitions
as
a
data
type
that
they
have
in
the
user.
E
Even
isn't
really
an
object,
it's
kind
of
any
sdf
definition.
It
would
really
be
like
the
way
we
use
sdf
ref.
Another
way
would
be
to
wrap
it
up
in
a
in
a
language
extension
like
sdf
ref,
but
instead
of
using
ref
call
it.
You
know,
sdf
pointer
and
then
just
have
that
be
a
quality
that
you
could
set.
That
could
be
a
pointer
of
a
structure
that
you
define.
So
there
are
a
few
different
patterns
audi
and
I
have
both
experimented
with
a
couple
of
patterns.
E
I
have
another
piece
of
work
that
I'm
doing
that.
That
kind
of
goes
along
with
the
last
bullet
on
this
slide
and
that
I've
been
building
an
sdf
digital
twin
of
code
and
it's
c
plus
plus
code
objects
that
run
on
constrained
devices
like
arduinos
and
embeds
and
stuff
like
that.
E
But
the
idea
is
you
do
all
the
the
programming
and
linking
of
the
object
is
data
flow
graph
based
and
you
do
all
this
stuff
in
the
model
with
sdf,
and
then
you
sort
of
push
a
button
and
it
generates
the
code
for
your
for
your
target
and
and
that
you
maintain
that
sdf
model
as
a
as
a
digital
twin.
So
I
had
to
encounter
all
of
these
things
with.
How
do
you
make
instances
and
how
do
you
point
to
them?
E
It's
just
a
a
bit
of
a
struct
that
has
you
know
a
a
regular
c
plus
plus
pointer
in
it,
so
that
that's
kind
of
the
work
that
I'm
doing,
and
I
think
that
in
general
I
think
that
it
all
converges
on
the
need
to
have
a
standard
way
of
doing
these
linkages,
where
we
could
do
it
in
an
ad
hoc
way.
But
I
think
there's
a
lot
of
value
in
building
a
an
interoperable
way
to
do
this
that
meets
everybody's
needs.
D
Very
good,
michael,
and
I
think
it
would
be-
I
think,
kind
of
going
going
forward
on
some
guys
as
we
discussed
earlier.
We
have
very
similar
needs
on
the
relationship
information,
and
this
would
be
like
writing
down
those
a
few
few
more
examples
and
then
taking
a
focused
session
on
that
topic
would
be
my
suggested
way
forward.
D
See
like
how
much
we
can
address
with
specific
designs,
and
I
do
actually
agree.
I
think
we
have
a
two
classes
of
of
relationship.
One
is
kind
of
more
design
time
information
and
one
is
what
you
said
like
exposing
the
users
so
doing
in
a
similar
way,
as
we
do
properties
today
that
you
can
read
and
write
them
during
run
time
and
change
them.
E
Yeah,
that's!
That's
really!
That's
that's
a
good
summary.
I
I
found
that
it
was
useful
to
have
both
types
of
linkages,
both
the
design
time.
Well,
I
guess
there's
two
different
things
right
yeah,
I
didn't
find
anything
I
couldn't
do
if
it
was
wrapped
up
in
a
language
feature
as
a
standard.
I
just
did
things
in
an
ad
hoc
way
as
a
property,
but
I
there
there
was
a
need
to
you
know
generate
some
kind
of
one
kind
of
pointer
from
another
in
a
protocol
binding
and
so
that's
kind
of
the
that's
really.
E
Let's,
let's
build
a
bigger
feature,
that's
like
more
like
a
quality
that
has
some
structured
or
some
some
qualities
to
build
a
structure
out
of,
however,
that
works
and
do
we
need
a
wiki
for
this,
like
the
other
one,
then
how
do
we?
So
we
have
these
little
examples
on.
E
I
want
to
say
just
about
whatever
it's
our
chat
system,
but
maybe
we
should
have
a
wiki
to
be
basically
try
to
ratchet
this
forward
a
little
bit
didn't
you
already
did
that
didn't.
You
are.
D
You
yeah
yeah,
we
have.
We
have
those
idf
notes
pages,
but
I
don't
think
we
have
a
necessarily
wikipedia
I'll.
I
would
look
it
up,
but
I
think
that's
a
good
idea
that
would
be
way
a
place
where
we
collect
at
least
pointers
to
those
notes
that
we
have
everything
in
in
one
place
and
my.
D
E
Yeah
just
a
place
to
collect
things,
because
I
have
some
examples,
but
I
would
want
to
be
able
to
maintain
them
as
well
and
say:
well,
you
know
that
that
wasn't
quite
right.
Here's
a
little
bit
better
way
and
also
I
wanted
to
sort
of
follow
up
when
you
said
80
so
is
this?
Is
the
20,
mostly
in
relationship?
Are
there
some
other
some
other
things
that
we
should
look
at
as
well?
Is
it
is
the
topic
just
linking,
or
is
the
topic
sort
of
sdf
for
digital
twins,
or
something
like
that?
E
But
anyway,
that's
maybe
for
later,
but
I
think
we
could
make
a
wiki
and
have
had
that
to
be
a
place
where
other
people
that
we're
working
with
could
go
in
and
sort
of.
We
could
just
point
them
there
and
say:
here's
there's
a
state
of
things,
here's
what
we're
working
on!
Here's
our
open
issues,
you
know,
what
do
you
think
comments,
ideas,
etc.
B
I
think
a
good
thing
to
have
would
be,
first
of
all,
the
definition
for
what
kind
of
links
we
are
seeing
here
at
all,
because
it's
very
very
different,
whether
a
specification,
a
model
links
to
another
model
and
whether
an
instance
of
that
model
links
to
another
instance.
So
these
are
completely
different
things
that
they
pointed
different
namespaces,
and
one
thing
we
would
probably
need
to
find
out
is
how
do
we
model
the
the
name
names
of
actual
things?
So
right
now
they
don't
have
name
names.
B
So
we
are
not
discussing
this,
but
if
we
actually
want
to
have
links
as
as
a
data
type
on
on
the
instance
level,
then
of
course
these
links
need
to
point
somewhere
and,
and
that
needs
some
form
of
identity
a
space.
B
E
Yeah,
that's
I
so
I
I
that's
a
good
point.
That's
what
I
was
driving
out.
I
have
an
architectural
solution,
so
I
I
don't
really
care
what
they
are,
because
I
make
instances
in
sdf
and
I
point
to
sdf
instances
with
sdf
pointers
and
then
each
of
those
instances
can
worry
about
how
it
needs
links
on
its
own.
I
just
basically
printed
on
that
and
said.
Well,
since
I'm
making
an
sdf
instance,
I
don't
really
need
to
worry
about
defining
an
instance
from
an
sdf
model.
I
have
an
sdf
instance.
E
B
So
if
I
have
a
light
switch,
I
need
to
have
a
pointer
a
way
to
to
describe
how
to
put
the
pointer
to
the
actual
lamp
in
there,
and
that
may
be
very
different
in
bluetooth
from
how
it
looks
like
in
mqtg
or
in
in
a
rest
environment.
E
D
Okay
good,
but
I
think
we
have
the
also
a
way
forward
if
we
start
this
wiki
page
start
collecting
those
yeah
more
concrete
examples
on
what
we
want
to
be
achieving.
I
think
that's
going
to
be
a
good
way
to
go,
go
forward
here.
I
think
I
know
and
also
I
think
from
our
side.
It
has
been
really
we
wanted
to
make
more
progress
here
already
earlier,
but
it's
been
so
many
things
since
a
little
time,
so
I
guess
we're
slowly
moving
forward
good
in
any
more
discussion
on
this
topic.
D
D
D
D
I
guess
we're
talking
about
something
around
june
before
summer
vacations
that
we
could
have
one
more
wishy
call
personally
I'm
planning
to
be
july
on
vacation
starting
from
mid
summer,
so
I'm
thinking
around
day
yeah,
basically
one
month
down
the
road,
there
could
be
an
option
for
a
quick
catch-up
meeting
if
you
want
to
have
one
before
summer
vacations.
D
B
I
think
it's
an
actual
holiday,
but
I
must
admit,
because
I'm
not
living
in
a
bavaria,
I
don't
know.
C
D
And
that's
not
a
good
one.
Either
fridays
are
always
tricky.
D
13Th,
okay,
so,
and
should
we
do
the
same
time
we
did
today
or
well?
Well,
michael,
maybe
this
for
the
west
coast
question
we
don't
want
to
wake
you
up
for
all
the
wishy
calls.
Should
we
do
it
one
hour
later
or
well.
I
guess
no.
E
No
problem,
I'm
usually
up
at
five
at
five,
so
just
this
is
a
good
time
for
me.
Actually.
C
D
Then,
let's
aim
for
the
monday
13th
as
a
the
next
catch-up
in
the
full
wizard
group.
D
B
D
B
D
B
About
before,
which
is
the
sole
property
graph
thing,
which
I
think
needs
some
some
thinking
into
the
future,
so
there
are
lots
of
other
things
going
on.
We
probably
should
spend
some
time
on
mapping
files,
but
yeah
there's
there's
work
to
be
done
there,
so
that
actually,
the
draft
was
had
expired
and
I'm
working
with
jan
to
write
new
stuff.
So
we
can
meaningfully
revive
that.
E
Yeah,
what
is
an
sdf
instance
because
we
talked
about
like
oh,
it
needs
a
network
address,
but
well,
but
if
it's
a
lightweight
mtm
object,
it
maybe
only
needs
a
an
object
id
and
a
resource
id.
So
we
need
to
definitely
kind
of
figure
out
and
what
does
it
even
look
like
what
are
the
refinements
and
how
do
they
work?
There's
a
bunch
of
topics
there
that
I've
been
doing
a
lot
of
hands-on
and
understand
sort
of
at
the
hands-on
level.
What
some
of
the
issues
are
as
well
now.
D
D
E
See
also
class
instance
distinction,
so
sdf
started
off
as
a
way
of
defining
classes
and
types
mostly
and
doing
that
at
a
low
enough
level,
so
that
you
could
construct
an
api
around
them.
If
you
had
a
protocol
binding
well,
things
started
off
with
basically
defining
a
high
level
categories
like
event,
action
and
property,
but
focused
on
defining
instances
and
how
those
are
mapped.
So
I
think
they're
complementary
at
a
certain
point,
an
sdf
definition
can
be
referred
to
by
a
web
of
things.
Document
yeah.
B
So
each
of
us
doesn't
have
to
repeat
the
stupid
decisions
that
the
other
one
did,
and
so
the
the
whatever
thing
sting
model
was
created
after
we
already
had
sdf,
and
so
they
they
could
learn
from
us
and
maybe
do
things
in
a
different
way
and
we
are
going
to
do
instances
long
after
the
web
of
things.
Incense
model
exists,
so
we
can
maybe
learn
from
them
and
and
avoid
some
of
the
problems
there.
B
E
One
more
feature,
one
more
thing
about
sdf
and
one
dm
is
that
the
the
model
is
based
on
being
able
to
have
fixed
reference
name,
spaces,
definitions
and
web
of
things
has
no
nothing
like
that
and
there
could
be
a
registry
of
thing
models
or
something,
but
we
build
the
the
path
directly
into
the
abstraction
which
has
turned
out
to
be.
I
think,
a
pretty
good
choice,
but
it's
that's
what
makes
it
allows
it
to
be
a
definitional
and
what's
what
distinguishes
it
from
the
web
of
things
even
thing
models?
B
D
E
Which
and
then
you're
going
to
mention
that
conversion,
because
it's
really
from
td
to
sdf,
there's
very
little
sorry
tm
to
sdf
there's
very
little
fix
up
needed.
It's
just.
The
only
question
is
what's
a
thing:
modularity
and
some
stuff
like
that,
but
they're
tools
that
do
that
already,
and
so
we
can
sort
of
have
a
whole
little
sort
of
slide
on
on
on
the
topic.
Probably.
B
Yeah
so
of
course,
my
my
point
of
view
is
that
what
is
just
another
ecosystem
for
sdf
and
what
people
probably
think
that
sdf
is
just
another
ecosystem
for
what.
D
All
right
anything
else
before
we
close.
D
Good
okay!
Well,
in
that
case,
thank
you
guys
for
the
great
discussions
today.
I
think
we
have
a
way
forward
on
the
multiple
sub
items
and
then
let's
have
a
second
look
in
the
next
week's
meeting,
but
that
meanwhile,
we
can,
of
course,
as
usual,
catch
up
on
our
email
and
telecom
and
all
others
and
we'll
be
seeing
in
the
various
one,
dm
asdf
and
whatnot
meetings.