►
From YouTube: CORE WG Interim Meeting 2021-05-26
Description
CORE WG Interim Meeting 2021-05-26
A
Okay,
we
are
recording
now
and
welcome
everybody
to
this
virtual
interim
meeting
of
the
co-working
group.
I'm
marco
tiloca,
my
co-chair
is
simon
ximenez
and
as
a
reminder,
this
is
an
officiality
of
meeting
which
we
are
recording.
The
not
well
applies
be
sure
to
be
familiar
with
it.
It's
not
just
about
ipr,
but
also
about
code
of
conduct,
so
be
nice
with
each
other,
and
the
agenda
for
today
is
about
the
choral
document,
where
activities
have
resumed
heavily
in
the
last
months.
A
A
B
Thank
you
so,
of
course,
in
the
core
working
group.
We
have
two
documents
right
now
related
to
coral,
and
one
is
of
course
the
coral
specification
itself,
but
then
we
also
have
the
href
draft,
which
specifies
how
you
can
encode
your
eyes
efficiently
in
a
compact,
binary
format,
and
before
we
come
to
the
core
roadmap.
I
would
quickly
like
to
report
on
the
href
draft.
B
The
issues
are
actually
just
just
one
major
item
left
and,
and
that
is
based
on
some
discussions
with
jim.
We,
we
tried
to
come
up
with
a
more
compact
theorization
and
that
has
now
been
as
put
as
a
proposal
in
the
new
dash
04
revision
that
has
been
published
a
couple
of
days
ago
and
now
now
what
we
want
to
do
is
to
double
check
that
that
is
really
what
we
want
to
use
in
the
end.
So
the
compact
is
very
compact.
Now
the
format
is
very
compact.
B
It's
near
perfect
to
what
can
be
achieved,
and
the
debate
is
more
on
this
side
of
is.
Is
it
as
easy
to
implement
as
we
want
it
to
be,
and
so
that
that's
the
main
issue
there?
Of
course,
what
would
help
here?
A
lot
would
be
if
we
have
additional
implementers
who
would
take
a
step
and
and
try
to
get
it
running
without
looking
at
the
reference
code,
so
based
purely
on
on
the
graph
text.
B
If
we
end
up
with
something
interoperable-
and
I
also
if,
if
it's
easy
enough
to
implement
or
not-
and
I
think
the
the
other
for
open
issues
in
the
github
repository
that
then
can
be
very
easily
fixed
so
that
we
could
probably
go
into
a
working
group
last
call
pretty
soonish.
So
it's
not
far
away
and
what
you
also
might
want
to
do
is
since
this
is
now
a
third
alternative.
C
B
B
The
the
problem
is
that
us
three
are
spoiled
we.
We
have
been
discussing
so
much
that
in
our
heads
we
have
a
good
picture
of
what
it
should
be,
and
the
question
is
is
what
is
in
the
draft
now
also
good
enough,
so
that
people
who
don't
have
all
this
knowledge
back
in
their
heads
that
they
can
implement
it.
D
Think
it's
really
important
to
have
a
nice
set
of
examples
so
that
I
did
find
my
implementation
again.
It's
not
complete,
so
I
still
have
to
complete
it,
and
I
have
to
to
run
a
few
hundred
examples
through
it
to
to
understand
what
it
actually
is
doing
and
I'm
starting
to
collect
the
examples.
I
think
you
sent
some
around
five
days
ago,
but
I
think
we
we
need
to
have
more
examples
than
that.
B
So,
in
the
end,
the
goal
from
my
side
would
be
that
we
not
only
have
the
draft
but
also
a
companion
repository
with
test
vectors
and
reference
implementation
and
so
on.
So
in
the
end,
implementers
won't
have
to
implement
purely
based
on
the
draft
from
scratch.
They
can
use
our
test
vectors
and
what
I
have
sent
you
a
couple
of
days
ago
is
basically
the
first
100
or
so
lines
output
of
of
my
test
vectors-
and
I
I
think
it's
it's
near
impossible
to
to
implement
this
right
with
our
test
vectors.
D
B
And
the
the
fundamental
problem
is
that
your
eyes
are
not
specified
in
an
intuitive
model.
It's
specified
by
algorithms,
in
the
in
the
rfc
and
whatever
we
do.
We
basically
have
to
find
algorithms
that
are
the
same
or
do
the
same
thing
as
those
algorithms
and
then
you
have
to
look
at
them.
Examples
to
make
sure
that
you've
got
it
right,
but
wait.
You
can't
verify
it
by
reading
the.
B
B
On
top
of
that,
we
have
a
bunch
of
areas
where
we
started
using
coral
and
also
we
have
along
the
way,
found
additional
ways
how
how
coral
could
be
used
and
what
would
be
needed
for
that,
and
so
one.
The
thing
that
might
be
good
to
do
is
not
to
rush
the
coral
draft
now
to
completion
and
then
start
using
it
everywhere,
but
do
a
bit
of
co-development
here
so
move
coral.
B
A
few
steps
forward
then
adopt
those
changes
and
and
the
other
places
and
and
then
we
get
some
additional
insights
and
can
then
go
back
to
coral
and
make
the
changes
needed,
and
so
there's
there's
some
nice
feedback
loop.
That
has
already
been
started,
so
we
have
now
these
design
team
meetings
for
a
while
and
also
last
year
behind
the
scenes.
B
B
I
have
created
this
hackendy
coral
roadmap,
where
I
just
tried
to
group
the
github
issues
a
bit
and
also
put
a
list
on
on
what
else
we
have
planned
or
what
what
should
be
part
of
of
the
choral
ecosystem
in
the
end-
and
I
would
now
just
go-
I
don't
have
any
slides.
I
would
go
through
the
second
d
and
explain
a
bit
what
each
of
these
areas
entail.
B
Then
the
next
area
is
called
names
in
negotiation.
So
our
what?
What
is
the
serious
term
for
running
geg?
Our
long-standing
mission
in
the
co-working
group
has
been,
and
is
allocating
small
compact
identifiers
to
semantic
elements
and
in
the
case
of
coral,
that
is
the
compact
identifiers
for
link
relation
types.
B
You
know
also
for
things
like
resource
types
and
and
similar,
and
the
problem
shows
up
basically
everywhere.
So
in
comai
we
have
a
solution
for
that
and,
of
course,
co-op
has
the
the
number
registries
for
methods
and
content
formats
and
so
on.
So
it's
just
the
same
topic
in
a
new
area,
and
in
this
case
the
area
is
coral.
B
So
we
have
been
discussing
a
bit
how
we
could
achieve
these
two
very
conflicting
requirements.
On
the
one
hand,
we
need
a
human
readable
identifiers
with
a
very
low
barrier
to
entry
for
for
the
specification
authors
which
might
not
be
itfs
and
on
the
wire
we
really
want
to
have
the
compact
identifiers.
B
So
we
we
can
keep
our
representations
very
small
and
there
is
now
a
bunch
of
issues
related
to
that.
So,
of
course,
if
you,
you
can
do
a
very
static
assignment
like
an
inner
registry
that
would
not
have
a
great
barrier
to
entry
that
would
not
have
a
great
low
barrier
to
entry.
So
it
would
be
probably
not
a
good
idea
to
do
that.
B
But
then,
if
you
do
something
more
dynamic,
where
the
participants
on
the
conversation
exchange
or
negotiate
some
compact
identifiers,
then
the
question
is:
how
do
they
do
that
and
on
both
of
these
questions
like
how?
How
do
we
even
do
the
assignment
and
then
how
could
we
potentially
assign
and
negotiate
the
assigned
values?
B
These
then,
the
next
area
is
called
queries
and
patches.
So
like
we
have
in
cnml
of
sentinel
fetch
patch.
We
probably
also
want
to
be
able
to
query
just
this
a
subset
of
a
chord
document.
So,
for
example,
you
can
imagine
that
we
have
a
collection
resource,
and
that
has
many
many
many
items
and
then
we
use
coral
to
represent
this
collection
resource.
Then
we
might
want
to
use
a
fetch
request
to
just
return
a
subset
of
these
items
in
the
core
document
and
in
in
well
known
core
and
resource
directories.
B
So
you
you
could
use
custom
vocabulary
for
any
kind
of
application
and
still
have
very
compact
queries
if
we
use
the
same
identifier
assignment
scheme-
and
here
we
have
interesting
questions
like
do.
We
basically
just
submit
some
some
kind
of
pattern
with
holes
and
then
everything
that
has
that
that
fits
into
this
pattern
is
returned,
or
do
we
actually
just
return
the
values
that
fit
these
holes?
So
there's
some
similarities
to
sparkle
here,
but
of
course
we
we
don't
want
to
completely
clone
all
the
expressiveness
of
sparkle.
B
We
probably
also
want
to
be
able
to
patch
a
resource
by
by
submitting
a
diff
or
a
patch
instead
of
replacing
the
whole
thing,
and
that
would
probably
simply
be
a
combination
of
a
query.
So
you
you
send
a
select
query
for
to
select
some
things
and
then
you
also
put
a
replacement,
and
so
the
query
then
selects
some
some
subset
and
replaces
as
it
with
the
replacement
which
could
be
no
for
for
deletion
or
something
like
that.
B
B
B
So
we
discovered
that
when
we
write
our
drafts
that
make
use
of
coral,
we
want
to
be
able
to
to
specify
the
expected
shape
of
a
coral
document
so,
for
example,
and
the
core
pops
up
broker.
When
you
have
your
list
of
topics,
you
want
to
be
able
to
to
write
a
specification
that
says
a
topic
has
these
elements,
and
these
here
are
optional
and
those
can
be
zero
and
more,
and
that
needs
to
be
exactly
once
and
and
so
on.
B
So
if
we
have
a
query
like
give
me
everything
that
matches
this
pattern
and-
and
we
have
a
way
to
describe
the
pattern,
then
we
could
simply
use
the
same
thing
in
our
documentation
and
say
here
here
is
the
expected
shape
for
for
the
quarry
document.
This
is
the
pattern
that
the
core
document
needs
to
match
in
its
entirety,
and
validation
would
then
simply
be
running
the
the
query
by
by
inputting
the
query
document
and
the
the
query
and,
and
then
you
get
if
it
matches
on
it.
B
The
most
common
one
is
probably
the
typical
shape
of
a
collection
resource,
so
a
list
of
items
are
sub-resources
and
a
way
to
add,
update,
remove
items
from
from
this
list,
and
so
there's
some
discussions
has
happened
some
some
time
ago,
where
we
started
documenting
as
a
first
reusable
shape.
This
collection
resource
pattern
and
then
something
else
that
also
showed
up
already
in
a
couple
of
places
is
a
configuration
resource
so
in
core
pub
sub
broker
and
but
also
in
the
a's
group
manager.
B
You
simply
want
to
essentially
set
a
bunch
of
key
value
pairs.
They
describe
the
configuration
of
a
group
or
a
topic,
and
so
you
have
a
resource
that
can
be
configured
and
we
could
simply
use
coral
to
express
the
configuration
and
also
facilitate
the
the
updating
of
and
deletion
of
this
configuration.
B
And
then
you
can
already
see
if
you
combine
the
two,
you
can
have
a
collection
of
configurations,
and
this
is
essentially
what
what
the
pub
sub
broker
is.
It's
a
collection
of
topic
configurations,
and
so
the
the
hope
that
we
have
here
in
this
area
is
that
if
we
just
specify
a
bunch
of
these
reusable
shapes
or
components,
we
could
slim
down
the
actual
application
specifications
like
puffs
of
broker
to
just
a
few
pages,
because
all
we
have
to
do
now
is
is
to
specify
please
use
the
collection
resource
pattern
from
that.
B
Hard
disk
a
draft
called
core
coral
shapes
which
proposes
yeah
a
a
notation
and
format
for
expressing
these
shapes
that
that
can
also
be
used.
Then,
as
the
query
format,
and
we
also
had
a
discussion
a
while
ago
and
again,
this
is
a
private
github
repository
where
we
started
documenting
these
reusable
patterns
or
shapes.
B
On
top
of
that,
there
are
two
implementations
and
one
is.
I
called
it
coral
tool,
that
is
this
validation
thing
that
we
couldn't
have
so
it's
a
simple
typescript
program
that
inputs
a
choral
document
and
a
shape
document
and
and
then
tells
you
if
it
matches
or
not,
and
the
other
thing
is
called
core
apps
tool
and
that
inputs
a
markdown
document,
and
then
it
extracts
all
the
choral
examples
and
correlative
shape
definitions
from
the
document
and
renders
the
whole
thing
nicely
in
html
and
I
haven't
implemented
it
yet.
B
B
Then
server
a
is
not
really
authoritative
for
the
resources
on
server
b
can
can
we
still
use
the
information
about
the
resources
on
server
b
if
it
comes
from
server
a
and
and
the
answer
to
this
is
most
likely.
It
depends
it's
it's
application
specific,
but
thinking
about
more
about
these
trust
issues,
I
I
think
would
be
very,
very
interesting
to
do
in.
B
In
the
end,
it's
probably
very
related
to
authorization
questions
is:
is
the
server
authorized
to
to
make
these
statements
and
and
imi,
as
a
recipient
of
a
correct
document,
authorized
to
to
make
use
of
the
information
that
I
find
in
the
document
and
then
on?
We
also
have
related
questions
like
if,
if
we
have
a
corey
document-
and
that
contains
a
bunch
of
statements,
can
we
relay
those
statements
through
a
third
party
like
a
resource
directory,
for
example,
and
keep
this
trustworthiness
of
of
the
statements
that
are
being
made.
B
So
if
a
server
uploads
its
list
of
resources
to
a
resource
directory,
then
of
course
the
resource
directory
can
knows
where
it
comes
from
and
can
check
if
it's
trustworthy
or
not.
But
if
then
the
resource
directory
hands
out
the
statements
to
us,
how
can
we,
since
it
doesn't
come
from
the
original
source,
but
from
from
a
third
party
can
can
we
still
do
our
same
checks
on
untrustworthiness
of
these
statements
or
not,
and
there
have
been
a
few
ideas
floating
around
on
this
one?
B
B
B
B
I
find
this
area
very
interesting,
but
not
much
work
has
happened
here
yet,
and
there
are
three
issues
open
in
the
github
repository
and
I
have
drafted
some
early
sketch
of
this
cozy
signed
corey
document.
It's
really
take
a
choral
document
and
slap
cozy
sign
on
top
of
that
and
and
you're
done
so
it's
just
the
one
page
at
this
moment
yeah.
C
C
B
C
Yeah
exactly
so,
I
see
this
as
the
you
know,
the
server
that
talks
to
drd
and
delegates,
part
of
its
resource,
322,
drd
and
so
drd
becomes
authoritative
by
means
of
this
implicit
or
explicit
delegation
done
by
the
server.
So
it's
not!
It's
not
like
you
know,
building
a
real
transitive
thing
here,
you're
having
two
sort
of
end
to
end
that
compose.
C
B
B
E
E
The
the
thing
is
also
the
the
rd
if,
if
an
rd
is,
is
fully
trusted
with
the
statements,
which
is
one
deployment
scenario.
But
if
it's,
if
there
are
many
parties
that
it
has
the
truck
that,
if
there
are
many
parts
that
it
is
authorized
to
speak
on
on
their
rehab,
that
becomes
a
very,
very
attractive
attack.
C
C
E
C
Exactly
what
I
was
trying
to
formulate
so
the
endpoint
publishes,
part
of
it
resource
3
to
drd
trd,
presents
that
subtree
and
you
know
the
composition
of
all
the
endpoints
sub
trees
to
the
rest
of
the
world.
So
a
consumer
of
the
rte
is
effectively
trusting
the
rd
to
be
an
origin
for
these
guys,
because
there's
there
has
been
a
transfer
of
authority.
E
In
in
many
cases
that
that
should
not
be
necessary,
so
much
information
that
we
publish
on
the
on
the
rd
is
more
hint
level.
So
if,
if,
for
example,
you
discover
that
there
is
a
light
bulb
there
and
it
speaks
these
in
those
content
formats,
and
then
you
interact
with
that.
Based
on
that
information
and
turns
out,
there
is
no
light
bulb
there.
Then
all
the
there
is
no.
C
C
E
There's
a
there's
a
problem
right,
so
the
the
rd
could
still
withhold
information,
but
it
cannot
insert
false
statements
and
might
even
and
there
can,
if,
if
you
think
it
it
to
the
extreme
like
it
is
then
with
dns,
you
might
even
manage
to
to
certify
the
absence
of
particular
statements
there.
I
didn't.
I
don't
think
we
went
that
far
yet
with
with
the
issues
eight
and
ten,
but
it's
it's
certainly
possible.
C
C
Right
so
going
back
we're
just
stepping
back
a
bit
on
on
the
still
the
the
bullet
point
too.
I
had
understood
that
that
thing
a
bit
slightly
differently
in
the
sense
that
I
was
thinking
that
the
the
idea
was
to
embed
into
the
document,
some
sort
of
security
configuration
hints
to
retrieve
embedded
resources
right,
so
so
resources
that
were
not
directly
hosted
at
the
origin
that
served
the
reservoir
the
the
resource,
but
at
some
some
other
endpoint
in
the
network.
C
B
B
B
So
I
try
to
preempt
that
by
defining
a
format
and
text
that
has
clear,
syntax
and
semantics
and
it
can
be
used,
but
the
the
implementers
are
not
really
expected
to
implement
that.
So
what
once
there
is
a
single
implementation
that
can
do
the
parsing
and
translating
that
in
past
information
into
the
c-ball
format,
there
there's
no
need
to
ever
implement
the
whole
thing
again
and
since
this
is
aimed
at
humans
to
to
read
and
write
and
not
at
machines,
it's
also
quite
annoying
to
implement.
B
B
Then
we
have,
of
course,
also
our
good
old
rfc6690
link
format
which
has
known
be
around
for
I.
I
think
it
was
our
first
rfc
right,
the
first
one
we
published
many
years
ago
and
it's
a
certain
use
in
many
places,
and
we
might
want
to
continue
the
discussion
that
happened
some
time
ago
on
how
to
convert
to
and
from
coral
for,
for
the
link
format.
And
I
think
we
have
a
really
good
proposal
there,
that
we
should
write
down
and
and
take
a
look
at
and
and
move
that
forward.
B
Yeah,
that
was
the
roadmap
I
also
have
in
in
the
second,
the
the
list
of
known
applications.
I
know
four.
Maybe
there
are
more
by
now.
I
don't
know-
and
I
forgot
to
mention
that
my
core
apps
tool-
also
it
comes
with
an
example-
and
that
is
the
the
collection
pattern,
so
there
it
generates
some
nice
rendered
output
of
of
the
documentation
of
that
which
I
can
show
at
some
point
right
right
now.
It's
somewhere
buried
on
my
hard
disk.
A
B
B
While
we
are
looking
for
for
the
most
interesting
issues,
I
could
maybe
say
a
few
words
on
how
I
think
could
be
possible
next
steps,
and
that
is,
as
I
said,
I
think
it
makes
sense
to
to
do
a
bit
of
code
development
here
with
the
applications
and
also
with
these
different
areas.
So
advancing
each
of
these
areas
a
bit
further
before
we
put
the
seal
on
the
the
coil
base
specification,
we
have
now
proposals
for
for
at
least
starting
points
for
proposals.
B
D
What
this
hand
over
actually
means
and
it's
it
is
often
important
to
capture
that
intent
and
that
intent
in
in
many
cases
actually
needs
to
be
protected
with
some.
Some
information
about
the
provenance
of
that
intent
and
a
related
question,
of
course,
is
whether
the
ui
actually
has
all
the
the
security
related
information
in
it.
That
is
needed
to
actually
properly
execute
on
on
that
intent.
D
So
I
think
that
that's
an
important
part
of
of
the
provenance
picture
we
in
the
http
world,
we
we
kind
of
ignore
the
problem,
and
whenever
we
have
a
uri
we
we
just
believe
that
everything
around
this
uri
will
be
secure.
But
of
course,
whatever
secure
means
here,
and
it's
also
not
always
clear
what
the
uri
means.
D
D
So
there
was
a
ui
in
in
that
message
and
the
the
it
was
clearly
qualified
as
a
ui
that
you,
you
better,
don't
click
on,
because
it's
going
to
compromise
the
system
and
for
some
reason,
the
administrator
forwarded
this
message
to
another
administrator.
Without
that
information
and,
of
course
the
other
administrator
thought,
oh
something
important
from
my
co-administrator
I'd,
rather
click
this
now
to
find
out
what
he's
talking
about.
D
So
that's
that's
a
real
world
human
world
example
of
why
it's
not
not
sufficient
to
just
throw
a
ui
to
someone,
but
you
really
need
to
to
provide
the
intent
that
you
you
have
in
mind
when,
when
throwing
over
the
the
ui
to
a
different
application
and
in
in
the
http
world,
we
have
link
relationships
to
to
capture
some
of
that
intent.
But
we
probably
have
to
think
a
little
bit
more
about
what
autonomous
autonomously
acting
acting
constraint.
Devices
actually
can
process
in
in
the
form
of.
D
D
C
C
E
C
A
F
G
That's
quite
interesting,
michael
coster.
Here
I
I
sent
klaus
an
email
about
a
week
ago,
saying
hey!
Why
couldn't
we
use
the
link,
the
the
semantic
link,
expressivity
in
coral
and
its
ability
to
template
to
create
a
direct
binding
so
that
you
could
use
basically
any
sdf
definition
and
and
sort
of
in
the
way
that
claus
described
earlier
using
some
standard
shapes,
convert
that
into
a
coral
document
and
and
basically
have
a
deterministic
conversion?
G
And
basically
that
would
allow
you
to
semantically
interpret
a
choral
document
using
the
sdf
semantic
names
that
that
we
define
for
affordances.
Essentially,
the
idea
would
be
to
use
link
relays
to
define
some
or
assign
some
link
relations
such
that
you
could
make
the
sdf
semantic
name
a
target
attribute,
and
then
you
could
basically
use
those
target
attributes
to
do
the
fetches
and
and
loads
and
and
with
sdf.
G
We
have
the
way
to
use
sort
of
deterministic
bindings
like
properties
that
get
put
observe
events
or
are
more
like
the
pub
sub
protocol
using
observe
and
actions
are
posed
with
a
return
payload.
So
we
could
define
all
of
those
things
and
basically
have
a
really
clean.
Interesting
way
to
build
a
self-describing
semantic,
semantically,
consumable
api,
and
that
was
that
was
sort
of
my
intro
to
things
and
klaus
said
that
sounds
interesting,
and
so
maybe
he's
had
some
more
thoughts
since.
G
D
That
has
certain
components
so
members
in
in
jsonparlians
and
and
these
are
shaped
in
a
specific
way
and
so
on.
But
this
is
of
course,
very
low
level
and
it
may
be
necessary
to
actually
describe
a
resource
that
that
provides
coral,
structured
information
using
a
higher
level
information
model,
so
sdf
would
have
to
be
extended.
D
G
I
you
know,
I
agree.
I
think
the
missing
piece
is
sort
of
the
the
additional
constraints
that
you
need,
but
I
also
think
that
sdf
may
already
have
the
if
we
just
make
sure
that
the
source
files
in
sdf
contain
the
data
constraints,
and
we
may
actually
need
to
say
well,
here's
what
a
payload
looks
like,
but
I
think
the
common
collection
shape
might
do
that
in
a
lot
of
cases.
So
I
think
it's
worth
sort
of
looking
at
how
those
converge
on
that
on
that
gap
that
you
just.
B
B
The
question
for
for
me
first
is
of
course,
then
what
what
is
the
place
where,
where
we
do
the
the
sdf
interactions
you
using
call
so
before
we
can
have
injections,
we
probably
first
need
to
have
instances
of
these
classes.
So
I
want
to
say
I
have
two
temperature
sensors
in
this
room
and
there's
also
another
room
adjacent
to
to
that,
and
that
also
has
has
a
temperature
sensor,
and
then
I
might
be
interested
in
the
room
temperature,
which
is
some
aggregated
value
between
these
different
temperature
sensors.
B
B
They
are,
of
course
described
in
sdf,
but
but
the
injection
I
I
assume
is,
is
then
ecosystem
specific
and
then
maybe
what
we
are
looking
at
is
some
kind
of
cloud-based
api.
Also
for
for
my
whole
house.
So,
no
matter
where
I
buy
my
sensors,
I
would
have
some
kind
of
box
in
my
house
or
in
the
cloud
that
I
can
talk
to
and
that
has
some
uniform
ecosystem
independent
api
based
on
coral.
B
B
G
So
the
sdf
descriptors,
the
sdf
themes
that
we
already
provide.
If
you
go
on
to
the
playground,
you
could
find
a
temperature
sensor
that
you
could
already
use
and
pattern
your
you
know,
northbound
facing
gateway
api
on
that
using
that
and
and
basically
some
to
to
identify
the
living
room.
You
need
some
additional
vocabulary
that
we
haven't
built
into
sdf.
G
You
could
define
an
object
as
a
room
with
properties
being
the
type
of
room
that
it
is
an
enum
and
call
it
living
room
and
you
could
use
that
to
prototype
the
system
or
you
could
go.
Look
at
some
other
ontologies
like
maybe
sa
ref
has
some
room
definitions
in
it
and
I
know
there's
some
some
other
ones,
some
xml
vocabularies
that
have
lots
of
room
definitions
in
them.
But
you
know
it
seems,
like
you
could
add,
link
relations.
G
That
say
this
is
a
temperature
sensor,
because
the
easy
one
because
you
could
just
say
you
know,
type
or
whatever
like
a
and
internal
or
whatever,
and
then
you
could
say
location
which
I
think
when
you
know
there
may
be
some
some
common
link
relations
you
could
use,
and
then
you
could
use
that
vocabulary
for
living
room
and
and
having
that
it
would
seem
to
be
easy
enough
to
construct
an
application
that
would
go
in
and
use
the
function.
You
were
describing
earlier
to
query
a
choral
document
and
find
the
the
ones
that
have.
G
Maybe
you
would
just
write
brute
force,
query
all
the
documents
in
repository
and
and
return
the
ones
or
the
fragments
of
the
ones
that
describe
the
part
you
need
that
have
living
room
and
temperature
sensor,
and
then
you
would
do
the
the
averaging
math
on
that
and
maybe
output
it
again
as
another
virtual
sensor
that
then
you
could
use
in
another
application.
Just
pretending
it's
a
sensor.
B
B
G
I
think
some
of
the
interesting
questions
are:
how
do
you?
How
do
you
come
up
with
common,
interoperable
serializations
and
I
think
that's
maybe
just
shapes
and
coral,
so
that
may
not
be
so
difficult
and
the
other
one
is
really
just
sort
of
like
network
management
and
base
addresses,
and
things
like
that,
because
I
think
you
could
probably
come
up
with
paths
already
in
the
synthesis
part
from
from
sdf,
and
I
think
you
could
use
jsonpath
type
constraints
in
the
links
as
well.
G
B
And
the
other
master's
thesis
was
about
the
southbound
of
this,
so
here
he
you
could
connect
your
lightweight
mtm
device
to
to
the
southbound
interface
and
that
would
register
the
device
in
in
this
thing
thing
in
the
middle,
and
it
would
of
course,
then
know
where
how
to
contact
the
device-
and
it
generates
some
instance
id
for
for
the
device
that
then
exposes
it.
Then,
over
graphql
and
open
api
on
the
northbound
side
and,
for
example,
in
graphql,
you
have
something
similar
to
a
schema.
B
G
G
E
If
we
had
this,
this
sketched
converter,
would
there
anything
be
missing
from
for
for
applications
where
the
where
a
constraint
device
uses
the
uses,
the
sdf
definitions
through
some
converter?
That
is
not
constrained,
but
produces
the
the
adjusted
coral
to
interact
directly
with
the
devices
that
do
not
that
that
speak
whichever
detailed
protocol
as
long
as
all
parties
can
process
the
choral
forms
that
are
produced
in
this
in
the
course
of
this
conversion,.
G
G
G
F
But
it
could
be
interesting
to
see
an
example
of
sorry
if
I
don't
use
the
right
terminology
of
an
sdf
instance
in
which
you
have
like
in
the
so,
for
instance,
in
the
minutes.
At
the
moment,
there
is
a
diagram
in
which
you
have
a
coral
based
rest
api
that
potentially
could
interact
with
live
with
n2m
or
ocf
or
other
objects,
and
my
understanding
is
that
those
would
be
expressed
as
namespaces
in
the
in
an
sdf
instance.
F
I.
It
could
be
very
interesting
to
see
an
example
of
such
instance,
because
in
there
you
could
have,
for
the
same
sdf
instance
links
to
multiple
choral
interactions
from
other
sdo's,
so
you
can
have
their
interactions
towards
ipso
towards
ocf.
It
could
be
a
an
interesting
example
if
I
am
understanding
the
discussion
correctly
by
the
way.
G
Yes,
and
indeed
that
that
would
I
would,
I
would
add,
to
clarify
that
that
means
that
we
would
use
the
standardized
coral
pattern
as
the
northbound
api
to
a
gateway
that
had
a
number
of
different
protocol
devices
that
offered
similar
affordances
and
those
affordances
would
all
be
normalized
to
sdf
and
then
and
then.
Basically,
there
would
be
one
way
of
interacting
with
all
those
different
protocol
devices
us
through
sdf.
Through
this
coral
sdf
northbound.
F
G
G
B
And
mostly
it's
it's
a
collection
resource
where
the
collection
items
are
pending
orders,
so
you
can
submit
your
coffee
order
to
the
machine
and
then
it
gets
appended
to
the
collection
resource.
It's
like
a
queue
and
and
then
at
some
point,
your
order
reaches
the
first
spot
in
the
queue
that
makes
it
an
active
order.
B
B
G
F
F
F
A
F
F
A
G
So
I
think
the
copy
machine
is
definitely
a
good
smoke
test
of
the
whole
thing,
but
I
think
to
get
it
to
get
it
jump
started.
We
could
do
some
of
the
simpler
ones
that
are
just
sdf
objects,
simple
objects,
because
the
copy
machine
is
going
to
bring
into
play
questions
of
how
you
compose
multiple
multiple
objects
and
how
you
layer
collections
and
things
like
that.
G
That
don't
really
need
to
be
answered
right
away
more,
like
the
basic
questions
of
how
do
you
convert
an
object
to
coral
and
what
are
the
additional
semantic
hints
that
you
might
need
and
things
like
that
and
then
once
once
those
a
couple
of
those
are
done,
then
I
think
that
you
know
that
you
would.
You
would
be
able
to
sort
of
tackle
the
composition
questions
not
that
they
have
to
be
done
in
order
like
that,
but
I
think
it
would.
G
It
would
might
be
useful
to
just
separate
the
concerns
at
least
and
then,
but
I
don't
know
about
a
project
plan.
I
don't
know
who
has
resources
to
go,
and
you
know
like
sort
of
work
on
this
sort
of
thing.
That
would
be
an
interesting
question
if
there's
enough
interest
to
sort
of
take
it
to
the
next
step.
I
think
that
how
do
we
make
it
real?
You
know
how
do
we
that
would
be.
That
is
a
good
question.
I
think.
F
How
can
we
paste
it
in
the
chat
in
the
minutes,
even
better
yeah?
So
that's
an
example
yeah
the
chat
it
wouldn't
make
any
sense.
It
wouldn't
render.
So
that's
an
example
of
sdf
that
has
choral
interactions
and
choral
issues
for
for
describing
the
interactions
and
they're
in
the
name
space.
I'm
for
forgive
me,
the
sdf,
the
faults
and
the
moral
express.
If
I
don't
explain
it
properly,
feel
free
to
jump
in
on
the
basically
you
have
there.
F
The
three
namespace
one
is
for
something
called
a
digital
twin,
the
other
one
is
for
ipso
and
the
other
one
is
for
saref.
So
all
the
reference
below
when
you
see
dt
column
and
then
hashtag
blah
blah
blah,
then
that
is
referencing
to
the
namespace.
So
you
have
there
the
the
links
that
the
potential
client
that
supposedly
I
guess,
he'll,
be
using
http
in
this
case,
but
it
could
be
for
co-op.
B
So
if
you
have
an
sdf
file
that
defines
classes
like
a
room,
for
example
and
and
some
some
temperature
sensor,
then
this
could
be
a
format
to
describe
sdf
instances.
So
in
this
case
it
describes
two
rooms,
room
one
and
room
two
and
one
temperature
sensor
sensor
one,
and
it
says
that
room
one
is
an
instance
of
an
sdf
object,
room
same
for
room
two
and
sensor.
One
is
an
instance
of
an
ipso
object
temperature,
and
then
there
are
a
bunch
of
sdf
relations
or
relations
to
to
the
other
instances.
B
And
of
course
you
could
also
provide
the
values
of
static
properties
here.
So
if
you,
for
example,
have
a
unit
property
that
never
changes
you,
you
could
just
put
the
unit
value
here
that
is
used
by
this
concrete
instance
e.
Even
if
the
the
class
offers
the
choice
between
multiple
different
units-
and
then
I
don't
know,
do
you
also
want
to
copy
the
core
example.
F
G
G
I've
done
a
lot
of
the
same
things
in
some
industrial
context,
but
yeah.
This
is
interesting,
like
if
you'd
like
to
circle
back
and
kind
of
get
some
feedback
on
your
experience
with
using
some
of
these
extensions
and
like
the
relation
one,
for
example,
is
something
that
ari
had
had
brought
up
a
couple
weeks
ago.