►
From YouTube: IETF-T2TRG-20221212-1530
Description
T2TRG meeting session at IETF
2022/12/12 1530
https://datatracker.ietf.org/meeting//proceedings/
A
Thank
you.
Okay.
Now
we
are
two
minutes
past
the
half
hour
last
time
to
get
started.
Welcome
everyone.
This
is
the
thing
good
thing:
research
group
our
summer
meeting.
My
name
is
one
of
the
chairs
of
the
group.
Of
course
the
Mormon
is
the
co-chair,
he's
just
coming
from
another
session
on
IAP
session,
joining
this
in
a
minute,
quick
reminder
to
everyone.
Since
this
is
an
irkf
session,
the
node
will
applies,
so
we
are
recording
a
session,
be
nice
to
each
everyone
and
also
the
iPad
guidelines
of
the
IEP
applied.
A
A
Also
quick
reminder
about
the
goals
of
the
irtf,
so
here
at
irtf
we
focus
on
long-term
research
issues
related
to
the
internet,
whereas
our
parallel
organization
ietf
focus
on
the
shorter
term,
issues
of
engineering
and
standards
making.
So
here
at
the
IU
therap
with
the
conduct
results
and
not
not
doing
standard
development
as
the
ietf
does.
But,
however,
we
do
publish
information
on
experimental
documents
in
the
RFC
series,
primarily
as
a
proper
way
to
promote
development
of
research,
collaboration
and
teamwork
on
the
topics
that
are
relevant
for
us.
A
A
few
notes
on
the
administrative,
so
we
have
an
online
note-taking
using
the
noteside.org
and
the
chairs
will
be
taking
notes,
but
we
do
welcome
everyone
to
join
on
the
note
taking
so
always
more
fun
and
better
on
collaborative
fashion.
We
do
have
a
mailing
list
where
we
recommend
you
to
join.
If
you
haven't
already
the
thinking
RT
at
irpf.org,
there's
a
link
how
you
can
subscribe
there
and,
as
usual
with
our
sessions,
we
do
have
a
GitHub
repository
for
this
session,
where
we
have
the
agenda
materials,
related
links,
Etc
stored.
A
A
quick
reminder
on
the
tinselin
Archie
scope
and
goals,
so
here
where
we
focus,
is
on
open
research
issues
internally
through
internet
of
things
in
the
reality,
in
particular,
on
internet
we're.
Also,
the
low
resource
nodes
can
communicate
among
themselves
and
with
the
wider
internet,
and
we
focus
here
on
the
topic
of
iot
and
issues
with
opportunities,
variety
of
standardization,
so
usually
starting
at
the
IP
adaptation
layer
and
going
all
the
way
up.
The
application
layer,
including
architectures
apis
data
management,
security,
Etc.
A
There
are
a
few
groups
that
we
work,
including
particular
closely
at
the
ietf
site,
so,
for
example,
core
where
there's
a
lot
of
work
on
protocols
and
data
models,
and
also
more
recently
with
ASDF,
which
is
engineering,
format,
variety
model,
convergence
and
then,
for
example,
groups
like
L.
We
can
iot
oops.
Where
is
more
recommendations
for
an
operational
issues
when
it
comes
to
iot,
but
usually
how
it
happens,
that
we
look
at
RG
the
more
longer
term
issues
on
these
topics
and
when
there's
need
to
write
standards
on
the
topic.
A
Also,
we
are
planning
to
have
summer
meetings
like
this
also
before
or
after
the
next
two
ietfs,
and
also
we
have
had
in
the
past
very
many
successful
meetings
with
other
sdos
Alliance
operators.
Communities
on
the
relevant
topics
so
we'll
be
very
much
open
having
more
of
those
that
we
don't
have
anything
scheduled
at
the
moment,
and
also
we
will
be
having
work
meetings
where
we
go
in
more
details
on
specific
topics.
A
For
example,
we
had
one
on
digital
twins,
not
that
long
ago,
where
we
take
a
specific
topic
and
work
more
specifically
on
that
we
are
also
planning
to
have
finally,
the
physical
meetings
someday
soon,
of
course,
not
this
year,
but
next
year
we
are
technically
discussing
to
have
one
before
the
Prague
ietf
have
a,
for
example,
half
a
layer
or
full
day
workshop
on
the
topics
relevant
for
evening
or
cheap.
So
please
stay
tuned
more
on
that
coming
soon
and
we
have
had
a
quite
some
time
planned
to
have
a
online
call.
A
A
Foreign
s
about
the
research
group
document
status,
the
document
on
H
and
iot
is
currently
has
passed.
The
research
group
last
call
and
if
share
review-
and
it's
going
to
irst
review
now,
the
other
research
could
talk
when
we
have
on
the
restful
design
for
iot
is
we're
currently
waiting
a
couple
of
more
PR's
to
come,
and
then
we
should
be
soon
going
to
research.
B
And
yes,
this
is
then
one
of
the
co-authors
of
the
the
draft.
So
just
very
quickly,
let
you
know
in
this
version
we
have
completely
assumed
the
new
terminology
used.
In
this
sense,
we
are
using
the
terms,
entities
or
or
players
involved
in
the
different
processes
and
terminologies.
Regarding
the
the
initial
processes
like
bootstrapping
provisioning,
onboarding
Etc,
so
we
analyze
different
players
involved
in
in
different
proposals
or
standards.
B
C
So
that's
that's.
What
I
would
say
is
is
is
we
need
to
have
a
top
to
bottom,
assuming
it's
20,
22
and
not.
You
know
those
document's
been
sitting
around
a
long
time
and
I
think
it's
okay
for
us
to
say
that
we
had
these
old
terms
and
that
we
have
some
new
terminology
that
is
there,
so
I'll
be
happy
to
send
you.
Some
pull,
requests
and
stuff
like
that.
But
I
think
we
need
a
working
group
wide
consensus
to
change
the
title
of
the
document.
B
So,
thank
you
Michael.
Just
a
quick
note.
The
the
the
title
was
was
already
changed
so
now
the
title
is
terminology
and
processes
for
initial
security.
Setup
of
iot
devices.
Bootstrapping
is
actually
removed
from
from
the
the
new
title,
and
what
I
would
just
say
is
that
we
try
not
to
Focus
or
favor
any
of
the
specific
terminologies,
but
we
just
try
to
to
review
the
different
terms
that
different
protocols
and
standards
used
sometimes
interchangeably,
like
bootstrap
in
provisioning.
B
C
What
I'm
trying
to
say
is
that
that
that
actually
people
have
come
to
some
consensus
about
what
the
different
terms
mean
and
that
provisioning
is
not
onboarding
and
that
provisioning
has
a
very
specific
thing
and
so
I
think
we
need
to
walk
through
the
document
and
we
need
to
rewrite
it
like,
even
in
section
two,
it
talks
about,
DPP
has
bootstrapping
information
and
it
doesn't.
It
is
provisioned
with
onboarding
information,
right
and
I.
Think
that's
just
really
important
for
us
to
get
to
get
on
top
of
that
and
I
think
that's.
Actually.
B
D
Yeah
I
I
would
just
add
that
we
we
can
recognize
industry
terms
and,
of
course,
should
be
using
them.
We're
we're
useful,
and
we
also
have
to
keep
in
mind
that
industry
terms
are
not
always
very
sharply
defined
and
where
we
find
that
an
industry
term
actually
is
ambiguous,
that
we
may
want
to
Define
some
of
our
outer
of
our
own
terms,
our
qualify,
the
industry
term
with
another
adjective
or
something
like
that
to
make
sure
we
have
really
well
defined
Towers,
but
I
agree
with
Michael
that
getting
the
terminology
right
really.
B
A
A
Next
we
have
a
segment
coming
on
security
topic,
so
your
answer
will
start
with
update
on
secure
work
and
your
Matson
will
continue
on
on
the
update
on
the
application
attacks
using
Co-op
and
then
finally,
Michael
Richardson.
We
can
update
on
the
tax
annoy
operational
security
considerations
for
manufacturing,
install
keys
and
Trust
anchors
work
after
the
security
segment.
A
We
have
a
semantic
interoperability
segment,
where
microcluster
will
start
with
the
One
dmit
schemework
update,
followed
by
Carson,
with
an
update
on
SDF
and
then
Jan
Roman
will
talk
you
a
brief
update
on
the
w3cb
of
things
and
talk
about
his
work
on
SDF
of
things,
conversions
and
then.
Finally,
Ali
and
bean
will
give
a
talk
about
their
work
on
knowledge,
graphs
for
iot
platform,
digital
twins
based
on
SDF
and
then
around
1725
UTC.
We
should
be
wrapping
up
and
concluding
the
meeting
any
questions
or
comments
on
the
agenda
for
today.
E
Can
you
hear
me?
Yes,
we
can.
Thank
you,
okay,
so
this
is.
This
will
be
short
because
I
don't
have
so
much
update,
just
informing
you
about
the
new
topic,
the
new
activity
called
Secor
security
for
constrained,
restful
environments
or
or
if
it
had
been
Italian
it
could
mean
dryness
or
secure,
or
something
like
that.
E
E
So
it's
the
idea
around
how
to
make
software
update
more
efficient,
using
multicast
or
other
group
communication
mechanisms,
and
the
second
topic
relates
to
delegation
of
Rights
in
in
particular
in
the
case
oauth
setting.
So
that's
also
an
interest
interesting
topic
and
which
we
didn't
cover
in.
In
the
Ace
work
and
which
might
benefits
from
first
a
research
activity,
so
those
are
are
two
topics
where
there
is
some
ideas
already
and
we're
just
waiting
for
people
to
have
time
to
be
engaged
in
this
and
and
bring
it
forward
to
to
the
working
group.
E
D
A
E
I
think
the
idea
of
having
meetings
somehow
relate
in
the
same
Pace
as
as
the
ITF
meetings,
either
before
or
after
or
during
I.
Think
that's
a
reasonable
attempt
for
given
the
commitment
of
other
people
who
also
are
interested
in
this
area,
but
don't
have
the
time
to
to
contribute.
So
that's
that's
my
expectation
so
in
terms
of,
but
if
other
people
are
interested
in
in
driving
some
some
things,
we
can
of
course
have
more
frequent
meetings.
A
F
F
So
we
have
submitted
a
0-2
version,
no
no
one
a
month
ago
or
so
with
basically
fixing
all
the
comments
and
issues
known
at
the
time.
A
lot
of
some
editorial
work
updated.
Some
references
updated
some
text
in
the
in
the
or
in
the
draft
that
was
better
written
in
the
slide
for
the
last
thing
to
think
RG
presentation
and
then
addressed
some
comments
from
from
Achim
to
how
calculation
of
the
amplification
factor
that
yeah,
depending
on
where
in
the
stack
you
calculated
you,
you
might
end
up
with
with
different
things.
F
He
has
some
clarification
that
you
need
to.
You
might
get
different
things,
but
depending
on
where
you
calculate
them,
sometimes
it
may
one
option
makes
more
sense
than
another.
Then
there
was
some
some
error
in
the
in
the
draft
received
from
attacker
is.
Is
now
stated
instead
of
sent
from
the
attacker.
G
F
I'll
do
it
there
received
quite
a
lot
of
new
comments
on
GitHub,
there's
best
requests
from
a
researcher
that
wants
he.
He
wanted
implementations
of
the
amplification
attacks
until
several
emails
that
this
is
smoothly
a
theoretical
work.
That's
quite
it
has
to
implement
it
himself,
but
that
is
quite
easy,
giving
him
links
to
to
different
Co-op
implementations
and
explain
how
to
high
level
to
implement
it.
Then
there
are
quite
a
lot
of
good
comments,
I
think,
most
of
them,
hopefully
quite
small
from
aquim
that
will
be
handled
for
the
zero
three
draft.
F
F
My
my
own
view
is
that
should
raise
awareness
of
iot
amplification
attacks
in
general
and,
as
pointed
out,
why
it
should
probably
also
talked
about
about
mitigations.
As
much
as
we
know,
a
question
that
could
be
discussed
is
whether
it
should
discuss
known
amplification
denial
of
service
attacks.
I'm
I,
don't
know,
probably
not,
but
if
there
are
material,
then
why
not,
but
this
is-
is
typically
involved
hacking
devices
and
so
on.
So
it's
quite
a
lot
quite
a
different
attacks
than
amplification
attacks.
Amplification
attacks
is
also
something
ITF
can
mitigate
with
the
protocols.
F
Hardening
devices
is
different
thing
and
then
the
fourth
thing
that
is,
should
the
document
include
concrete
information
about
actual
attacks.
There's
previous
well
definitely
discuss
this.
It
was
important
part
of
the
discussion
why
this
is
important.
There
was
a
request
for
newer
and
more
concrete
information
about
the
actual
attacks.
We
have
tried
to
make
the
information
a
little
a
little
bit
better,
but
the
reality
is
that
there
are
little
new
and
concrete
information
out
that
information
give
them
by
various
security
companies.
F
One
suggestion
would
be
my
CSA
to
maybe
completely
remove
this
part
from
the
draft.
It's
maybe
more
confusing
than
helping
some
other
comments
from
also
relate
to
actual
attacks
from
is
to
not
painted
to
paint
it
black,
maybe
especially
regarding
Co-op
I.
Think
removing
these
things
about
actual
attack
is
First.
Step
could
also
maybe
make
the
high
level
document
less
core
focused.
The
current
title
is
amplification
attacks
using
Co-op
I.
F
Think
the
main
goal
of
the
document
is
maybe
to
raise
awareness
of
iot
amplification
attacks
in
general,
so
I
think
maybe
high
level.
The
document
could
be
less
core,
focused
I,
think
the
examples
are
probably
on.
Most
of
the
examples
are
probably
best
to
keep
in
Co-op.
That's
the
most
relevant
ietf
iot
protocol.
A
Great,
thank
you
John
any
questions
or
comments
on
the
on
the
craft
so
far.
Well,
think
about
your
question
comments.
What
we're
thinking
of
is
doing
a
show
of
hands
in
the
medical
Tool
for
those
who
think
we
should
be
adopting
this
documents
now,
you
should
actually
see
it
in
mythical
okay.
So
this
is
a
for
a
question
who
has
read
a
version
of
this
document
and
you
can
either
click
raise
hand
or
do
not
raise
hand.
A
A
D
Yeah,
so
there
are
actually
several
ways
in
which
we
can
adopt
a
documents,
so
we
we
can
actually
achieve
research
group
consensus,
so
we
we
all
agree
on
on
what's
in
the
document,
or
we
can
simply
agree
that
this
is
useful
information
to
have
published.
Even
if
we
don't
necessarily
agree
with
all
the
details,
I
think
we
can
decide
what
we
want
to
do
when
the
document
is
already
adopted.
D
G
D
A
A
A
A
C
Okay,
thank
you,
so
I'm
gonna
make
this
quicker.
I
thought
I
had
was
expected
to
provide
more
time,
so
I
made
so
many
slides.
Thank
you
for
the
extra
time
so
I've
had
this
document
and
taxonomy
of
operational
security
considerations
for
manufacturer
installs,
keys
and
Trust
anchors.
It's
quite
a
mouthful
and
I
would
be
happy
to
shorten
it
if
people
had
a
good
way
of
shortening
it
without
losing
detail
anyway.
C
So
history
of
the
draft,
so
it
started
in
2020,
it
actually
is
first
of
all
was
in
this
document.
This
animate
document
called
Master
considerations
where
I
felt
needed
to
give
some
advice
to
Enterprises
or
manufacturers
about
how
to
build
their
idav
ID.
Their
8021
AR,
Keys
and
people
have
been
asking
for
it,
and
the
other
thing
that
I
experienced
in
2020
was
that
there
was
a
fair
bit
of
pushback
on
things
like
brewski
and
now.
C
Actually
matter
has
the
same
issue
and
DPP
as
well
about
whether
or
not
manufacturers
would
ever
actually
put
birth
certificates
in
their
devices
and
if
they
did,
could
we
ever
trust
them
to
have
gotten
it
right,
and
specifically,
there
was
basically
a
lot
of
cynicism
that
these
Keys
would
actually
ever
be
kind
of
secure
in
any
way,
and
I
was
surprised
by
that.
Considering
that
we've
had
you
know,
workshops,
security
workshops
and
iot.
That
I
think
the
Paris
one
I
think
is
2012.
C
Is
that
really
10
years
ago,
when
we
heard
from
various
entities
that
they
were
putting
idav
ID
keys
in
there,
VoIP
phones,
for
you
know
more
than
five
years
already
so
at
this
point
now
we're
talking
like
it's
15
years
ago
that
people
started
doing
this,
and
the
other
interesting
thing
was
that
I
came
to
realize
that
a
bunch
of
people
that
were
pushing
back
on
this
didn't
know
their
companies
already.
Did
it.
C
That
say
you
know:
I
have
dozens
of
ndas
with
customers
and
I
can
not
even
discuss
with
customer
a
how
they
could
simplify
things.
By
doing
a
customer,
B
did
because,
of
course,
both
of
them
are
under
NDA
and
they
can't
talk
about
them
and
they
were
kind
of
saying.
Well,
if
only
I
could
refer
to
some
external
source,
that
was
public.
C
C
You
know
remember
that
time
we
did
that
I'm
not
going
to
go
through
the
content,
but
non-goals
of
the
document.
Okay.
So
this
is
not
an
ISO
27,
000-ish
or
14
000-ish
evaluation
process.
I'm
not
going
to
tell
you
in
this
how
to
do
your
auditing,
okay
and
not.
The
goal
of
this
document
is
also
not
to
say
what
is
more
secure.
C
What
we're
actually
trying
to
do
is
simply
say
what
is
and,
and
that's
the
the
really
the
the
first
part
right.
So
we
want
to
say
you
know
what
this
is,
what
you
need
to
go.
This
is
a
certificate
we
have
on
appliances
in
Canada,
tells
you
how
energy
efficient
or
not
they
are,
and
you
can
see
in
this
example.
It's
far
to
the
left.
C
It's
really
not
very
energy
efficient,
and
you
know
what
that's
actually
sometimes,
okay,
you
know
what
you're,
okay,
with
buying
a
cheap,
refrigerator
or
microwave,
that
you
don't
use
very
often,
and
so
the
fact
that
it's
energy,
inefficient
doesn't
actually
matter
because
you
hardly
ever
use
it.
So
what
we're
kind
of
looking
at
is
this
is
just
the
numbers
here,
and
you
know
this,
this
Cheetos
holding
the
closet
shut.
C
You
know
what
that
actually
might
be
an
appropriate
level
of
security
for
some
class
of
devices,
and
the
only
important
thing
is
that
you
recognize
when
that's
what
you're
buying
and
when
you're
buying
something
super
more
secure.
You
recognize
that
and
you
see
that
there's
a
difference
in
the
price
and
that's
okay,
because
they
can
tell
you
what
the
difference
in
the
security
is
in
a
reasonable
way.
C
One
of
the
things
that
comes
of
this
document
is
a
way
to
count
a
number
of
pki
levels:
I'm
not
going
to
talk
a
lot
about
that.
Now.
How
is
the
key
generated
still
unhappy
about
some
of
the
naming
I'd
like
better
names?
No
one's
come
up
with
a
thing.
Everyone
seems
to
hate
the
third
name,
but
I
don't
have
a
better
name
at
this
point
and
then
how
do
you
deal
with
descriptions
of
business
continuity
about
secret
sharing?
C
What
do
you
publish
and
what
do
not
publish
and
what
I
believe
that
the
answer
is?
Is
that
we're
gonna,
you're
gonna
say:
publish
n
minus
K
as
the
as
a
something
that
you
can
share
without
actually
telling
anyone
n
or
k?
So
if
you
have
seven
pieces
and
you
need
four
of
them
to
reconstruct
a
key,
then
the
answer
is
you
you
have
this.
You
have
a
redundancy
of
three
which
means
that
you
know
it.
C
It
also
is
a
little
bit
like
people
might
say,
bus
count,
which
is
how
many
people
you
can
lose
from
your
team
before
your
project
is
unviable.
For
that
and
there's
an
example
right
of
what
people
were
talking
about.
You
split
off
these
keys.
They
have
different
pieces
that
go
different
places
and
you
need
to
know
how
many
there
and
one
of
the
conclusions
is
that
you
might
never
even
publish
the
list
of
who
has
the
keys
externally.
C
Obviously,
but
you
might
not
even
tell
the
board
of
directors,
okay
that
that
actually
also
might
be
something
that
that
you
might
not
do,
but
it's
not
really
our
problem,
but
you
think
about
about
the
different
situations,
but
how
that's
going
to
work
so
next
stop
and
get
documented
document
adopted.
There's
some
wordsmithing
and
maybe
some
bike
shining
over
some
terminology.
That
I
would
like
to
have
happen.
C
I
think
we
need
to
talk
about
the
resulting
terminology
widely
and
we
need
to
listen
to
while
we're
talking.
We
need
to
listen
carefully
to
the
Expressions
on
people's
faces
and
see.
You
know
where
there's
still
some
awkwardness
or
some
disagreement,
or
something
like
this
and
figure
out
what
that
is
in
there
and
I'd
love
to
publish
it
in
late
2023.
That
would
be
my
schedule
and
goal
good
enough.
D
Great
so,
as
we
said,
we
really
are
in
need
of
stable
terminology,
so
this
is
really
an
important
contribution.
This
document
can
make
and
I
think
by
actually
phrasing
it
as
a
terminology
document
and
and
less
of
an
evaluation
and
recommendation
document.
It
will
be
easier
for
us
to
actually
achieve
a
research
group
consensus
on
on
actually
publishing
this,
so
I'm
I'm
going
to
ask
the
same
questions
again
so
who,
who
has
read
a
version
of
this
document.
D
A
H
H
It
is
there,
it
is
never
mind
okay,
so
one
data
model
we've
been
going
for
a
while
now
and
I
think
I
without
giving
people
a
lot
of
unnecessary
background.
The
focus
of
the
organization
we've
really
shifted
in
the
last
years
of
the
news
is
that
we,
rather
than
driving
toward
model
convergence
and
coming
up
with
a
single
model
for
how
everyone
should
model
A
light
switch
or,
however,
we
should
model.
You
know
a
pressure,
transducer
or
whatever.
We've
basically
recognized
that
the
industry
isn't
really
ready
to
go.
H
H
We
have
SDF,
which
is
which
is
almost
there
and
we'll
hear
more
about
that
later,
but
basically
to
get
everyone
to
bring
what
they
have
in
this
format
and
and
then
work
on
the
convergence
from
there
and
that
will
in
in
really
two
ways.
So
we're
basically
giving
opening
up
so
that
people
can
create
their
own
repository
in
the
one
data
model,
space
and
use
the
CI
tools
and
basically
enforce
a
set
of
common
practices
and
common
patterns.
H
On
top
of
that,
so
that's
kind
of
what
we're
working
for
right
now
and
and
the
technical
work
is
focusing
on
the
semantic
proxy
and
mappings
and
binding
so
I
guess
you'd,
say
we're
we're
sort
of
looking
taking
a
more
long-term
view
of
the
model,
harmonization
approach
to
get
everyone
to
use
the
same
model,
and
that
will
probably
happen
over
time.
But
that
will
be
make
it
easier
to
happen
if
we
support
translation
and
semantic
proxy
and
mappings
and
bindings.
And
so
that's
that's
really.
What
the
where
the
focus
is?
H
That's
really
the
big
news.
Now,
we've
we've
got
this
set
up
already,
so
anyone
can
come
and
open
up
a
repo
and
start
downloading
their
their
models,
and
we've
done
this
already
with
Oma
and
OC.
After
those
those
two
organizations
are
pretty
pretty
far
along
we're,
just
starting
on
Bluetooth
and
initially
we're
we're
going
to
look
at
modeling
the
characteristics
and
the
mesh
device
properties
which
are
both
I
guess,
they're,
non
and
IPR
encumbered.
H
They
only
have
copyright
rules,
so
we
don't
have
to
worry
about
the
next
level
of
agreements
and
publish
them
and
they're
they're,
basically,
data
models
so
that
they,
but
but
with
Bluetooth
mesh
them,
embody
a
lot
of
the
semantics
of
what's
happening
in
the
data
types.
So
it's
a
it's
a
I
think
it's
that's
a
good
direction
and
we're
also
reaching
out
to
CSA
to
matter
now
that
they
have
launched
now
that
they
have
they're,
calling
their
data
model
dot
dot.
H
So
originally
dot
dot
was
going
to
be
this
zigbee
cluster
Library
over
IP
networks,
but
now
they've
sort
of
branded
their
the
data
model
is
dot
dot.
It's
still
plan
to
be
open,
but
so
we're
reaching
out
to
them
to
see
how
we
can
work
together
to
you
know
whether,
whether
we're
going
to
publish
that
or
exactly
how
that's
going
to
to
work
now
that
we
have
all
these
tools.
H
H
We
have
some
dtdl
Azure,
dtdl,
I,
guess
interworking
that
we're
working
on
to
to
test
some
of
this
out.
But
we're
looking
for
some
other
use
cases.
You
know
we'd
like
to
do
OPC
UA
and
some
find
some
other
people
who
are
using
and
and
I've
privately
done.
Some
similar
modeling
myself
that
I
can't
quite
share
yet
but
there'll
be
some
public
stuff
coming
out
at
some
point.
H
H
G
H
H
H
And
in
the
meantime,
people
will
have
the
ability
to
publish
their
models
in
a
Common
Language
and
it'll
reduce
the
the
burden
of
some
of
the
tool
sets.
You
know
the
question:
do
we
use
XML
or
rdf
or
whatever?
Well
they're?
You
know
there
still
are
those
choices,
but
if
SDF
provides
a
reasonable
alternative,
we
think
that
will
be
easier
for
people
to
adopt.
Also,
okay.
D
H
Other
comments
questions
please
all
right.
Well,
let's,
let's
move
on
I'll,
give
you
a
quick
update
on
iot
schema
.org.
We
started
iot
schema.org,
with
basically
the
same
idea
to
capture
the
the
I
o,
the
information
models
that
vendors
and
other
other
participants
in
iot
were
using
to
represent
their
device.
Affordances
that
how
do
you
read
temperature
from
a
device
Etc?
How
do
you
turn
the
light
on?
How
do
you
change
the
color
of
the
brightness
of
the
light?
H
So
which,
when
in
SDF,
we
have
consistent
paths
and
that,
basically
or
in
one
dm
with
SDF,
we
have
consistent
paths
and
that
basically,
will
give
you
the
identifiers
you
need
for
mapping
to
RDS,
but
I
think
that
the
the
real
interesting
thing
is.
If
there
is
an
rdf
framework,
we
don't
have
to
create
as
many
different
models
to
adapt
to
different
rdf
systems.
The
expectation
and
and
rdf
is
more
that
you'll
import
a
model
as
it
is
and
then
reason
about
it
to
do
whatever
kind
of
you
know
integration
into
your
other
model.
H
So
that's
that's
an
interesting
point
that
we
we
need
to
look
at
and
see
how
how
we
could
deliver
rdf
models
across
the
space,
and
maybe
it's
through
translating
SDF
or
something
like
that,
but
iot
schema.org
we're
leaving
it
up
because
people
are
using
it
and
and
using
it
as
an
examples
for
semantic
annotation
and
thing
descriptions,
but
we're
there
really
isn't
any
governance.
It's
ad
hoc
and
the
development
meetings
are
paused.
We
add
models
as
people
need
to
to
do
their
demos
and
and
think
TD
interrupt
blood
tests
for
w3c.
H
But
you
know
there
might
be
some
some
future
there
in
making
it
a
w3c
community
group.
We
started
that
activity
at
one
point,
but
right
now
it's
just
sort
of
a
I
guess
an
experiment
that
that
was
moderately
successful
but
doesn't
really
have
a
lot
of
legs
because
you
know
there
are
probably
other
ways
to
do
this-
that
people
are
more
interested
in
doing
with
with
one
data
model
and
things
like
that.
H
So
I
don't
really
have
a
future
forward
plan
for
that,
but
just
where
it
is
we're
going
to
keep
it
running
and
it's
only
a
little
bit
of
a
server
that
runs
and
and
a
domain
registered
and
stuff
like
that,
but
basically
we're
not
going
to
try
to
integrate
it
with
fema.org,
because
fema.org
is
more
about
higher
level
business
Concepts
and
not
about
device.
Affordances
and
I
think
there's
a
pretty
clear
dividing
line
there.
G
A
D
D
So
this
was
originally
started
by
wandian
and
1dm
submitted
the
protocol
or
the
the
specification
on
how
to
write
these
models
to
to
This
research
group,
and
we
worked
on
getting
an
iitf
working
group
working
that
that
now
is
working
on
that
we
have
a
pretty
stable,
Dash
12..
There
are
still
a
list
of
issues
that
we
need
to
work
on
and
I,
don't
think
going
through.
D
D
So
this
is
what
we
are
doing
right
now
and
of
course
this
is
not
just
specification
work,
but
it's
also
work
on
tools,
and
we
will
here
talk
about
one
of
the
tools
later
today.
There
is
a
tool
for
converting
between
Yang
and
SDF,
for
the
ITF
Yang
specification
is
used
for
talking
to
network
elements,
but
there's
nothing
fundamental
that
limits
it
to
that.
D
So
it's
useful
to
be
able
to
translate
back
and
forth,
and
the
the
main
point
of
having
a
common
semantic
division
format
is
that
we
can
have
converters
that
convert
from
into
a
lot
of
other
ecosystems
like,
and
we
have
them
for
Uma
or
CF
dtdl
What,
whatever
things
and
we
have
used
these
converters
to
populate
1dm's
playground
and
that's
certainly
an
activity
that
will
continue
in
parallel.
But
of
course
it's
not
the
working
group
that
does
the
implementation.
D
So
talking
about
how
we
will
actually
get
SDF
next
going,
there
are
several
documents
out
there
right
now
that
describe
various
extensions
or
alternate
views
at
the
this
space.
One
is
just
a
different
Syntax
for
SDF
that
that
is
actually
meant
to
be
used
by
humans,
so
it's
not
based
on
Json
but
yaml,
but
also
does
some
other
ways
of
reducing
the
noise
in
the
specification.
D
So
this
this
has
no
functional
component
to
it,
but
it
just
makes
it
easier
to
write
a
spec
on
the
Whiteboard
or
keep
it
on
on
one
side.
When
you
talk
about
this,
the
second
one
is
the
SDF
mapping
document
that
describes
a
way
how
an
SDF
model
that
exists
can
be
augmented
by
adding
to
this
model,
usually
by
adding
additional
qualities.
D
D
So
looking
at
these
two
link
oriented
documents,
the
distinction
that
I
just
made
appears
to
be
a
very
nice
and
sharp
distinction,
but
of
course
that
that's
not
entirely
sure
so
for
semantic
links.
We
have
an
example.
We
actually
have
a
unit
quality
in
SDF
that
allows
you
to
tell
what
unit
a
specific
number
you
might
find
in
a
property
has
and
that's
great
for
many
models
on
the
model
level.
D
But
then,
of
course,
there
are
ecosystems
that
actually
provide
units
in
their
interactions,
so
an
Oma
device
might
tell
you
its
unit
and
it
might
even
provide
a
way
to
switch
between
Fahrenheit
and
and
Celsius,
or
something
like
that,
so
it
yeah
it's
not
as
clear-cut
as
as
it
seems.
But
anyway
we
do
have
these
model
of
links
already
for
reuse
and
composition.
That's
called
SDF
ref
and
we
probably
want
to
do
more
things
than
than
just
gluing
SDF
models
together.
D
So
that's
why
we
need
more
relation
types
than
than
just
the
the
one
that
is
implied
by
an
SDF
ref
quality
on
the
the
insurance
level.
Of
course,
we
need
a
data
type,
because
the
information
model
has
to
model
the
the
data
Exchange
in
the
interactions
and
that
data
model
is
based
on
RFC
82
ADH
web,
linking
so
it's
pretty
straightforward
and
what
we
now
have
to
find
out
whether
the
the
the
statements
we
can
make
at
the
model
level
about
what
the
values
of
these
links
will
be.
D
You
can
actually
expressed
in
in
this
generic
data
model
in
a
way
that
that
makes
sense.
So
what
what
we
really
need
for
for
the
continuation
of
this
work
is
appropriate
examples
and
and
trying
out
the
mechanisms,
whether
they
they
do,
the
right
thing
and
that's
where
I
hope
we
will
get
some
some
input
from
This
research
group.
D
More
generally,
we
we
are
talking
about
extension
points,
so
we
can
wrap
up
SDF
base
an
stf's
based
specification
and,
as
I
said,
this
all
results
revolves
around
qualities
and
it's
extending
SDF
can
be
as
simple
as
adding
qualities,
and
then
you,
of
course,
need
to
to
manage
some
namespaces.
There
may
be
General
stf
extensions.
There
may
be
ecosystem
specific
one,
so
we
have
to
Define
how
this
should
be
done.
D
This
is
currently
just
an
issue
on
the
SDF
spec,
but
it
seems
relatively
straightforward
to
Define
this,
so
this
will
be
one
of
the
things
to
be
done
next
and
yeah.
Then
again
we
want
to
do
verify
validate
whether
we
are
doing
the
right
thing
here.
So
that's
simple,
not
so
simple
is
actually
extending
the
architecture,
so,
for
instance,
web
of
things
has
something
called
protocol
bindings.
D
We
we
currently
put
these
into
mapping
files,
but
that
doesn't
really
answer
the
question
whether
the
protocol
bindings
are
can
be
described
in
a
cross-ecosystem
way
and
of
course
there
are
also
other
kinds
of
ecosystem
info
for
affordances.
So
we
can
put
these
into
mapping
files
that
that's
the
easy
part.
The
not
so
easy
part
is.
How
do
you
actually
go?
One
one
meta
level
above
and
say
by
the
way
a
mapping
file
for
Bluetooth
typically
looks
like
this
or
the
mapping
file
for
Oma
typically
has
an
Oma
object,
ID
somewhere
in
it.
D
So
how
do
you
get
from
a
product
line,
description
to
a
specific
product
description
and
so
on?
Yeah,
some,
some
interesting
questions
there,
which
again,
where
I
hope
the
the
research
group
will
help.
And
finally,
there
are
all
kinds
of
other
information
that
go
beyond
just
providing
a
description
of
the
affordances,
such
as
purpose
in
life,
information,
part
of
which,
which
a
device
needs
to
know,
but
part
of
which
actually
is
outward
facing
and
there's
also
deployment.
D
Information
such
as
location,
a
device
doesn't
need
to
know
its
own
location
so
that
that
may
be
somewhere
else.
But
then
we
need
to
properly
link
this
together
in
a
way
that
actually
is
not
brittle
and
links
to
other
things
where
SDF
type
link
already
does
something.
But
is
that
that
all
we
need
and
more
generally
we
we
seem
to
need
locating
things
at
the
class
level
modeling
the
instances,
but
we
also
need
to
have
a
way
of
actually
describing
what
what's
going
into
a
specific
instance.
D
A
A
A
I
I
From
what
I've
seen
there's
going
to
be
the
transition
to
candidate
recommendations
for
these
three
documents
later
this
week
and
then
in
March
there
will
be
the
transition
to
proposed
recommendations
and
eventually
yeah
there.
There
will
be
published
as
recommendations
and
web
standards
by
the
w3c.
I
If
everything
goes
right,
then
there
will
be
a
new
Charter
beginning
in
May,
where
first
of
all
postponed
document
from
this
Charter
period
will
be
published,
profile
specification,
which
yeah
specifies
a
profiling
mechanism
for
GDs.
It's
also
a
basic
HTT,
HTTP
profile
and
yeah.
In
this
Charter
period,
there
will
be
a
new
delivery
boards,
such
as
a
2.0
version
of
the
HD
specification,
but
also
on
new
deliverables
and
new
topics,
such
as
a
stronger
focus
on
protocol
bindings.
However,
the
actual
topics
are
still
being
discussed
and
yeah.
I
This
discussion
is
going
to
be
finalized
into
the
mid
of
January
and
yeah.
You
can
find
the
current
publication
schedule,
as
well
as
the
discussion
on
the
new
Charter
topics
in
the
what,
in
the
in
the
main
word
repository
on
GitHub,
but
also,
for
example,
on
the
watch
in
the
word
Wiki,
the
w3c
yeah,
coming
to
the
actual
topic
of
this.
The
main
topic
of
this
talk
and
the
mapping
between
SDF
and
what
and
the
conversion
I
first
want
to
the
brief
motivation
for
this
conversion.
I
So,
as
you
probably
know,
both
what
and
SDF
are
dealing
with
improving
the
interoperability
and
the
internet
of
things
from
different
angles.
So
SDF
primarily
focuses
on
improving
the
probability
between
ecosystems
and
the
data
models
by
providing
Universal
universal
language
which
can
be
used
in
conversion
processes
and
what
you
de
primarily
focuses
on
improving
the
interoperable
interoperability
between
individual
device
instances.
I
I
We
have
a
similar
structure,
so
the
label
from
the
SDF
object
can
be
mapped
to
a
title
at
the
GD
level
or
the
top
level
of
the
TD
and
the
property
from
the
SDF
model
or
the
SF
object
can
be
mapped
to
property.
At
the
thing,
in
the
thing
description
containing
a
similar
information,
however,
we
can
also
observe
two
major
differences,
so
on
the
one
hand,
we
have
Json
ad
context
at
the
top
of
the
theme
description.
I
This
raised
two
questions,
the
first
of
which
being
yeah
how,
first
of
all
how
we
can
map
the
what
specific
vocabulary,
which
is
the
F
and
for
this
I
mentioned
I,
used
a
concept
already
mentioned
by
Carson
the
so-called
mapping
files
which
allow
for
the
augmentation
of
the
SDF
model.
So
on
the
left,
we
can
see
the
same
model
as
before
and
on
the
right
hand,
side.
I
We
have
a
map
object
within
this
mapping
file
or
Json
Json
object
that
contains
Json
pointers,
which
indicate
where
the
state
of
model
on
the
left
is
being
augmented.
With
the
what
specific
vocabulary
and
yeah
from
this,
these
two
documents
yeah
was
possible,
for
example,
to
create
augmented
SDF
model,
which
could
then
be
converted
to
what
what
data
model
in
the
other
direction.
There
was
the
question
of
how
to
map
SDF
models
and
themselves
to
what
that
abstract
and
contain
no
instance
specific
information.
I
Since
the
forms
and
the
security
information
is
actually
mandatory
in
thing
descriptions
and
it
has
to
be
provided
and
to
solve
this
question
or
this
problem,
it
was
possible
to
use
a
New
Concept
called
thing
models
which
are
near
superset
of
theme,
descriptions
with
fewer
constraints
that
allowed
to
omits
the
instant
specific
information,
while
only
requiring
the
addition
of
and
Json
ID
Edge
type
annotation,
indicating
that
this
is
a
thing
model
and
yeah.
This
allows
the
mapping
of
abstract
SDF
models
to
get
to
the
word
ecosystem
on
a
high
level.
I
I
So,
due
to
the
fact
that
thing
models
are
almost
supersets
of
thin
descriptions
and
it
was
possible
to
only
specify
the
conversion
between
SDF
and
thing
models
and,
on
the
other
hand,
the
conversion
between
descriptions
and
thing
models
and
then
gets
the
conversion
between
TDS
and
SCF
models
as
a
cover
Library
as
a
result
and
yeah.
This
enabled
me
to
cover
all
three
types
of
documents,
with
only
yeah
two
real
implementations,
so
to
speak.
Yeah.
I
I
Besides
the
problems
I've
already
mentioned,
there
have
been
a
number
of
additional
challenges
during
the
con
for
the
mapping
and
conversion,
so,
for
example,
SDF,
and
what
use
different
approaches
for
nested
models
or
composition
so
and
what
documents
we
actually
have
a
linking
approach
for
creating
hierarchies,
while
in
SDF,
as
you
might
know,
we
can
express
hierarchies
in
a
single
SDF
model
using
the
SDF
think
class
and
eventually
it
was
possible
to
map
these
two
approaches
to
each
other.
After
making
slight
adjustments
to
the
state
of
think
class
and
the
SDF
specifications.
I
However,
one
challenge
was
that
it's
it's
currently
not
intended
to
have
a
self-contained
documents
containing
multiple
nesteds,
TMS
or
TDS,
and
therefore
I
used
an
experimental
approach
called
TM
otd
collections,
where
the
linking
relations
are
expressed
using
Json
pointers
yeah.
So
this
is
actually
one
thing
where
the
what
specification
might
be
improved
in
the
future
and
another
challenge
was
of
course
round
tripping,
so
this
yeah
converting
from
what
to
SDF
this
was
relatively
easy.
I
Using
mapping
files
put
in
the
other
direction,
it
was
necessary
to
use
certain
additional
keywords:
prefixed
with
SDF
and
yeah.
This
is
definitely
something
that
has
been
has
to
be
Revisited
when
making
a
more
formal
specification
of
the
conversion
process
or
mapping,
process
and
yeah.
Another
challenge
for
round
tripping,
of
course,
was
when
external
references
have
been
used.
These
have
had
to
be
resolved
before
converting
documents
to
the
other
format.
I
I
I
implemented
this
mapping
or
conversion
as
a
software
using
using
the
Python
programming
language,
I
published
my
converter
as
a
library
to
the
python
package
repository
Pi
Pi,
so
you
can
simply
install
it
using
the
package
manager
and
obtain
both
the
library
and
an
in
the
CLI
tool
contained
within
within
this
Library.
So
you
can
either
use
it
from
the
command
line
or
in
your
own
python.
Project
I
also
created
a
web
application
where
you
can
experiment
with
the
conversion
between
SDF
and
what
models.
I
However,
there's
still
most
energization
work
in
research
needed,
so
there
should
be
some
kind
of
canonical
mapping
specification
in
the
end,
and
it
has
been
already
mentioned
and
the
question
of
how
to
map
the
linking
approaches
used
in
what
is
also
still
an
open
question.
So
this
hasn't
been
taken
into
account
yet
by
me
and
yeah,
so
last
Point
yeah.
A
I
A
G
I
think
you
can
get
operational
terms.
What
is
the
objective
of
this
work?
Is
it
to
prove
the
feasibility
of
doing
the
conversion,
or
is
it
to
service
the
basis
for
some
automated
tools
that
will
do
the
conversion,
I
presume
at
the
design
time?
This
is
a
bit
heavy
to
do
at
runtime
at
the
node
level.
But
in
any
case,
is
this
a
feasibility
demonstration
objective
or
is
it
to
create
a
tool
for
a
conversion
tool.
I
So
creating
a
conversion
tool
was
certainly
one
of
the
objectives
but
yeah.
Another
all
of
me
was
to
provide
a
proposal
Nation
one
for
yeah
or
mapping
between
SDF
and
what
that
can
or
that
could
be
used
for
this.
Then
standardization
process,
so
yeah
I,
think
I
also
demonstrated
the
feasibility,
but
it
was
also
met
as
an
input
for
the
sanitization
process.
A
A
J
Okay,
yes,
so
then
I
will
proceed
to
present
the
project.
I
have
carried
that
Ericsson
research
we've
been
shower
as
my
supervisor,
and
this
project
is
a
title:
knowledge
graphs
for
iot
platform,
digital
twins
based
on
SDF
as
re
as
mentioned,
so
at
the
end
of
this
presentation,
is
the
following:
first
I'm
going
to
give
a
brief
description
of
the
background
on
the
research
question,
followed
by
Russell's
overview
and
also
a
talk
about
the.
F
J
Enablers
of
this
project
and
then
I
will
dive
more
deeply
into
the
projects
itself,
starting
by
describing
the
test
environment.
We
have
used
the
Prototype
and
the
in
the
algorithm.
We
have
used
to
measure
the
similarity
between
devices
and
integrate
new
devices
within
the
graph,
and
we
will
talk
about
more
in
detail
and,
of
course,
we
will
finish
with
the
future
work
and
a
discussion
of
the
questions
that
may
arise.
J
So.
First
brief
description
of
the
background
and
the
focus
the
project
that
builds
the
digital
twin,
using
like
knowledge,
graphs,
which
represent
manage
and
reason
with,
grab
structured
knowledge
for
this.
We
are
using
the
fields
of
knowledge,
representation
and
reasoning,
being
a
knowledge
representation
based
on
the
representation
of
knowledge
as
a
set
of
facts
and
rules.
J
Query
in
that
knowledge
through
query
language
and
conduct,
a
reasoning
in
that
knowledge
or
knowledge
base
to
get
non-splicitly,
stated
facts,
and
this
first
three
requirements
I
usually
implemented
the
building
in
like
the
available
knowledge
graphs.
But
then
we
want
to
focus
on
the
fourth
requirement,
which
is
the
integration
of
new
unfortunate
iot
devices
in
the
in
this
stream.
We
are
going
to
model
of
the
iot
platform,
which
is
which,
as
I
said,
it
will
be
the
main
contribution,
and
here
we
have
an
example
of
what
could
be
this
scenario.
J
So
imagine
we
have
a
iot
platform
representing
our
production
line
in
a
in
a
manufacturing
plant,
so
this
will
be
divided
in
two
tasks:
The
Underpants
configuration
which
will
be
developed
by
a
pickup
robot
and
a
piece
detector.
These
are
iot
devices
and
also
the
body
configuration
task
which
will
be
the
developed
by
the
pickup
robot,
drilling
robot
and
so
on.
J
So
the
question
here
is:
if
in
this
stream
of
data
in
maybe
Co-op
Co-op
or
mqtt
protocol,
if
a
new
message
from
a
device
that
we
still
don't
have
in
our
graph
appears
such
as
this
new
pickup
robot.
How
to
how
can
we
interpret
this
message
and
integrate
this
device
into
the
graph
of
existing
devices?
We
have.
J
Now
I
want
to
briefly
describe
the
results
of
this
project.
This
is
divided
into
three
main
goals
we
pursued
and
the
first
one
was
the
exploration
of
the
available
methods
to
develop.
Two
storage
store
knowledge
in
a
digital
twing,
and
we
chose
to
store
this
knowledge
using
the
type
DB
open
source,
Knowledge
Graph,
and
then
for
this
graph.
We
Define
a
domain
adapted
ontology
or
schema
using
that
schema.
We
initial
design
and
initialization
of
the
data
we.
J
This
is
the
initial
devices
and
their
connections
based
on
the
physical
asset
we
want
to
model
and
this
physical
asset,
the,
since
we
don't
have
data
from
a
real
physical
object
or
asset
available,
we
decided
to
emulate
it.
So
the
second
goal
main
goal
was
to
set
up
this
iot
based
test
bet
for
the
knowledge
ingestion.
J
This
is
the
first.
You
will
see
divided
into
the
following
sub
goals,
which
is
the
Define.
The
iot
devices
like
it
was
based
in
iot
devices
in
a
simplified
automobile
production
line
that
can
be
seen
here
in
the
picture
on
the
upper
right,
then,
for
each
of
the
devices
involved
in
this
production
line,
we
described
them.
Semantically,
using
SDF
and
these
devices
are
divided
in
modules,
which
you
will
be
SDF
objects
which
are
divided
in
proper
in
attributes,
which
will
be,
in
this
case
the
SDF
properties.
J
J
The
final
goal
was
the
device
in
integration
of
the
device
data
into
the
knowledge
graph.
For
this
we
Define
we
have
the
made
the
algorithm
able
to
Define
each
new
class
of
iot
device.
It
detest
detects,
which
is
described
by
the
SD
by
its
SDF
file,
in
the
schema
of
the
knowledge
graph
and
update
this
the
device.
They
are
the
attributes
of
these
devices
in
real
time,
as
well
as
being
able
to
integrate
new
14
devices
when
they
appear
so
for.
In
order
to
achieve
these
goals,
we
have
so
certain
key
numbers.
J
Enablers,
as
the
first
one
is
the
type
DB
Knowledge
Graph,
which
is
divided
into
the
schema
and
the
data.
First,
the
schema
is
describing
the
automatological
description,
which
would
be
the
backbone
of
this
graph,
and
it
represents
domain
specific
terminal
terminology
that
defines
the
objects
in
this
graph
and
how
they
relate
to
each
other.
J
So
in
this
graph
we
will
have
a
three
main
types,
which
are
entities
which
are
the
objects
involved
in
this.
In
this
graph,
for
example,
in
this
simple
schema
for
a
phone
calls
a
knowledge
graph.
We
have
that
the
entities
are
persons
and
companies,
and
then
we
have
another
type,
which
is
the
relationship
which
is
which
are
in
NRA
connections
based
on
roles.
So
for
this
simplify
the
schema
for
another
phone
calls,
this
will
be
the
contract
and
these
are
based
on
roles
which
state
the
the
activity
of
these
relations.
J
So
for
today,
in
order
to
define
a
schema
like
this
one,
we
will
execute
the
say
the
this,
the
defining
query
we
have
here
so,
for
example,
for
the
contract.
We
will
Define
it
as
a
type
of
relation
so
sub
relation,
and
then
it
will
relate
a
provider
with
a
customer
which
I
was
with
over
here,
for
example.
If
we
then
dive
deeply
into
the
object,
The
Entity
company,
it
would
be
a
sub
entity
and
we
play
the
role
of
the
role
provider
in
the
relationship
contract
and
you
will
own
a
name.
J
Then,
as
in
another,
in
the
knowledge
graph,
we
also
have
the
data
which
are
the
actual
entities,
the
under
instances
and
relationships
in
relationships.
So
for
them.
The
basic
example
of
the
phone
calls
Knowledge
Graph.
We
talked
about
before
we
could
Define
a
company
such
as
Ericson
and
two
persons
such
as
me
and
John
Legend,
John
Legend,
and
then
we
can
also.
They
insert
some
calls
between
this
person
with
a
certain
duration
and
give
certain
give
specific
names
to
the
persons.
J
As
we
can
see
on
the
graph
on
the
right,
then
the
second
key
enabler
is
SDF,
which
you
are,
of
course
familiar
with
the
semantic
definition
format,
and
we
have
used
this
format
to
define
a
semantic
Json
description
of
each
iot
device
class,
which
is
divided
in
modules,
attributes
and
value
type.
So
it
like
specifies
the
modules,
the
attributes
and
value
types
that
each
iot
device
has.
J
So
this
the
goal
of
this
SDS
institution
description,
then,
is
that
each
time
they
we
detect
a
device
in
the
in
the
Stream
of
data
we
are
listening
to,
but
it's
not
whose
class
it's
not
just
defined
in
the
schema.
So
the
classes
are
known.
We
would
like
query
this
SDF
description
and
use
in
the
description.
J
So
now
that
we
have
defined
the
describe
the
background
on
the
on
the
key
enablers,
we
were
going
to
dive
more
deeply
into
the
the
job
done.
So
we
will
start
with
by
describing
the
test
environment
which,
as
I
said,
it's
a
based
on
iot
devices
in
a
in
a
car
manufacturing
plant
and
then
we're
going
to
talk
about
the
Prototype,
which
is
divided
in
the
key
component's
key
component
description
and
the
data
flow
flow.
J
So,
first
talking
about
the
environment,
it
is
based
on
a
car
manufacturing
plant
divided
in
task
and,
as
I
said
before,
a
Knowledge
Graph
requires
us
to
define
a
schema
based
on
the
domain.
So
for
this
manufacturing
plan,
we
designer
simple,
schema
to
model
how
the
devices
relate
between
each
other
and
what
role
does
it
take
in
the
in
the
environment?
This
is
based
on
this.
J
So
we
have
two
departments
and
it's
a
environment,
the
production
department
and
the
safety
Environmental
and
within
the
production
Department.
We
have
the
initialization
task
divide.
That
includes
the
attack
scanner
device
and
a
production
control
device,
and
also
the
underpant
configuration
task
that
pickup
robot
device
as
a
piece
detector
and
so
on,
and
the
thing
will
apply
for
the
safety
environmental
department
and
the
task
of
interim
indoors
monetization
Outdoors
control,
monetize,
monetization
and
safety
alarms.
J
So
now
we're
going
to
talk
about
the
key
components
of
this
prototype.
I
want
to
start
with
from
the
right
of
the
slide.
So
first
we
will
have
a
set
of
scripts
in
specific,
specifically
the
Escape
that
the
defines
the
physical
object
or
the
or
the
emulates,
the
physical
object
or
the
iot
platform,
and
this
will
be
will
Define
a
set
of
iot
device
classes
that
will
be
implemented
implemented
through
threads
and
mqtt.
Clients
where
we
have
decided
to
use
mqdb
just
because
it
was
It
was
a.
J
But
then
we
will
be
sent
by
the
broker
to
the
mqtt
client
that
will
receive
and
process
these
messages
and
then
send
them
to
the
consistency
Hardware
that
will
actually
process
the
information
of
these
messages
and
Define
new
devices
in
the
schema,
if
necessary,
update
their
attributes
and
integrate
new
14
devices
and
then,
since
it
needs
to
update
the
information
in
the
knowledge
graph.
It
will
be
this.
J
J
It
starts
from
an
idle
point
where
we
are
waiting
to
receive
a
message
from
an
iot
device.
So
in
case
you
receive
a
message.
This
message
is
decoded
and
this
message
is
divided
in
in
the
header,
as
we
talked
before,
we
specifying
the
name
or
the
class
of
the
iot
device
and
the
uuid
of
this
device,
and
then
we
are
also
the
body
which
specifies
the
actual
values
that
this
device
has.
So
what
we
will
ask
ourselves
is
ourselves
first
is:
is
the
class
of
this
device
known
and
in
case
it
is
not
known.
J
We
will
Define
the
device
slash
in
the
knowledge
graph
schema
using
the
SDF
description.
So,
as
we
said
before,
we
will
turn
the
SDS
decryption
of
the
device
into
this
automate
into
this
query
automatically
to
Define
it
into
the
schema
of
the
graph,
and
then
once
this
is
done,
we
will
ask
the
following
question:
do
we
know
the
actual
device
instance?
So
this
is
like?
J
If
do
we
have
the
uuid
already
in
our
known
devices,
and
in
case
the
device
is
not
known,
so
we
will
insert
a
floating
device
in
the
knowledge
graph
through
the
which,
where
floating
means
it
is
inside
the
graph
already,
but
it
doesn't
have
any
relation.
So
it's
like
floating
on
the
graph
and
go
to
the
next
step,
which
is
to
update
the
device
that
the
actual
attributes
or
values
of
the
device
and,
as
we
said
in
case
this
device
is
not
known.
J
The
algorithm
we
use
to
file
to
measure.
Similarly,
I
will
explain
in
continuation,
but
if
this
algorithm
finds
these
are
really
similar
device,
what
we
will
do
is
we
will
replicate
the
relationship
of
the
relations
of
the
closest
device
on
the
new
device
and
check
if
it
was
active
lately
to
in
case
it
was
considered
a
new
device
complementary
and
keep
the
closest
device,
and
in
case
it
wasn't
replaced
the
the
older
device
consider
the
replacement
took
place.
J
So
I
want
to
end
up
by
explaining
how
we
measure
the
similarity
within
devices.
So
this
the
similarity
measure
is
divided
into
device
similarity
and
device
in
an
instance
similarity
and
foreign
classes
of
devices
we're
comparing
their
SDF
descriptions
and
to
do
that,
we
turn
them
into
table,
which
is
the
analysis
but
adds
a
bit
of
redundancy
and
the
problems
we
encounter
to
measure.
This
distance
was
that:
how
can
we
compute
that
distance
based
on
the
string
values
which
for
what
we
use
the
natural
language
processing
tools?
J
And
then
the
other
problem
was
how
to
compare
device
classes
with
different
number
of
properties
for
what
we
use
a
rows
wise
voltage,
voting
system
that
we
are
going
to
explain
briefly
in
continuation,
so
to
compare
devices
with
different
number
of
properties.
Or
we
did
this.
Take
a
row
of
this
sdl
description,
defining
a
branch
of
the
description.
So
it
would
be
a
certain
attribute
and
we
will
compare
this
class
SDF
row
to
all
of
the
possible
rows
or
attributes
in
the
other,
already
integrated
classes.
In
the
graph.
J
We
will
determine
somehow
which
one
is
the
closest
one
semantically,
and
for
this
losses
we
will
look
closest
row.
We
will
look
at
what
class
it
belongs
to
and
give
this
class
about.
So
if
we
repeat
this
process
for
all
the
attributes,
this
air
quality
simplified
new
device
that
appears
in
the
Stream
has
we
can
get.
We
will
get
at
the
end
that
the
closest
device
is
the
air
quality
device
which
is
not
simplified.
J
It's
a
bit
more
complex
device,
but
they're
doing
the
same
job
so
since
it
was
the
closest
last
it
will
or
the
one
with
the
most
votes.
What
we
will
do
is
integrate
this
inference
using
the
SD
Evolution
into
this
DF
description.
So
now
we
will
say
in
the
description
of
the
air
quality
simplified
and
we
will
add
the
density
of
relation
saying
that
it's
the
same
as
or
similar
to
an
air
quality
device.
Plus.
J
So
what
we
will
do
is
like
take
the
sliding
Windows
of
the
last
values
of
this
attributes
of
this
unknown
device
and
slide
it
through
the
all
of
the
other
possible
attributes
of
the
closest
classes,
device
entities
and
see
which
ones
are
the
closer
ones.
So
we
will
vote
the
closer
class
for
each
of
these
attributes
and
I
said
before
get.
J
J
We
also
need
to
look
on
the
optimization
of
the
closest
device,
the
computation
of
the
most
similar
devices.
This
is
the
class
and
behavioral
distance,
because
it's
a
it's
a
bit
a
bit
too
slow
at
the
moment
and
it
could
be
made
more
fast
and
then
we
are
also
in.
We
don't
tackle
the
integration
of
devices
new
devices
from
scratch.
J
This
is
that,
if
in
case,
we
don't
find
any
similar
any
really
similar
devices
within
the
graph
to
the
new
device,
we
don't
have
a
process
yet
to
integrate
the
device
but
the
new
device,
but
it
will
require
you
creating
a
new
Branch
within
this
graph,
and
then
we
also
need
to
test
this
implementation.
This
project,
with
the
real
data
coming
from
an
actual
iot
platform
when,
with
this
I
I
end,
the
presentation
I
mean
open
for
questions.
H
A
H
You,
assuming
that
already
exists
in
the
terms
of
an
SDF
Sable
capulary.
If
you
encounter
the
term
temperature,
do
you
expect
that
you
know
how
much
fuzzy
reasoning
are
you
doing
to
to
sort
of
try
to
harmonize
different
models,
or
are
you
expecting
vocabularies
to
already
be
harmonized
harmonized
here.
K
Foreign,
maybe
I
can
answer
this
question
for
that.
That's
first
a
very
good
question
and
just
to
say
we
are
not
following
up
with
the
capillary
ones
and
meanwhile
we
are
very
much
open
for
different
type
of
identified
vocabularies
for
and
for
the
isdf
notation
look.
That's
because
the
way
we
are
doing
is
actually
calculating
distance.
K
Then
the
only
question
is
that
it
doesn't
matter
what
are
in
the
dictionary
or
not.
Once
we
annotated
use
SDF,
then
you
can
always
try
to
find
and
search
in
the
current
existing
Knowledge
Graph.
If
there
be
anything
close
to
that
using
a
distance
calculation,
we
have,
and
if
they're
being
do
let's
say
close
on
the
distance,
then
things
can
be
integrated
with
the
new
data
to
the
existing
Knowledge,
Graph
I
hope,
I
answered
the
question
this
way.
A
Okay,
thank
you,
I
guess
we
have
a
for
a
very
quick
comment.
Our
well
not
really
works,
we're
practically
out
of
time
here
that
that's
actually
true
but
I.
What
what
we
could
definitely
do
is
to
have
the
demo
in
one
of
the
one
dm
or
as
the
obsessors
we
could
take
a
closer
since
we
didn't
have
one
first
time
for
it
today,
but
thanks
a
lot
for
presenting
a
lot
of
things
was
very
interesting
and
relevant
work
here.
A
So
what
we
could
do
now
is
is
to
wrap
up
here.
We
have.
We
already
identified
a
couple
of
ways
forward,
especially
with
the
documents,
so
thank
you,
everyone
for
showing
your
support
on
adoption
and
looking
forward
to
all
the
reviews
on
the
documents
when
it
comes
to
the
presented
protocol
on
stf.
Yes,
let's
continue
the
discussions
in
the
one
VM
calls
in
the
ASDF
calls
that
are
coming
and
also
on
the
all
the
security
topics.
You
will
be
hearing
more
on
the
Secor
on
the
mailing
list
and
anything
else.