►
From YouTube: T2TRG Interim Meeting, 2021-10-25
Description
T2TRG Interim Meeting, 2021-10-25
A
A
Anything
that
has
a
relevant
that
has
happened
since
the
last
time
since,
since
you
presented
the
dddl,
but
then
I
think
the
bulk
of
the
time
and
a
half
of
perhaps
the
meeting
was
planned
that
we
could
discuss
on
this
way
forward
with
the
interwork
discussing
some
of
the
things
that
we
have
discovered
here
and
see
how
we
could
actually
improve
across
ecosystem
here.
Crosstalk
system
interoperability
here.
A
B
One
is
that
I
think
last
time
we
talked
about
the
the
iot
plug
and
play
device
models
repository,
which
is
basically
a
github
repository
where
we
collect
together
dtdl
device
models.
For
you
know
devices
that
are
available.
You
know
in
production
devices
that
you
can
then
use
with
our
services,
and
so
that's
been.
B
So
that's
that's
been
one
thing:
that's
continued
to
grow
there.
You
can
see
just
more
and
more
models
showing
up
there
and
then
the
other
part
of
dtl
that
that
I
think
we
talked
about
last
time
as
well-
is
the
set
of
ontologies
that
we
have
so
we've
got
one
for
smart
buildings
based
on
real
estate.
B
Core
we've
got
energy
grid,
one
for
energy
grid,
which
is
based
on
a
standard
that
I
don't
remember
off
top
my
head
and
then
we've
got
a
smart
cities,
one
as
well,
and
so
those
are
other
places
good
places
to
look
at
how
we're
doing
d2dl
modeling
for
digital
twins,
in
that
case
less
about
devices
for
those
ontologies
and
more
about
modeling,
the
other
parts
of
digital
twins.
So
you
know
things
like
buildings
and
cities
and
those
kinds
of
things.
B
A
A
A
A
A
So
what
we
noticed
that
in
them
in
detail
the
telemetry
type,
you
can
do
complex
things
like
you,
put
an
array
there
or
an
object
and
describe
all
the
details.
But
when
it
comes
to
the
properties,
you
only
have
a
simple
like
string
or
an
integer.
First
of
all
wondering
like
what
is
the
background
on
this
design
decision
and
then
got
a
follow-up
question
like
if
there
would
be
more
complex
things.
A
B
Yeah,
actually
in
dtdl
properties
can
be
complex
types.
The
only
type
that's
not
supported
right
now
is
arrays
in
properties.
So
and
that's
something
that
we
want
to
correct
in
time.
We
just
haven't
been
able
to
get
that
that
far
yet,
but
you
can
do
objects
and
there
is
some
depth
limit
to
objects.
I
think,
but
you
can
do
objects,
you
can
do
enums,
and
you
know,
of
course
the
simple
types
like
you
like
you
saw.
A
A
A
B
B
A
D
So,
in
other
words,
if
I
have
an
rgb
color
can
I
go
then
and
look
at
red
and
green
and
blue
as
separate
components,
and
you
have
something
that
describes
what
what
those
the
meaning
of
those
components
is
etc
and
like
same
for
enums.
If
I
have
a
set
of
enums,
can
you
can
you
point
like?
I
guess
dtdl
is
rdf-based,
so
you
theoretically
should
be
able
to
do
this.
I
guess
what
I'm
asking
is.
Is
this
a
pattern
you
use
in
your
definitions.
B
Yeah,
actually
it's
a
really
great
great
question,
so
we
think
about
properties
in
two
ways.
One
is
that
we've
made
it
through
with
the
so
you've
got
the
modeling
side
of
things
and
then
you've
got
the
sort
of
the
instance
side
of
things
on
the
instant
side.
We
set
it
up
so
that
when
you're
working
with
properties,
you
can
work
with
the
whole
value
like
you
could
set
your
you
know
in
your
rgb
color
example.
B
You
could,
you
know,
get
or
set
the
whole
value
with
it
with
the
three
or
the
three
values
inside,
but
we
do
at
the
modeling
level.
Let
you
you
do
model
each
of
those
separately.
So
you
model,
you
know
the
r
and
the
g
and
the
b
separately,
and
the
intention
is
also
to
allow
you
to
attach
semantic
meaning.
You
know
semantic
types
and
other
things
to
those
individual
fields
within
that
complex
type.
B
D
Yeah,
likewise
enums,
when
you
have
an
enum
and
you
have
a
set
of
potential
values,
it
would
be
nice
if
each
of
those
could
sort
of
be
a
a
note
in
the
graph
as
well,
and
then
you
can
have
you
can
expand
those
out.
Sometimes
I,
when
describing
things
like.
Oh,
I
want
to
think
about
in
ashrae,
2
and
223p.
They
have
a
thing
called
unit
quantity
kind,
which
is
sort
of
like
an
enum.
But
then
each
of
those
is
actually
a
a
unit
quantity.
You
know
structure.
D
B
Yeah
yeah
and
in
the
in
the
sort
of
underlying
modeling
graph,
though
they
are
separate
nodes,
like
you,
said,
we've
just
at
the
dtdl
language
level,
we
have
we've,
we've
purposely
kind
of
kept
it
limited
in
what
you
can
do
both
to
help.
You
know
sort
of
focus,
focus
model.
Authors
on
you
know
being
able
to
just
focus
on
the
certain
things
that
to
get
started,
and
but
we
do
expect
to
be
able
to
extend
that
and
that's
what
we've
been
working
on
some
of
that
stuff
as
well.
A
Okay,
good.
Well,
then,
that
that
clarifies-
and
I
also
I'm
looking
forward
to
see
your
your
design
on
that,
because
we've
been
kind
of
talking
about
the
similar
topic
when
it
comes
to
the
stf
design,
because
if
you
can
do
you
can
do
complex
types
but,
as
you
said,
it's
very
useful
to
be
able
to
attach
semantics
on
those
parts
and
kind
of
what
are
the
right
tools
and
modeling
techniques.
For
that.
That,
then,
would
be
you
know
suitable
with
with
the
different
ecosystems
such
as
dddl.
B
A
Okay,
I
guess
team
and
I
mean
also
when
it
comes
to
sdf.
I
mean
we're
not
not
planning
to
get
the
first
version
of
sdf
publish
as
an
rfc,
but
then
probably
doing
these
kind
of
details
and
perhaps
being
an
extension
towards
sdf.
So
maybe
the
key
thing
would
be
for
us
on
the
stf
side
to
have
the
right
kind
of
extension
models
that
support
this.
So
I
was
wondering,
like
I
mean
whenever
you
have
a
chance
to
to
talk
more
about.
A
B
Yeah,
I
know
that
that
sounds
great.
I
actually
like
what
you're
saying
about
extensions
in
sdf
I've
been
sort
of
on
the
side.
Looking
at
how
could
we,
you
know
enable
extensions
in
dtdl
so
that
we
could
actually
use
other
ontologies
or
you
know
other
rdf
definitions
like
things
like
qudt
and
things
like
that.
We
don't
have
anything
formal
there
yet,
but
it's
it's
an
area
that
I
think
was
was
I
got
interested
in
from
our
from
the
last
meeting.
I
was
in,
I
think,
back
in
july,
so
I
think
it's
great.
A
A
We
didn't
quite
conclude
yet
last
time
if
there
was
a
appropriate
dtl
unit
namespace-
and
you
mentioned
last
time
that
you
there's
a
few
different
sources
where
you
had
pulled
like
the
units
you
use
in
the
video.
But
then
you
had
added
some
on
your
own
and
I
guess
slug
was
one
of
those
that
that
you
had
added.
Then
the
quest
question
would
be
like
like
if
we
would
use
this
kind
of
a
uri
model
for
those
units,
for
example
specific
to
dddl.
A
A
Yeah
it's
more
like
if
we
would
use
if
you
would
use
the
uni
dtl
digital
specific
units
in
sdf
models.
We
will
do
it
put
the
ui
there,
but
I
guess
you
would
do
a
similar
thing
in
individual
like
if
you
refer
to.
I
don't
know
qudt
units,
but
if
there
are
units
that
are
ddl
specific,
what
would
that
uri
be
like?
Are
you
planning
to?
You
know,
publish
the
ddt
specific
units
as
a
formal
ontology
somewhere
that
we
could
then
refer
to
or
is
it
should
be?
A
B
Yeah
so
yeah
yeah
we
do,
we
do
have
a
a
namespace
for
the
units
and
I'd
have
to
go
look
up
to
find
exactly
what
it
is.
You
can
actually
see
it.
I
think,
because
we
do
publish
our
context,
files
for
dtdl
those
are
out
in
our
repository,
so
I
can
go
look
there.
We
can
grab
it
from
there
and
put
in
the
notes,
and
so
so
we
do
have
full
uris
for
those.
B
A
C
C
C
B
B
C
B
Yeah-
and
I
can
just
comment
on
that
as
well-
you're
right,
we
don't
have
a
way
to
say
to
to
say
in
some.
You
know
machine,
readable
way,
what
the
kind
of
relationship
is
currently
the
best
we
have
right
now
is
we
have
the
name
field
in
a
relationship
where
you
can,
you
know,
set
the
name,
but
of
course
that's
just
you
know
the
a
a
human
or
a
model
author
can
can
read
that
and
understand,
probably
what
the
name
means,
but
it's
not
a
it's,
not
really
machine
readable.
B
C
Yeah
cool
the
other
thing
that
I
hit
there
was
this
copyright
and
license
parts
that
are
missing,
so
I
understand
that
you
have
somewhere
generic
copyright
or
license
information,
so
that
can
be
basically
copied
to
sdf
to
those
fields,
but
on
the
other
hand,
when
you
are
doing
sdf2dtdl,
we
actually
lose
that
information
completely.
Then
we
can't
store
it
anywhere.
C
C
C
Any
better
thanks
yep,
so
basically
we
I
just
give
the
we
have
the
conversion
tool
with
where
I
give
the
ontology
directory
and
the
output
directory
and
run
it.
So
it
will
make
automatic
conversion
for
each
of
the
each
of
the
models
and,
as
we
can
see
here,
we
have
the
corresponding
directories
and
check
what
what's
there.
So
it's
now
named
with
sdf
object
and
then
the
original
name
plus
sdf
json.
C
Let's
take
one
of
those.
If
you
can
see-
hopefully
it's
not
too
small,
I
can
try
to
boot,
it's
bigger
but
starts
to
confuse
my
screen.
So
basically
it
converts
it
to
sdf
with
the
dtdl
ac
dc
terminal.
As
the
title,
then
we
have
the
rest
of
the
header
fields
still
empty
and
we
have
it
collects
or
gets
the
actual
namespace
dtmi
digital
twins
and
gsild,
and
then
we
have
also
the
terms
namespace.
C
That
should
give
us
give
the
type
of
the
actual
relationship
and,
at
the
end
end
of
the
file.
You
can
see
the
sdf
relation
where
the
operational
limit
set
is
one
relation
and
type
is
currently
to
be
defined.
Target
is
the
object's
namespace,
with
the
operational
limit
set
as
the
specific
item
and
then
the
description
field.
C
C
B
B
Did
you
do
it
as
json
ld
or
json,
just
as
json
yeah?
There
may
be
some
that
that
may
be
interesting
at
some
point,
because
I
know
that
there
are
that
sometimes
the
json
varies.
You
know
because
json
ld
allows
different
forms,
you
know
you
can,
you
can
have
absolute
uris
or
you
can
have
relative
uris
in
the
file,
and
I
know
that
some
of
these
files
will
have
sometimes
mixed
things,
because
some
of
them
are
generated
so
that
that
that
can
be
interesting
if
you're
just
doing
json
processing.
C
Yeah,
okay
yeah,
I
was
actually
checking.
I
have
a
small
demo
web
web
page
where
I
can
convert
from
other
models
to
sdf
and
then
from
sdf
to
other
other
models.
But
at
least
web
of
things
thing
model
didn't
work
always
so
it
would
crashed
at
some
point.
So
I
don't
know
yet
where,
where
the
actual
problem
is
with
this
but
but
we'll
see,
I
have
discussed
with
the
web
of
things
implementer
and
the
young
roman
so
see
his
response
at
least
quickly.
If
there's
some
problems
with
that
code,
so,
but
it's
really
interesting.
D
You
mentioned
that
json,
ld
and
and
processing
I'm
wondering
in
dtdl.
Do
you
use
any
rdf
constraint
tools
like
do
you?
Do
you
have
rdfs?
Do
you
use
shackle,
but
I'm
not
maybe
I
should
maybe
I
could
determine
this
just
by
looking
into
things,
but
you
know
that
sort
of
related
to
the
thing
we
just
discussed.
B
B
You
know
in
some
of
our
scenarios
because
of
the
runtime
performance
requirements,
the
perf
we
did,
it
did
not
meet
our
performance
needs,
and
so
what
we've
done
is
we've
actually
taken
us
a
combination
of
shackle
specifications
and
then
we've
we've
added
some
of
our
own
sort
of
extensions.
If
you
will
to
that
and
we've
actually
what
we
do
in
our
parsers
we've
we've
pre-built
the
shackle
constraint
so
that
we
don't
have
to
actually
run
the
full
shackle
processor
at
runtime.
D
So
you
use
the
shackle
framework
you've
added
some.
Some
relates
to
new
relation
types
to
shackle.
Maybe
to
to
you
know
that,
in
terms
of
what
you
just
described
as
an
extension
and
then
you
sort
of
cache
the
processing
but
you're,
still
sort
of
using
a
shackle
sort
of
constraint
framework
on
the
on
the
language,
it'll.
C
D
Interesting
to
see
how
you
know
when
you,
when
you
get
around
to
publishing
that
how
what
that
looks
like,
because
that
seems
a
common
approach
now.
I
know
they're
using
that
in
ash
right
now,
like
joe
bender's,
using
all
that
stuff
shackle,
they
use
rdfs
for
some
constraints
also,
and
they
have
two
or
three
owl
keywords
in
there
just
just
for
good
measure.
But
right.
You.
C
D
B
Yeah,
we
were
actually
really
liked
shackle.
It
was
just
the
performance
and
really
in
particular,
around
the
sparkle
parts.
So
he
had
originally
written.
Some
of
our
constraints
couldn't
be
expressed.
You
know
directly
with
shackle.
You
know
with
the
with
this
built-in
shackle
constraints,
but
they've
got
the
sparkle
mechanism
for
expressing
really
kind
of
anything,
and
so
we
had
used
that
pretty
heavily
in
our
first
iteration
and
that
just
didn't
it
just
didn't
mean
our
performance
needed.
So
we
had
to
so.
B
We
took
some
of
those
those
things
we
had
expressed
with
sparkle
and
said:
hey,
let's
just
you
know,
define
these
sort
of
as
extensions
if
you
will
and
and
then
do
this
sort
of
pre
pre-built
constraint,
checker
based
on
those
but
yeah
but
yeah-
I
think
you
know.
Hopefully
we
can
get
get
our
meta
model
to
be
public,
not
not
too
long,
and
I
think
when
you
see
it,
it
won't
look
unfamiliar,
there's,
there's
a
bunch
of
shackle
stuff
in
there.
A
Okay,
very
good,
and
maybe
one
quick
comment
I
could
make
here
on
the
converge
model
so
that
we
are
using
here
an
extension
that
is
not
part
of
the
sdf
spec.
Yet
so
the
sdf
relation,
that's
something
that
we
are
still
experimenting
with
and
but
since
given
it
was
used
by
that
kind
of
mechanism
was
used
by
ddl
models,
already
we're
using
it
here
on
the
conversion.
So
that
is
a
good
chance.
It
will
change
how
it
exactly
looks.
A
D
D
This
is
our
sort
of
rdf
hook
to
sort
of
go
to
the
broader
you
know
sort
of
directly
since
we're
not
really
json
ld
and
you
can't
just
plug
in
sort
of
that
type
and
stuff.
This
is
that
way,
we're
planning
on
doing
it.
So
it's
it's
meant
to
look
like
an.
I
think,
like
an
rdf
link
more
or
less,
but
also
a
sort
of
general
purpose.
So
we
could
do
a
lot
of
stuff
with
it.
A
Okay,
great
thanks
peter
and
maybe
one
question
about
this
transformed
model,
so
we
think
it
might
be
useful
that
people
can
see
these
ddr
models
translated
into
sdf,
I'm
just
wondering
before
we
dump
them
somewhere,
for
example,
in
a
github.
Do
you
brian
know?
If
there's
any
concerns
on
that
I
mean,
if
I
remember,
the
license
was
mit,
so
that
seems
to
be
quite
quite
relaxed
on
the
on
the
legal
side.
But
is
there
any
any
other
things
to
consider
for
before?
We
would
publish
these
sdf
versions
of
the
ddl
models.
B
I
I
guess
I
don't
have
any
particular
concerns,
but
you
know
let
me
circle
around.
We've
got
a
team
that
works
with
our
ontologies
in
more
detail.
Let
me
just
like
you're
saying
the
license
doesn't
may
not
say
anything
there.
I
I
can
circle
around
with
them
just
to
see,
if
there's
anything
that
you
know
they'd
be
that
they
would
have
to
say,
or
maybe
even
that
we'd
want
to.
You
know,
set
up
crosslinks
or
something.
D
E
D
What
is
that?
I
don't
stop
me
if
I'm
interfering
with
the
agenda,
but
what's
that
scope
of
what
we're
going
to
publish
on
sdf
in
terms
of
like
definitions
from
dtdl?
Is
it
that's
a
basic
sort
of
system,
ontology
stuff
or
does
it
include
the
application
stuff
like
smart
city
and
power
grid,
and
all
of
that
also
abroad?
Is
that
what
we're?
What.
A
D
A
Yeah
yeah
that's
kind
of
as
the
first,
but
then,
of
course,
on
the
longer
term.
Now
I'm
thinking
about
that
the
one
dm
side
of
things.
Of
course
it
would
be
very,
very
interesting
to
have
where
we
want
them.
You
know
the
idea
is
to
to
collect
these
models
and
then
look
at
how
we
can
you
know,
learn
from
the
best
best
of
the
models.
So
for
that
purpose,
of
course,
it
would
be
great
to
have
you
know
as
as
good
set
of
models
as
possible
on
in
in
sdf.
A
A
But,
of
course
I
mean
like,
if
you
think
brian,
like
that
the
ddo
folks
don't
have
anything
against
that.
I
think,
would
be
very
good
that
you
know
the
bigger
bigger
set
of
models.
We
have
a
model
in
the
same
language,
the
bigger
better
chances
we
have
on
things
to
make
things
operate
across
the
ecosystem,
so
I
think
it
would
be
very
beneficial
for,
for
all
of
us.
D
D
Sense,
we've
been
sort
of
well
sorry,
but
really
the
the
impetus
behind
it
is
we've
been
looking
at
sort
of
what
we
have
in
sdf
and
sorry
in
one
dm
and
say
well.
This
is
mostly
just
you
know
for
device
affordances
like
how
do
I
control
devices,
but
really,
you
know,
there's
a
whole
broader
set
of
concepts
and
things
like
that
that
could
also
be
represented
in
the
same
model.
This
is
the
stuff
we
have
here,
which
is
very
close
to
devices,
but
not
not
just
what
is
already
being
published.
D
That
is
there
any
kind
of,
I
guess,
that's
sort
of
what
we
have
in
terms
of
copyrights
and
stuff,
but
you
know
linking
back
in
terms
of
being
able
to
say
sdf
relation
this
thing
lines
up
with
the
thing:
that's
in
this
other
name,
space
is
another
really.
What
I
was
thinking
about,
though,
like
when
I'm
processing
the
model
I
get
to
find
out,
I
can
link
straight
back
to
a
dtl,
namespace
and
and
find
out
more
about
this
thing.
D
So,
like
sdf
might
be
an
entry
point,
but
we
don't
want
it
to
just
stop
there.
We
wanted
to
to
fully
link
back
to
the
where,
where
the
things
came
from,
and
in
this
case
I
think
there
might
be
some
times
when
we
just
sort
of
purify
a
a
description.
You
know
a
definition
of
something
and
and
say
here's.
This
is
just
sort
of
a
1dm
definition,
but
we
still
want
the
provenance
of
that.
A
Yeah,
at
least
how
I've
been
thinking
about
this
in
my
head.
Is
that
like,
when
you
see
a
of
course,
the
ddr
models,
they
would
have
the
ddl
namespace
in
them,
which
should
be
then
a
sufficient
indication
on
that
where,
where
this
comes
from,
and
you
can
expect
that
those
models
would
be
just
as
such,
converted
ddl
on
on
any
sr
system.
A
But
then,
of
course,
when
it
gets
more
interesting,
is
that
you
have,
for
example,
an
ipso
model
or
or
if
someone
else
together
with
digital
models,
and
you
build
your
thing
out
of
them
and
then
be
able
to
link
across
them
and
converting.
You
know
your
ipso
definition
via
sdf
into
dddl
and
bringing
it,
for
example,
to
the
azure
digital
twin,
explorer
and
building
your
your
system.
On
top
of
that,
that's
roughly
what
I
have
the
model
in
my
my
head,
at
least
that
I
haven't.
We
haven't
experimented
with
that
too
much
yet.
D
Really
looking
at
kind
of
two
two
main
ways
of
using
sdf
one
is
like
what
what
I
would
say
is
earlier
like
purified
models,
that
sort
of
like
they're,
like
a
1dm
thing,
would
say:
here's
a
one-size-fits-all
model
for
some
general
concept
that
everybody
uses
and
it
contains
elements
of
sort
of
the
best
best
elements
of
other
models.
But
another
way
to
do
it
is
just
sort
of
convert
it.
D
So
I
have
a
common
entry
point
for
a
bunch
of
different
backend
languages
and
systems,
like
you
know,
dtdl
and
opc
ua,
and
you
know
bacnet
and
modbus,
and
that
also-
and
as
an
entry
point
I
can
think
about
composing
systems.
I
can
browse,
I
can
whatever
and
then
you
know
just
link
back
my
ins.
My
intention
is
ultimately
to
maybe
build
a
web
service
layer
on
top
of
these
things,
and
so
I
want
a
common
entry
point
for
all
of
them.
A
C
A
That
would
have
two
kinds
of
information,
at
least
the
ecosystem,
specific
information,
so,
for
example,
in
ipso
ecosystem.
Each
model
has
a
numeric
id,
because
this
is
rather,
if,
if
so,
it
was
a
specific
thing,
you
wouldn't
necessarily
see
those
in
the
generic
spf
models,
but
you
would
add
those
to
the
in
a
refinement
set
and
then
there's
the
other
set
of
specific
information,
not
not
so
much
on
specific
ecosystem,
but
actually
on
that
specific
instance.
For
example,
what
is
the
ip
address
of
that
device?
B
Yeah
this
is
a
this
is
a
good
area
for
discussion
and-
and
I
think
you
know,
improvement
on
our
side.
So
we
have.
You
know
this
identify.
Of
course,
the
similar
you
know
problem
that
needs
to
be
solved
where
you
need
to
be
able
to
map
from
you
know
these
device
instances
or
digital
twin
instances,
and
that
you
don't
want
to
carry
that
information
in
the
generic
model,
and
so
we
we've
on
our
side
called
those
bindings
but
mappings
similar
similar
thing.
B
D
So
a
couple
of
things
I
mean
you
could
you
could
immediately
employ
something
like
open,
api
or
better,
yet
thing
description
to
just
describe
what
you
have
the
profile.
I
would
call
what
you
defined
as
a
profile
and
it's
sort
of
like
it's
you.
There
could
be
other.
You
know
profile,
but
yeah.
It's
a
protocol
binding
is
what
they
call
it
and
one
of
those
things
but
yeah.
D
Then
you
know
down
the
road,
a
more
general
thing
that
says:
well,
here's
how
we
map
our
thing,
our
schemas
to
other
protocols,
I'm
assuming
bacnet
and
modbus
and
and
lawn
works-
are
going
to
be
sort
of
like
for
a
lot
of
the
people
using
digital
twins
and
buildings
and
then
for
cities.
There's
you
know.
So
it's
going
to
be
probably
a
good
half
a
dozen
or
a
dozen,
even
different,
different
things.
You're
going
to
want
to
map
to
like
somebody's
laura
kind
of
you.
C
D
Lpwan
protocol
endpoints,
and
things
like
that,
so
it
would
be.
It
would
be
interesting
to
go
through
an
exercise
where
you
could
you
know
even
so
thing
descriptions
are
just
instances.
You
would
just
crank
them
out
when
you,
when
you
make
things
and
and
what
we're
talking
about,
is
more
like
how
you
map
them
to.
But
it
would
just
be
interesting
to
see
what
some
of
these
look
like
if
you
have
had
a
way
of
describing
them
in
swagger
or
our
thing
description.
B
B
B
Typically,
what
we
see
there
is
a
lot
of
services,
you
know
using
you
know,
being
rest
based
or
using
http
or
whatever,
and
so
we've
got
actually
a
mapping
there
that
is
described
with
swagger.
So
I
yeah
I
actually
published
a
swagger
on
that.
So
I
could
you
know:
we've
got
a
swagger
that
defines
that
side
of
the
service
space
inside
of
oh.
D
D
In
other
words,
you
could
really
map
them
back
and
forth
if
you
had
both
sort
of
some
some
rdf
that
pointed
to
things
in
the
swiger
file,
but
the
thing
that
thing
description
allows
you
to
do
is
put
a
type
annotation
right
in
the
file,
so
some
of
my
examples
were
complex,
schemas
that
had
annotations
of
which
sub
property
using
that
type.
That
pointed
back
to
sdf
models
that
that
said,
here's
the
red,
here's,
the
green,
here's,
the
blue,
that.
D
D
Really,
that's
that's
sort
of
I'd
encourage
you
to
look
at
thing
description
because
it
has
some
features
that
would
be
used
to
pull
in
both
those
directions.
For
you
and
there's
already.
The
bacnet
and
bacnet
findings
are
not
that
hard.
It's
the
uri
basically,
but
you
know
there's
already
bacnet
and
modbus
bindings
and
and
there's
already
some
examples
of
how
services
are
being
exposed
upward
using
thing
description
because
it
still
has
the
sort
of
no.
I
don't
know
your
interaction
style.
D
There's
like
this
idea
of
actions
and
events
and
and
things
you
might
or
might
not
use
they're
useful
in
other
systems
like
opc
ua,
where
they
have
concepts
that
align
with
those,
but
even
if
you're,
just
using
it
for
an
object
property
model.
It
still
has
all
those
protocol
bindings
and
you
can
say
I'm
using
http.
D
Alternatively,
here's
an
mqtt
endpoint
that
you
can
go
to
you
can
pretty
much
do
all
that
in
thing
description,
and
so
I
I
guess,
I'd
recommend
like
looking
at
that.
That
would
be
a
a
possible
common
interaction
point
and
also
you
know
eventually
going
to
be
well.
It's
already
a
an
actual
w3c
recommendation,
but
it's
still
on
a
you
know:
1.0
to
2.0
kind
of
development
stage
right.
B
D
D
A
E
A
That
that's
a
that's
a
very
good
question.
I
think
what
we
we
have
now
like
like,
for
example,
the
set
of
dddl
models.
I
I
know
I
can
at
least
give
them
to
us
our
tools
and
that
they
show
up
there
so
that
that
far
we
are
definitely
but
I
haven't.
We
haven't
yet
tried
to
actually
do
anything
with
them.
A
A
B
B
E
B
E
So
we
need
to
do
some
work
on
the
model
level,
but
we
also
need
to
do
some
work
on
the
instance
levels
right
at
the
end.
We
need
to
have
that
actual
ipso
thing
and
and
the
the
digital
twin
over
there
in
asia
land
and
all
that.
So
there
is
probably
some
some
configuration
and
setup
work.
We
have
to
get
out
of
the
way,
so
we
can
actually
do
the
the
part
that
we
are
more
interested
in,
which
is
the
the
modeling
work.
B
D
D
E
A
Okay,
good
sounds
like
we
have
a
good
good
way
forward
here
and
now.
Look
at
the
clock.
I
wouldn't
realize
we're
already
running
over
time,
but
thank
you
everyone.
This
is
very,
very
good
discussions
and
I
think
we
have
a
good
good
progress
here
on
on
on
the
interwork
aspects
and
and
yeah
and
brian.
If
you
can
come
back
to
the
about
the
publicity
models
topic,
then
we
could,
you
know,
put
those
models
somewhere.
Everyone
else
can
also
have
a
closer
look.