►
From YouTube: T2TRG Interim Meeting, 2020-07-30
Description
T2TRG Interim Meeting, 2020-07-30
A
C
C
E
F
C
C
It,
and
so
we
put
together
some
slides
here
to
talk
about
that.
Did
someone
have
a
question
or
comment?
No,
okay,
so
we'll
go
through.
I've
got
some
slides
here,
but
also
we
just
wanted
to
also
say
that
this
you
know
we
want
to
have
an
open
discussion
here
and
so
feel.
Free
to
you
know,
ask
questions
as
we
go.
We
do
have
some
time
at
the
end
for
more
more
discussion.
If
we
don't
have
it
during
the
during
the
presentation.
C
All
right
so
just
to
set
us
up
here
we've.
This
is
our
the
agenda
we've
put
together,
but
if
you
have
specific
areas
or
specific
questions,
we
can
certainly
you
know
not
don't
have
to
strictly
follow
this
agenda.
This
is
just
what
we
put
together
to
try
to
introduce
etdl
and
talk
about
some
of
our
experience
and
experiences
and
things
so
we'll
start
with
a
brief
introduction
of
dtdl.
C
C
And
at
least
what
we
see
from
our
customers
is
that
they
use
a
wide
variety
of
modeling
languages
and
so
we're
very
interested
in
how
we
collaborate
and
interoperate
with
those
things
that
already
exist
and
that
customers
and
other
people
are
using.
And
then
we've
got
some
time
if
we
need
it
for
questions
and
discussion.
At
the
end.
C
So
so,
to
start
us
off,
this
first
slide
is
kind
of
a
terminology
slide
before
we
jump
into
talking
about
the
dtdl,
specifically
just
to
sort
of
give
give
some
definitions
for
the
terms
that
we're
using
so
you'll
hear
us
talk
about
digital
twins,
a
lot
and
what
that
means
to
us
is
a
variety
of
things.
So
digital
twins
can
be
physical
devices,
so
actual
iot
devices
that
are
deployed
in
a
physical
environment.
We
will
call
that
a
digital
twin,
sometimes
we'll
call
that
a
device
digital
twin.
C
C
Lastly,
we
also
look
at
collecting
these
sets
of
digital
twins
or
systems
of
digital
twins
together,
where
customers
can
create.
You
know
full
buildings,
for
example,
made
up
of
these
digital
twins
that
all
interrelate
together
and
so
we'll
call
this
either
a
graph
or
a
system
of
digital
twins
or
a
set
of
digital
twins.
Those
kinds
of
things.
G
C
G
C
So
it
certainly
does
that
certainly
living
in
the
cloud
is
certainly
one
place
that
it
lives,
but
we've
also
started
to
see
that
digital
twins
may
live
elsewhere,
so
they
may
live
in
more
local
networks
like
on
an
edge
device,
for
example,
that
is
more
local
to
you
know
a
set
of
physical
things
like
physical
devices
or
or
physical
entities,
for
example.
You
might
have
a
factory
and
you
may
have
an
edge
device,
that's
local
to
the
factory,
and
that
may
have
some
representation
of
the
elements
in
the
factory.
You
know
as
digital.
H
C
I
C
So
I'm
gonna
go
on
here,
jump
in
a
little
bit
into
actually
what
is
the
digital
twins
definition?
Language,
because
that's,
I
think,
primarily
what
we're
here
to
talk
about.
So
to
begin
with,
our
our
intention
here
is
that
the
digital
twins,
definition,
language
or
dtdl-
is
an
open
source
modeling
language
for
describing
digital
twins.
C
The
list
we
had
on
the
previous
slide,
so
iot
devices,
for
example,
digital
twins,
as
well
as
the
system
of
digital
twins,
and
so
the
language
tries
to
include,
intends
to
include
enough
enough
expositivity
to
be
able
to
express
those
different
things
and
we'll
get
into
some
more
detailed
examples.
On
the
next
couple
slides.
C
So
what
we
were
seeing
before
this
is
that
in
in
many
cases,
devices-
and
you
know,
iot
devices
and
iot
solutions
would
be
very
tightly
coupled
together,
because
there
was
no
contract,
no
no
formal
contract.
The
solution
had
to
be
written
to
to
specific
devices
and
understand
the
specific,
the
specific
interface
for
the
for
each
of
those
devices.
C
The
other
thing,
another
thing
we
get
out
of
modeling
as
well
is
the
ability
to
have
contract
enforcement
and
model
driven
clients.
So
with
that
contract
we
can
now
entertain
the
idea
of
you
know
having
enforcement.
So
if,
if
a
digital
twin
says
it
has
a
particular
property
or
state
that
could
be
enforced
at
the
appropriate
layer,
and
then
you
can
also
start
to
build
model
driven
clients
where
a
client
no
longer
has
to
say
you
know
it
works
with
device
xyz.
C
And
then
more
specifically,
dtdl
is,
is
really
a
meta
model,
so
we
call
it.
The
digital
twins
definition
language,
but
what
it
really
is
under
the
covers
is
a
set
of
rdf
classes
and
chapter
constraints
that
describe
the
meta
model,
which
then
you
know
in
turn
describes
what
you
can
actually
express
in
a
dtdl
model.
K
C
C
C
Okay,
so
I'll
move
on
to
an
example
here
of
d2dl
just
so
you
can
kind
of
get
a
sense
of
what
it
looks
like,
so
it
is
json
like
I
said
so,
and
specifically
json
lb,
and
this
this
example
model
here
is
expressing
an
interface
which
is
really
the
top
level
element
that
we
use
in
dtdl
to
describe
what
a
digital
twin
looks
like
so
interface
is,
is
describing
the
interface
that
the
digital
twin
exposes,
and
then
in
that
interface
you
can.
You
can
express
different
things.
C
This
example
shows
that
this
particular
digital
twin
has
a
property
with
the
name
name
and
a
and
its
data
type
of
string.
It
has
telemetry
that
it
sends
that's.
Temperature
called
temperature
and
its
scheme
is
double,
and
then
it
has
a
command
that
is
called
update
that
doesn't
take
any
arguments
and
doesn't
return
any
response.
C
And
then
just
to
expand
on
that,
and
I've
got
a
picture
of
this
as
well.
So
these
are,
these
are
all
of
the
top
level
concepts
that
you'll
see
in
dtdl.
So
the
interface
is
the
is
the
very
top
level
concept
that
you
use
to
describe
the
functionality
of
a
digital
twin
and
then
an
interface
really
then
describes
the
property
telemetry
command,
which
we
just
saw
in
the
previous
slide.
In
the
example,
and
in
addition,
it
can
describe
components
which
is
a
way
of
contain
a
way
of
expressing
containment
to
other
interfaces.
C
We
also
support
interface,
inheritance
and
first,
you
know
for
special
socializing,
your
digital
twin
interfaces,
and
then,
lastly,
this
idea
there's
this
idea
of
semantic
type
which
I
briefly
mentioned
before.
But
this
is
a
way
to
add
additional
semantics
onto
those
properties.
Telemetry
commands,
for
example,
where
you
could
say
not
only
is
the
telemetry,
you
know
a
named
temperature
and
its
data
type
is
double,
but
that
it
is
also
measuring
temperature
and
that
the
temperature
units
are
in
degrees
celsius
and
you
can
even
get
more
specific
semantic
types.
You
could
say
this.
C
Not
only
is
this
measuring
a
temperature,
but
maybe
this
is
measuring.
You
know
outside
air
temperature
or
body
temperature
on
different
types
of
temperature
as
well,
and
all
of
that
is
all
of
that's
there
to
provide
that
semantic
information
for
primarily
for
solutions
that
are
built
on
top
of
this
and
for
machines
to
go
to
reason
about
this
data.
G
C
Yeah,
so
I
think,
if
I
understand
the
question
right,
you're
asking
are
there?
Is
it
sort
of
unlimited
where
you
can
add
these?
I
don't
have
a.
I
don't
actually
have
a
good
example
on
this
slide.
The
way
we
express
this
is,
you
add,
just
add
more
types
here
that
create
an
array
of
types,
and
so
from
that
perspective
the
array
can
contain
as
many
different
semantic
types
as
you
want
it
to
contain.
C
G
C
One
now
I'm
trying
to
remember
the
name
there's
another
one.
I
think
it
was
qu
type
or
something
like
that
where
there
is
a
set
of
like
you're,
saying,
there's
a
there's,
a
vocabulary
of
those
stand.
You
know
based
on
standards,
a
set
of
of
useful
semantic
type.
What
we
call
semantic
ties
but
useful
of
these
useful
set
of
these
you
know
measurement
types
or
whatever
you
want
to
call
them.
Yeah.
C
J
C
Of
course,
we
we
have
one
that
we
use
for
our
own
services,
and
you
know
that
microsoft
produces
so
you
know,
for
example,
azure
has
an
azure
iot
hub
that
iot
devices
can
connect
to.
We
have
a
binding
what
we
call
a
binding
for
that
that
describes
how
dtdl
connects
to
the
protocols
that
are
used
there,
but
I
think
it's
an
area
where
we
want
to
actually
expand
that
and
collaborate
on
that.
More
generally,.
C
C
C
Okay,
great,
let's
go
on
to
so
this
slide.
I
called
the
y
slide
when
we
were
prepping
for
this.
This
meeting
it
sounded
like
there.
You
know
there
were
some
questions
around
what
you
know
why
utdl
and
why
choices
around
jason,
ld
and
those
kinds
of
things,
so
I
wanted
to
put
together
a
slide
here
and
be
able
to
have
a
chance
to
talk
about
some
of
that,
and
so
one
of
the
you
know
one.
C
I
think
very
reasonable
question
is
to
ask
why
dtdl
and
not
you
know
another
modeling
language
that
already
exists,
and
so
we,
we
certainly
did
look
at.
You
know
a
set
of
other
modern
languages
that
are
out
there.
You
know
from
things
like
opcua
and
borto
and
others,
and
you
know
all
of
those
all
of
those
are
great
and
all
of
those.
Actually
we
have
customers
that
use.
C
You
know
a
variety
of
those
modeling
languages
already
for
their
solutions,
and
so
we
certainly
want
to
be
able
to
support
those
customers,
but
we
also
found
that
we
wanted
to
be
able
to
support
these
other
kinds
of
things
in
you
know
in
our
iot
solutions.
So
things
like
device,
modeling
and
digital
twin
modeling,
we
wanted
to
bring
people
to
bring
those
things
together,
where
it's
not
only
about
devices.
C
So
those
are
some
of
the
reasons
why
we
why
we
chose
dtdl,
why
we
chose
to
do
dtdl
and
not
directly
adopt
you
know
only
one
of
the
other
modern
languages.
So
that
said,
though,
what
we,
what
we
actually
expected
to
be
able
to
do
is
customers.
Like
I
mentioned,
customers
are
using
a
variety
of
different
modern
languages
and
that's
where
we
want
to
start
to
look
at
the
interop
between
those
existing
modeling
languages
and
dtdl.
We
started
to
do
a
little
that
internally,
but
I
think
with
this
meeting
with
you.
C
C
Ld
is
really
great
for
that
and
trying
to
do
something
else.
You
know
in
json
and-
and
you
have
reuse
and
linking
would
probably
just
lead
you
to
inventing
essentially
json
lda
again,
and
so
we
we
pivoted
to
that
primarily
to
be
able
to
pick
up
that.
I
you
know
those
concepts
of
of
linking
that
have
proven
to
be
useful
now
for
us,
and
we
wanted
this
idea
of
semantic
types,
and
you
know
jsonld
and
rdf
really
allow
that
to
happen.
C
Another
another
thing:
I
guess
that's
not
on
the
slide
is
we
also
wanted
the
ability
for
multiple
authors
to
be
able
to
provide
information
about
a
digital
twin.
So
if
you
imagine
a
device
manufacturer
describing
their
device
through
a
dtdl
model,
that's
great.
They
can
describe
a
bunch
of
information
about
that
device,
but
they-
what
they
probably
don't
know,
is
how
that
device
is
actually
installed.
You
know,
is
it
installed
outside
or
inside
do?
Does
the
does
the
solution?
G
C
K
C
C
Quite
broadly
speaking,
developers
weren't
quite
ready
for
triples
and
we
didn't
want
to
have
to
push
the
requirement
to
do
triple,
processing
or
json
ld
processing
onto
customers
for
every
entity,
and
so
we
actually
have
this
split
where
we
use
json,
ldrdf,
etc
for
the
modeling
side
and
then
on
the
instance
or
entity
side.
We
just
use,
you
know
traditional
rest
apis
with
just
json
entities.
C
Yeah
sure,
like
and
and
earlier
benjamin,
you
can
jump
in
here
as
well,
but
I
I
would
start
with
there's
there's
actually
a
broad
set
of
of
different
use
cases
that
we
see
so
one
set
of
use
cases
we
see.
Are
you
know
the
physical
devices
that
are
that
are
connected
into
the
cloud,
so
you
may
have
a
set
of
devices
that
are
you
know,
monitoring
some.
C
You
know
a
manufacturing
line
or
monitoring
something
in
you
know
in
a
building
those
kinds
of
things,
then
we
get
and
so
there's
sort
of
some
a
set
of
device
oriented
use
cases
where
you've
got
those
physical
devices.
You
want
to
do
device
management
over
those
devices.
You
want
to
be
able
to
collect
data
and
analyze
data
and
produce
insights
from
the
data
coming
from
those
devices
and
the
modeling.
C
C
They
want
to
be
able
to
connect
them
together
into
systems
and
they
want
to
be
able
to.
You
know,
draw
data,
you
know,
aggregate
data
produce
insights
from
that
data
to
be
able
to.
You
know,
improve
energy
using
a
building,
for
example,
and
so
from
a
modeling
perspective.
We
wanted
to
be
able
to
provide
again
the
modeling
there
where
the
solution
can
understand
what
the
you
know,
what
the
what
the
entities
are
that
they're
connected
to.
J
Right
so
it's
a
follow-on
question.
Have
you
can
you
compare
this
to
like
what
platform
4.0
has
been
working
on
and
in
particular
I
don't
think
you
have
behavioral
modeling
explicitly
laid
out
here.
Can
you
like
comment
on,
like
you
know,
do
compare
and
contrast
with
like
a
platform,
zero
language
which
doesn't
matter.
J
C
C
J
It's
not
tied
to
opencua
it's
more
general
modeling
language.
More
like
yours
and
oh
okay.
I
wish
I
looked
at
the
name
while
you
were
speaking
so
we
could
refer
to
it,
but
yeah.
It's
it's
similar
concept.
I
think
it
also
includes
like
state
machine
definitions
and
things
like
this,
so
behavioral
modeling,
so.
C
So
I
I
don't
know
that
I'm
familiar
with
it,
then.
Okay,
maybe
we'll
follow
up
on
offline
I'll,
look
it
up
and
bring
up
next
time,
yeah.
Definitely,
let's,
let's
do
a
follow-up
offline
on
that,
because
it'd
be
great
for
us
to
learn
about
it
as
well,
and
understand,
understand
that
and
be
able
to
connect
that
you
know
you
know
figure
out
how
to
connect
that
or
you
know
interrupt
between
that
ddr.
C
Okay,
okay,
so
I'm
going
to
just
we.
We
talked
briefly
about
our
experience
with
jason
ld,
but
I
created
a
slide
here
just
because
we've
actually
been
pretty
happy
with
what
using
json
ld.
So
one
of
the
first
benefits
of
it,
of
course,
is
it's
json
and
that's
great,
because
that's
pretty
well,
you
know
pretty
well
understood
by
a
broad
set
of
developers
and
there's
lots
of
tools.
C
There's
lots
of
support
across
you
know
broad
set
of
languages,
programming,
languages,
which
is
great,
but
of
course
it's
also
more
than
just
json
it's
it
actually
brings
in
the
linking.
Of
course,
we
found
that
the
spec
was
a
well-written
spec
and
that
there
were
enough
tools
and
libraries
for
us
to
learn
about
it
and
use
it
and
be
successful
with
it.
You
know
internally,
before
we
even
went
to
customers
with
it
we
found
in
particular,
I
mean.
C
C
But
we
also
do
like
some
of
the
benefits
of
the
open
world
assumption
like
the
semantic
type
idea,
or
the
idea
of
that
we
talked
about
earlier.
The
idea
of
multiple
authors
contributing
to
the
definition
of
of
an
entity
or
of
a
type,
and
so
you
know
we
we
actually
get
benefit
out
of
the
moral
assumption.
In
some
cases,
we
put
constraints
on
it
as
we
expand
out
from
just
jason
ld
into
some
of
the
other
related
technology.
C
Like
shackle
the
shapes
constraint
language,
it
shackle
does
cover
a
lot
of
what
we
need
and
we
did
find.
There
were
some
constraints
that
we
wanted
to
express,
that
weren't
directly
accessible
in
shackle
and
if
you're
familiar
shackle,
shackle,
has
basically
an
escape
clause
where
you
can
use
sparkle,
which
is
the
actually
it's
the
query
language
for
triples.
A
A
J
Yeah,
I
was
going
to
say
something
similar
so
in
web
of
things.
We're
looking
at
discovery
and
discovery
is
basically
getting
access
to
the
metadata
about
devices,
and
part
of
that
is
doing.
Queries
on
databases
and
so
part
of
the
reason
to
have
semantic
annotation
is
to
be
able
to
find
stuff
like
all
the
lights
in
a
certain
area
and
so
sparkle.
Really
I
mean
it
can
be
used
for
constraints,
but
it
also
is
obviously
a
query
language,
but
it's
a
bit
too
powerful
for
constrained
devices.
J
So
jsonpath
is
not
just
like
you
know.
Doesn't
just
let
you
point
at
part
of
unless
you
do
queries,
it's
actually
related
closely
to
xpath
next
path,
even
though
it's
for
xml
now
is
json
support,
so
we've
been
comparing
and
contrasting
those
two
query
languages,
but
they're
more
syntactic
query
languages,
so
you
can
search
for
particular
terms,
but
you
can't
search
for
things
that
are
like
derived
by
inference
from
other
terms,
you
cannot
spherical,
but
it's
still
pretty
powerful
and
pretty
useful
if
you
fairly
constrain
semantic
tagging.
C
This
is
these
comments
for
more
about
what
we
use
internally
to
to
actually
implement
the
various
services
and
tools
that
we
have
around
dtdl
and
and
models,
but
I
think
that's,
but
I
think
what
you're
kind
of
getting
at
is
is
actually
there
is
value
in
exposing
some
of
the
at
least
some
of
the
query
side
for
people
to
be
able
to
use
yeah.
I
think
that
that
totally
makes
sense.
J
D
J
Your
system,
by
by
intention
or
by
or
by
accident,
whereas
it's
not
like
json
query,
is
much
more
straightforward
and
much
more.
You
know
controllable,
although
you
probably
want
to
limit
the
use
of
arbitrary
scripts
and
which
it
doesn't
allow
the
problem
with
this
path.
That
was
not
really
got
a
really
good
spec
right
now,
I
just
like
lay
a
blog
page,
and
so
it,
as
I
think,
was
alluded
by
like
carson.
It
needs
some
work
to
turn
into
a
real
spec
before
we
can
really
deploy
it.
J
C
Yeah,
no,
I
think
that
makes
sense
yeah.
We
we,
I
think,
probably
aren't
at
the
point
where
we
would
entertain
exposing
sparkle.
Because
of
the
reasons
you
just
said
and
but
having
something
like
something
more
constrained
where
we
can.
Actually,
you
know,
provide
some
controls
at
a
you
know
at
a
service
level,
or
you
know,
even
at
the
level
of
you
know,
code
running
on
on
an
edge
or
even
on
a
device
that
would
be
useful.
Yeah.
J
I
think
one
interesting
question
is:
is
there
an
intermediate
level
between
sparkle
and
json
path?
So
if
there
are
some,
we
do
simple
inferencing,
for
example,
limited
in
some
way
so
that
it's
not
not
just
syntactic
matching,
but
we
can
do
sparkle.
Like
things
that
I
mean
all
the
all
the
belgian
muscle
sparkle
has.
I
think
it's
an
interesting
question.
C
B
C
Yeah
so
now
I
think
the
next
couple
slides
get
into
some
of
the
you
know,
sort
of
expanding
beyond
just
what's
in
dtdl,
but
actually
how
dtdl
interoperates
and
where
we
wanted.
You
know
where
we,
where
at
least
we've
had
ideas
around
collaboration,
so
to
kind
of
get
us
into
that.
This
slide
talks
about
some
ideas
that
we
have
around
interoperability
with
other
specs
and
so
in
particular,
we've
been
internally
looking
at.
C
We,
we
don't
think
they're
perfect.
We
think
that
they're,
you
know,
depending
on
what
features
of
different
modeling
languages,
have
been
used,
that
not
everything
may
be
expressible,
you
know
either
in
dtdl
or
maybe
there's
some
things
in
dtl
that
could
be
expressed
somewhere
else
from
a
dtdl
perspective.
C
This
I
equals
number
structure
and
in
dtdl
for
example,
that
is
not
that
contains
characters
that
aren't
allowed
in
a
dtbl
name.
We
don't
allow
the
equals.
We
only
allow
really
alphanumeric
characters
because
it's
designed
to
be
used
in
in
programming
languages,
and
so
you
know
you,
you
then
have
this
problem
where
this
particular
you
know,
if
you,
if
you
were
translating
between
opcwa
and
dtdl,
how
do
you
represent
that
special
id?
C
That
has
so
you
don't
lose
that
data,
so
you
could
go
into
dtdl
and
still
then
consume
a
dtl
model
that
reference
back
to
some.
You
know
opcwa
element
and
what
we
look
at
here
is
this
idea
of
of
these
extension
types,
which
you
can
see
an
example
of
here
where
someone
could
define
an
extension
type.
I
just
made
this
one
up
called
opcwa
property
and
so
on
a
property
in
a
dtdl
model.
I
could
add
in
this
additional
type,
that's
called
opcwa
property
and
then
that
property
can
come
with.
C
C
C
C
C
That
would
then
you
would
then
have
in
essence
the
definition
and
if
you
look
at
this
from
a
dtdl
parser
perspective,
what
happens
there
is
that
is
that
the
the
parser
actually
would
expect
to
have
to
be
loaded
with
what
we
call.
I
guess,
call
a
package
and
we
haven't
settled
on
all
the
names,
but
a
package
of
the
definitions
of
what
opcwa
property
is.
C
C
This
is
exactly
where
at
least
our
implementation
and
our
parser,
where
we
do
use
shackle
to
say,
look
this
like
property
is
defined
actually
now
remembering
so
when
we
define
property
ourselves,
we
define
it
as
an
rdf
class,
but
we
also
define
the
shackle
constraints
that
go
with
that,
and
that
is
where
we
say:
property
must
have
name
and
it
must
be
a
string
and
it
must
have
schema,
and
it
must
be.
You
know
one
of
these
elements
and
then
optionally,
you
could
have
description
and
then
to
display
name
of
those
things
right.
L
C
Yep
and
so
then,
when
someone
authors
this
this
opcwa
property
element,
they
would
do
the
same
thing.
They
would
describe
it.
You
know
what
they
can
describe
in
rdf.
They
would
describe
that
as
an
rdf
class,
and
then
they
would
also
provide
the
constraints
so
like,
for
example,
opc
a
property
might
always
require
node
id
to
be
there.
That
could
be
expressed
in
that
extension.
B
C
Okay,
yeah,
and
so
then
that
sort
of
leads
us
to-
and
this
is
one
you
know
one
of
our
last
slides,
I
think
there's
a
discussion
slide
yeah,
but
so
this
is
really
leads
us
to.
Hopefully,
where
maybe
we
can
have
a
little
more
discussion.
You
know
kind
of
gauge
interest,
but
we
put
together
a
list
of
of
areas
that
we
are
interested
in,
collaborating
on
things
that
you
know
we
want
to
get
more
into
at
dtdl,
and
so
that's
this
list
you
can
see
here.
C
We
found
some
really
good,
really
good
libraries
in
some
primary
languages
and
not
as
much
support
in
others,
and
so
we're
interested
in
that
as
well.
In
sort
of
beefing
this
up
to
having
you
know
a
good
set
of
cross-language
source
software
stacks
for
for
really
primarily
json
ld,
that
would
be
production
grade
and
that
would
be
tooling
ready
for
us
as
well
and
then
more
stuff
that
we
probably
haven't
thought
of,
but
and
then.
C
Lastly,
I
just
mentioned
on
this
slide:
the
digital
twin
consortium,
which
is
a
a
consortium
that
microsoft
and
many
other
companies
and
organizations,
are
a
group
of
where
it's
designed
to
influence
digital
film
technology
and
it's
a
place
where
it
looks
like
there's
some
collaboration
that
will
be
starting
up
there
on
dtdl,
so
yeah.
So
I
wanted
to
pause
here
and
actually
kind
of
open
things
up
to
discussion.
C
K
Yeah,
I
have
a
comment,
so
I'm
sebastian
here
so
did
you
already?
I
wrote
the
wtc
web
of
things
activity
since
we
started
a
new
chart
beginning
of
this
year
and
we
have
there
the
topic
single
description,
template
and
the
thing
description
template
is
actually,
I
would
say,
a
hundred
percent
identical.
What
you're
doing
and
I
did
few
months
ago
I
did
a
kind
of
comparison
of
etdl
and
a
single
script
template
and
if
you
like,
I
can
quickly
show
you
the
comparison.
C
Do
it
do
I
have
to
I'll
stop
sharing
yeah
yeah
and
just
so
you
have
some
context
as
well.
We
have
been
looking
at
web
of
things
and
sort
of
keeping
you
know
track
of,
what's
what's
being
released
there
publicly
and-
and
I
agree
like
there's
a
there-
is
a
lot
of
a
lot
of
overlap
and
similarity
here,
and
so
I
think
it
would
be
great
to
you
know
to
have
some
more
discussions.
C
K
K
The
the
change
is
that
we
just
say:
okay,
this
is
as
the
single
description
form,
so
we
have
our
own
namespace
for
that
that
it's
also
by
the
w2z
and
what
you
see
here.
I
just
integrate
your
context,
which
you
have
defined
also
here
in
the
and
the
button.
Can
you
see
my
mouse
yep?
I
can
yep
yeah,
so
we
just
integrate
that
and
then
we
are
simple.
You
have
to
find
all
this
identical
stuff.
What
you
have
there,
so
you
have
id
here.
K
You
have
the
ad
type
here,
so
we
have
the
thing
as
a
core
class
definition
and
sync
description
which
we
integrate.
Then
I
simply
say:
okay,
this
definition
follows
the
interface
from
from
the
dtl,
except
of
the
display
name.
We
have
using
title.
The
title
is
something
yeah,
it's
just
a
different
name
and
yes,
and
what
is
also
a
little
bit
different,
but
only
a
naming
thing
is
what
you
have
called
as
property
command.
Telemetry
is
at
wwc
web
of
things,
property
action
events,
but
completely
the
same
intention
that
yeah.
L
J
I
also
want
to
say
we
shouldn't
put
too
much
emphasis
on
the
change
in
syntax,
because
in
fact,
our
original
syntax,
for
whatever
things,
looked
very
much
hdl
under
json
1.0.
It's
only.
We
went
to
1.1
that
we
could
switch
to
the
you
know,
map
approach
that
was
a
little
bit
cleaner
and
a
bit
more
didn't
have
to
have
all
the
at
types
everywhere,
but
I
think
you
know
we
we
should
look
in
in
the
devils
in
the
details
here.
J
L
That's
true
in
terms
of
integration.
This
week
you
could
provide
a
td
template
and
a
td
that
would
give
a
web
of
things
interface
to
a
dtdl
system
that
uses
dtdl,
and
likewise
you
could
probably
import
things
as
td
templates
into
dtdl,
so
it
could
probably
work
both
ways.
You
could
have
things
that
are
described
using
td,
that
you
could
import
and
it
seems
like
this
is
pretty
low,
friction
and
low
loss.
J
J
I
suspect
there
are
some
especially
under
events
and
actions,
because
we
ran
into
a
lot
of
fun
fun
things
about,
and
things
like
you
know,
but
I
think
it's
definitely
worth
looking
at
to
uncover
gaps
at
the
very
least
but
but
yeah.
I
think
if
it's
just
a
different
syntax
and
there's
a
bi-directional
converter,
then,
for
example,
having
links
in
a
thing
description
that
point
to
a
dtl
as
its
you
know,
template
would
then
be
feasible
if
they
agree
formally
interconverted.
C
I'm
I'm
very
interested
in
understanding
where
we
can
do
that
versus
conversion,
like
I
think
conversion
is
you
know
you
know,
is,
is
useful
and
is
probably
valuable
in
many
cases,
but
I
can
also
imagine
if
someone's
already
got
their
their
td
template,
for
example,
or
a
set
of
those
for
for
their
solution.
Why
even
convert
them?
Could
we
reference
those?
J
J
Like
converted,
I
just
meant:
are
they
semantically
equivalent
yeah,
it's
possible
to
do
a
one-to-one
conversion,
then
they're
semantically
equivalent,
and
then
you
can
just
you
know,
get
the
information
directly
and
I'm
just
saying
proving
that
they're
equivalent
can
be
accomplished
by
building
a
converter.
I
guess
another
question
here,
though,
is:
what's
your
standardization
plan?
E
Hi
this
is
elio,
so
we're
the
long-term
plan
is
definitely
we
would
like
to
make
this
standard.
We
do
not
have
a
plan
that
is
publicly
shareable
right
now,
we're
definitely
working
on
it,
we're
very
eager.
We
know
that,
to
a
certain
extent
we're
late,
starting
that
we're
just
like
so
busy
getting
stuff
out,
so
that's
definitely
high
on
our
priority,
but
we
don't
really
have
like
a
specific
plan,
we're
also
open
to
suggestions.
E
I
I
think
brian
was
like
very
very
good
with
that.
If
you
say
hey
look
this,
should
you
consider
this
organization,
or
this
specific
thing
seems
relevant-
we're
definitely
open
to
those
kind
of
suggestions
as
well.
Well
we're
doing
our
own
process
internally,
but
definitely
very
open
to
see
what
what's
the
best
avenue.
E
We
absolutely
want
to
have
like
an
open
stance,
we're
working
on
how
to
a
more
formal
way
to
start
collaborating
on
on
the
new
things
that
we're
doing
on
this,
and
we're
definitely
definitely
gonna
like
to
start
being
to
make
this
like
more
of
a
standard
and
open
process.
Open
development
process
like
in
general.
K
C
K
Yeah-
and
this
was
actually
what
I
was
with
chris
queen,
exchanging
and
and
yeah,
and
then
one
day
he
doesn't
answer
anymore,
and
so,
but
I
think
it's
really
almost
identical
what
we're
doing,
and
I
think
we
will
be
more
strong
and
work
on
that
and
right
and
if
you
are
planning
to
also
to
to
address
protocol
bindings.
I
think
this
is
what
we
already
did
in
a
couple
of
years
about
this
and
have
a
lot
of
experience
and
addressing
this
in
plug
fest,
etc.
I
think
you
can
really
benefit
of
that.
F
And
this
is
speaking,
can
maybe
the
group
at
large
help
us
at
microsoft
understand
when,
where
you
would
see
in
in
the
future
the
discussions
happening,
because
I
mean
there's
dtdl,
where
we're
on
github,
so
maybe
like
the
particular
example
that
you
shared
sebastian.
That
could
be
an
issue
where
we
discussed
the
stuff,
but
of
course
that
also
has
some
web
of
things
bits
to
it.
So
discussion
could
also
be
on
the
web
of
things
mailing
list
and
or
this
could
be
someplace
else.
K
J
So
certainly
that's
that's
feasible
and,
as
we
said,
we
have
a
charter
to
build
a
template
definition.
So
I
think
you
know
that
would
be
one
path
for
the
fast
track
and
standardization
effort
might
tweak
a
few
things
to
bring
things
into
alignment
on
both
our
sides.
I
think
it'd
be
very
valuable
in
alignment
a
year
and
a
half
now
right.
J
B
A
Yeah,
you
asked
what
would
be
a
good
forum
for
conversations
about
this.
You
are
in
one
of
those
forums,
so
this
is
exactly
what
we
have
created
wishing
for
to
get
an
open
conversation
going
on
between
different
boards
and,
of
course,
it
would
be
possible
to
put
through
this
conversation
here
as
well
before
our
time
runs
out.
I
wanted
to
quickly
show
a
couple
of
slides
that
we
made
this
morning
and
the
best
I'm
going
to
steal
your
presentation.
B
A
We
looked
at
one
of
the
examples
in
in
the
github
repository
with,
which
is
the
copy
on
the
slide.
It
will
look
familiar
to
you
because
it's
another
thermostat
and
there
are
things
in
there
like
telemetry
property
and
command,
which
are
in
sdf
events,
properties
and
and
actions,
and
various
descriptions
and
and
schemas
and
and
so
on.
A
There
is
also
for
for
the
action
here
the
temperature
report.
There
is
a
return
type
which,
which
is
described
by
a
schema,
and
especially
the
the
terminology
here,
pretty
much
maps
to
sdf
terminology,
so
property
action
event
is
property
command.
Telemetry
object
is
probably
close
to
component.
We
may
have
to
work
a
little
bit
on
the
object
terminology,
input,
data
and
output
data
as
requests
and
response
label
is
displaying
and
so
on.
A
So
that's
pretty
much
a
one-to-one
thing,
so
it
will
be
pretty
easy
for
a
translator
to
actually
handle
this
and
then,
of
course,
the
the
there
are.
Things
like
like
json
schema
descriptions
which
which
I
think
it
would
not
include,
and
these,
but
these
can
be
mapped
with
little
effort
between
the
dl
and
spf.
A
I
have
no
idea
what
that
is,
so
we
didn't
get
it
this
morning
and
the
actual
thermostat
is
an
sdf
object
which
in
turn
has
an
sdf
event,
and
that
is
a
little
bit
clumsy
in
sdf
right
now,
so
you
have
to
have
a
pointer
to
a
data
structure.
Here
the
sdf
output
data
we
can
clean
up
in
the
next
version
a
little
bit.
We
have
a
property,
we
have
two
properties,
target
temperature
and
max
temp
since
last
reboot
and
again,
these
are
json
schema
or
type.
A
Descriptions
with
type
number
units
is
something
that
is
specific
to
sdf,
that
is
using
the
cml
unit
names
and
we
could
make
another
table
that
maps
the
cinema
unit
names
to
the
gtd
unit
names.
So
it
should
be
relatively
easy
to
get
a
converter
going
between
the
two,
and
this
is
really
what
we
are
trying
to
push
forward
in
in
the
sdf
world
that
we
actually
have
converters
and
we
we
have
a
process
called
compressor
pressure
testing,
which
means
we
we
feed
models
into
the
converters
and
see.
A
Can
we
actually
generate
useful
sdf
for
that,
and
that
is
essentially
what
moves
the
language
forward.
So,
for
instance,
if
you
look
closely
into
this
sdf
action,
that
is
a
little
bit
clumsy
how
the
output
data
is
defined.
With
all
these
json
pointers
somewhere,
we
can
make
this
a
little
bit
simpler,
yeah
and
and
the
the
actual
sdf
data
are.
The
data
types
that
are
defined
here
are
pretty
straightforward.
A
So
this
is
really
one
of
the
things
that
that
we
we
could
push
forward
quickly,
make
sure
we
have
the
converters
available
and
to
do
this.
Of
course,
it
would
be
nice
to
have
more
than
two
dtdl
models,
so
if
you
have
a
hundred
or
so
that
would
be
good
for
for
actually
pressure
testing
converter.
So
if
you
can
point
us
to
resources,
we
can
use
for
that.
C
Yeah,
I
think
this
is
really
encouraging.
Actually
I
I
have
to
apologize,
I'm
not
super
familiar
with
sdf,
but
I
already
took
a
note
earlier
on
to
go,
learn
more
about
it
after
this
meeting,
so
I
will
definitely
go
do
that
for
myself.
I
think
in
terms
of
getting
more
d2dl
models,
we
should
be
able
to
provide
some
more
of
those.
C
You
know
many
of
the
ones
that
we're
working
with
that
we
see
internally
are
are
from
customers,
and
so
we
probably
wouldn't
be
able
to
share
those,
but
there
probably
are.
I
do
believe
that
we
have
a
good
set
of
example,
models
for
sure
around
the
digital
twin
space,
so
things
that
are
some
devices,
but
also
some
non-device
things,
and
so
I
think
we
can
probably
pull
from
those
examples
and
tutorials
that
we
have
to
get
a
better
set
here.
C
L
It
would
be
interesting
to
look
at
how
you
how
you
have
models
to
represent
things
like
the
temperature
transmitter,
or
you
know,
level
control
or
something
like
that
right,
a
pid
controller.
You
must
have
some
some
generic
dtdo
models
that
aren't
super
specific
or
proprietary
and
just
to
see
how
the
uris
map
to
the
concepts
and
and
is
an
interesting
thing
because
we
have
we
have.
L
C
Yeah,
actually,
to
that
point,
we've
actually
for
for
now,
anyways
sort
of
purposely
stayed
away
from
trying
to
create.
You
know
a
set
of
of
models,
for
you
know
for
any
particular
domain,
whether
it's
you
know
iot
devices
or
building
management
or
energy
management,
or
anything
more
thinking
that
what
we
want
to
try
to
do.
There
is
engage
with
the
domain
experts
to
to
help
us
build
those
up,
and
so
we
don't
currently
have.
We
aren't
currently
pushing
you
know
a
set
of
if
you're,
implementing
a
thermostat.
You
should
use
this.
J
Yeah,
so
actually,
I
think
one
day
the
model
has
two
things
that
are
interesting:
one
is
the
large
collection
of
you
know,
actual
device
models,
there's
just
kind
of
a
framework
in
terms
of
you
know,
capabilities
and
objects,
and
and
kind
of
like
a
modularity
and
one
thing
that
occurred
to
me
previously,
I've
mentioned
you
know
we
have
this
gap
between
full
sparkle,
semantic
queries
and
kind
of
pure
syntactic
queries,
which
only
give
us
one.
You
know
particular
keyword,
I
think,
a
interesting
intermediate
zone.
J
There
is,
if
you
have
you,
know
a
particular
semantic
structure
in
place.
That
is,
for
example,
hierarchical
like
maybe
we
don't
allow
cycles
and
graphs.
We
only
allow
like
trees
or
or
some
kind
of
more
strict
subclassing
mechanism,
and
the
infant
seems
a
lot
easier
and
a
lot
more
efficient,
and
it
might
be
very
interesting
to
look
at
you
know
more
constrained
semantic
models
that
are
still
powerful
enough
to
capture
the
things
you
want
to
talk
about
in
iot,
space.
J
Yeah
yeah,
so
I
think
I
think
it'd
be
very
interesting
to
think
about
also,
like
I
said,
the:
what
kind
of
infancy
do
we
need,
and
I
think
a
lot
of
it
is
simply
super
class
subclass
type
of
inferencing
right
and
that
can
be
a
lot
more
efficient
than
just
general
graph.
You
know
inconsent,
and
I
think
you
know
maybe
we
should
talk
about.
J
C
Yeah-
and
I
actually
think
that
point's
really
interesting,
that
you
know
what
how
much
inferencing
do
you
actually,
you
know,
do
you
actually
need
for
solutions?
What
we're
seeing
right
now
is
many
of
our
customers
aren't
really
there
on
you
know
needing
inferencing
or
understanding
what
the
use
cases
are.
C
So
we
ourselves,
don't,
I
would
say,
don't
fully
understand,
what's
needed
there
right
now,
customers
seem
to
be
at
the
place
where
they
do
want
the
you
know
a
graph
of
digital
twins,
so
a
system
of
digital
twins
represented
they
want
to
be
able
to
model
that
graph
as
well
as
have
the
entities
or
instances
of
that,
and
they
want
to
be
able
to
query
that
at
least
at
a
graph
level.
You
know
so
right,
I
I
know
I
have
a
device.
J
Some
like
thought,
experiments
about.
You
know
I
am
a
user.
I
need
to
do
this
task.
What
kind
of
queries
would
I
write?
I
might
want
to
know
what
kind
of
lights
are
used
for
task
lighting.
I
need
to
access
all
the
task
flights
or
all
the
hallway
lights
or
yep.
You
know
or
all
the
incandescent
lights
or
I
need
to
like
look
at
power
consumption
for
things
on
this
floor.
I
think,
if
we
think
about
you
know
work
through
it,
what
kind
of
inferencing
capabilities
we
want.
J
I
can
certainly
like
I
said
I
think,
abstraction
I
I
want
to
know
all
the
light,
not
just
the
incandescent
lights
right.
So
I
need
to
have
like
a
super
class
ability
to
search
for
things.
Maybe
I
only
only
tag
things
as
being
you
know
a
certain.
You
know
model
of
light,
but
it's
it's
a
subclass
of
general
classic
light,
so
I
switch
on
lights.
I
should
pick
all
the
things
that
are
tagged
as
personally,
so
I
think
we
can
define
some
use
cases
and
then
go
back.
C
A
A
Okay,
so
what
we
will
do
is
we
will
send
a
doodle
to
the
fingerthing
research
group,
mailings
and
and
everyone
who
is
not
subscribed
to
that.
This
is
a
low
volume
milling
view.
So
it's
probably
a
good
idea
to
join
that
to
know
what's
what's
going
on
in
the
thinking
research
group
in
in
the
wish
activity,
and
then
we
can
look
when
exactly
we
are
going
to
have
or
the
next
meter.
J
G
A
C
Yeah
I
mean,
I
think,
that
the
the
things
we
had
talked
about
from
our
side
that
we
wanted
to
to
get
out
of
this
call
and
is,
is
how
to
collaborate
going
forward
and
what
the
areas
of
collaboration
areas
of
interest
are,
and
I
think
we
got
some
of
those
and
as
next
steps.
So
what
I've
got
is
yes,
sending
the
some
more
models
and
then
also
looking
at
collaboration
between
sdf
and
dtdl,
as
well
as
web
of
things
in
dtdl,
and
I
guess
they
say
one
dm
sdf.
G
C
J
K
C
L
C
D
A
A
G
A
G
Okay,
so
anyway
not
much
has
happened.
I
just
thought
in
terms
of
what
needs
to
be
done.
I
guess
everybody
remembers.
It
was
a
month
ago
already
we
discussed
whether
we
should
do
a
document
that
does
a
description
of
iot
standards
in
a
common
way,
so
that
one
can
relate
so
basically
to
do
the
abstract
definition
of
of
the
problem
and
the
concept.
Actually
I
have
that
slide
that
wasn't
sure.
If
microsoft
guys
are
gonna,
be
there
or
not,
but
we
wanted
to
create
the
paper.
G
The
otg
draft
that
does
standard
description
in
a
consistent
manner
and-
and
we
discussed
what
the
truth
shouldn't
do.
I
did
a
straw
man
on
the
common
criteria.
There
wasn't
a
proposal,
not
much
discussion
and
michael
koster
and
michael
mccool
offered
to
contribute
some
of
the
previous
work
and
the
working
progress
that
they
had
so
in
terms
of
so
I
was
thinking
okay,
we
need
to
start
and.
G
G
My
belief
is
a
rhetoric,
that's
shared
by
others,
that
we
should
aim
for
a
more
general
audience,
not
just
informal
connoisseurs
like
us.
I
mean
people
who
are
familiar
with
at
least
one
probably
several
models,
but
rather
to
somebody
a
more
general
practitioner
or
researcher
of
iot
who
basically
is
kind
of
aware
of
the
problem,
but
not
of
the
details.
So
I
would
just
have
some
pros
to
explain
the
lay
of
the
land
what
it
is
and
in
addition
to
tables
and
comparisons,
I
think
just
labels
and
comparisons.
G
In
my
experience,
don't
quite
communicate
same
thing.
They're
complementary,
but
pros
is
important.
So,
in
any
case,
I
was
going
to
draft
some
pros
after
august,
as
carsten
pointed
out
and
includes
the
criteria
and
terminology
description,
and
hopefully
at
least
some
feedback
from
this
group
on
the
written
document.
I
guess,
based
on
the
past
experience
of
the
documents
we
were
recently
reviewing,
that
might
work
better
than
just
the
powerpoint
solicitation.
J
Well,
yeah,
so
I
was
going
to
say:
I'm
happy
to
contribute.
I
think
we
need
to
focus
on
here
is
just
getting
logistics
set
up
so
that
we
can
do
so.
You
know
setting
up
you
know,
github
repo
or
whatever,
maybe
a
meeting
with
a
smaller
number
of
people,
so
that
we
can
just
go
on
and
work
on
things,
and
I
think
I
can
start
as
simple
as
an
email
between
I
think,
michael
koster
and
myself
volunteered
already.
I
think
others
want
to
do
that.
M
A
J
A
J
A
J
J
M
J
J
G
G
G
Basically
I
I
see
them
as
the
same
and
ocf
is
what
I
would
start
with
and
then
iterate
in
terms
of
you
know,
are
we
getting
the
vocabulary,
use
it
as
a
pressure
test,
we're
getting
the
vocabulary
right
of
the
taxonomy
and
then
covering
the
right
basis
and
then
possibly
expanding
the
brothers.
At
that
point,
I
would
play
a
person
something
or
another
of
the
paper
and
then
go
forward.
A
B
G
A
D
K
Well,
so
I
would
like
to
present
the
id
which
we
would
like
to
start
now
at
a
wc
web
of
things
group,
namely
to
define
for
the
co-op
protocol
rdf
representation
for
that.
So
maybe
you
are
already
familiar
with
the
web
of
things
and
thing
description
that
we
have
also
covered
protocol
bindings
in
there.
So
that
means
we
are
first
of
all
thing.
K
K
This
kind
of
process
to
define
our
ontology
rdf
ontology
for
co-op,
where
we
can
use
or
reuse
the
existing
terms,
which
should
be
very
equivalent
what
you
can
find
also
in
the
co-op
specification,
also
in
rdf,
based
representation
like
in
the
description
and
right,
and
the
reason
why
I
like
to
start
the
discussion
here.
So
first
of
all,
I
would
like
to
make
aware
of
that.
So
we
did
around
one
month
ago.
K
A
kind
of
kickoff
meeting
and-
and
one
of
important
point
is
that
the
idf
should
be
aware
of
that
activity,
and
we
would
also
get,
I
would
say,
kind
of
official.
Okay
with
that.
That
is
a
kind
of
agreement
that
we
are
doing.
This
kind
of
work,
because
co-op
belongs
to
idf,
as
you
know,
and
and
what
we
just
want
to
do
is
to
make
our
rdf
representation
of
the
most
common
use
terms.
K
And
and
that's
the
reason
I
want
to
make
aware
of
of
that
and
and
ask
if
there's
any
objection
on
that
to
to
to
starting
this
work,
so
the
idea
is
that
klaus
heart
is
coordinating
this
kind
of
work
and
also
other
members
will
contribute
to
this
contribution
and
also
it's
a
call
to
to
everyone
who
is
also
into
this.
This
walk
to
a
simple
yeah
to
join
this
activity
here
and
right:
that's
it's
all
and
yeah,
I'm
open
for
a
question,
any
feedback,
etc.
A
A
J
J
I
think
carson
one
is
a
machine,
readable
version
of
this
data
expressed
in
rdf.
In
fact,
we
actually
want
to
have
a
fixed
url
for
it,
so
we
can
reference
it
in
a
context
file
in
the
description
yeah.
So
I
think
part
of
it
is
simply
mechanical.
Simply
taking
this
information
just
pointed
out
and
converting
it
into
a
a
ttl
file
that
we
can,
we
can
link
to
yeah.
So
the
definitions
of
december.
J
K
D
A
So
it
may
not
cover
everything,
but
it
covers
all
the
things
that
are
growing,
so
you
may
need
a
couple
more
things
that
actually
come
from
the
document,
but
all
the
things
like
like
option,
space
method,
space,
rt
values
and
and
all
this
stuff
are
being
maintained
by
ayana,
so
having
the
the
ability
to
pull
in
ayanna,
xml
and
and
turn
this
into.
Something
like
rdf
might
be
something
that
they
we
should
be
cultivating
here.
In
wishing.