Copyright © 2017-2018 W3C ® ( MIT , ERCIM , Keio , Beihang ). W3C liability , trademark and permissive document license rules apply.
This is the first draft of the new simplified TD approach based on JSON-LD 1.1. Some definitions are not finished yet and are still in progress. A stable Thing Description deliverable version based on JSON-LD 1.0 can be found here .
This
document
describes
a
formal
model
and
a
common
representation
for
a
Web
of
Things
(WoT)
Thing
Description.
A
Thing
Description
describes
the
metadata
and
interfaces
of
Things,
where
a
Thing
is
an
abstraction
of
a
physical
or
virtual
entity
that
provides
interactions
to
and
participates
in
the
Web
of
Things.
Thing
Descriptions
provide
a
narrow-waist
set
of
interactions
based
on
a
small
vocabulary
that
makes
it
possible
both
to
integrate
diverse
devices
and
to
allow
diverse
applications
to
interoperate.
Thing
Descriptions,
by
default,
are
encoded
in
JSON-LD.
a
JSON
format
that
also
allows
JSON-LD
processing.
The
latter
provides
both
a
powerful
foundation
to
represent
knowledge
about
Things
and
simplicity,
since
it
allows
processing
as
in
a
JSON
document.
In
addition
to
physical
entities,
Things
can
also
represent
virtual
entities.
machine-understandable
way.
A
Thing
Description
instance
can
be
hosted
by
the
Thing
itself
or
hosted
externally
due
to
Thing's
when
a
Thing
has
resource
restrictions
(e.g.
(e.g.,
limited
memory
space)
or
when
a
Web
of
Things-compatible
legacy
device
is
retrofitted
with
a
Thing
Description.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.
Implementers need to be aware that this specification is considered unstable. Vendors interested in implementing this specification before it eventually reaches the Candidate Recommendation phase should subscribe to the repository and take part in the discussions.
Please
contribute
to
this
draft
using
the
GitHub
Issue
feature
of
the
WoT
Thing
Description
repository.
For
feedback
on
security
and
privacy
considerations,
please
use
the
WoT
Security
and
Privacy
Issues,
as
they
are
security
and
privacy
is
cross-cutting
over
all
our
documents.
This document was published by the Web of Things Working Group as a Working Draft. This document is intended to become a W3C Recommendation.
Comments
regarding
this
document
are
welcome.
Please
send
them
to
<EMAIL_ADDRESS>(
subscribe
,
archives
).
Changes
from
the
previous
publication
can
be
found
in
Appendix
A
B
.
A
diff-marked
version
of
this
document
is
also
available
for
comparison
purposes.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This document was produced by a group operating under the W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
This document is governed by the 1 February 2018 W3C Process Document .
The
W3C
Thing
Description
(TD)
is
a
central
building
block
in
a
the
W3C
Web
of
Things
(WoT)
enabled
system
and
can
be
considered
as
the
entry
point
of
a
Thing
(aka
(much
like
the
index.html
of
the
Thing).
a
Web
site).
The
TD
consists
of
semantic
metadata
for
the
Thing
itself,
a
narrow-waist
an
interaction
model
with
based
on
WoT's
Properties,
Actions,
Properties
,
Actions
,
and
Events,
Events
paradigm,
a
semantic
schema
to
make
data
models
machine-understandable,
and
features
for
Web
Linking
to
express
relations
among
Things.
Properties
can
be
used
for
sensing
and
controlling
(or
retrieving)
parameters,
such
as
a
setting
an
operation
state
(or
getting
the
current
value).
value
or
setting
an
operation
state.
Actions
model
invocation
of
physical
(and
hence
time-consuming)
processes,
but
can
also
be
used
to
abstract
RPC-like
calls
of
existing
platforms.
Events
cover
are
used
for
the
push
model
of
communication
where
state
change
notifications,
discrete
events,
and
or
streams
of
values
are
sent
asynchronously
to
the
receiver.
In
general,
the
TD
provides
metadata
for
the
different
communication
bindings
identified
by
URI
schemes
(e.g.,
HTTP,
CoAP,
MQTT,
"http",
"coap",
"mqtt",
etc.),
mediaTypes
media
types
(e.g.,
"application/json",
"application/xml",
"application/cbor",
"application/exi"
etc.),
and
security
policies
(authentication,
mechanisms
(for
authentication,
authorization,
confidentiality,
etc.).
The
default
serialisation
Serialization
of
the
TD
instances
is
JSON-LD.
based
on
JSON
and
includes
at
least
the
TD
core
vocabulary
as
JSON
keys
as
defined
in
this
specification
document.
Example
1
shows
a
simple
TD
instance
that
reflects
in
such
a
JSON
serialization
and
depicts
WoT's
Property,
Action,
Event
Properties
,
Actions
,
and
Events
paradigm
by
describing
a
lamp
Thing
with
the
name
MyLampThing
.
{
: ["https://w3c.github.io/wot/w3c-wot-td-context.jsonld"],
: ["Thing"],
: "urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
: [
{
: ["Property"],
: "status",
: {"type": "string"},
: false,
: true,
: [{
: "coaps://mylamp.example.com:5683/status",
"mediaType": "application/json"
}]
},
{
: ["Action"],
: "toggle",
: [{
: "coaps://mylamp.example.com:5683/toggle",
"mediaType": "application/json"
}]
},
{
: ["Event"],
: "overheating",
: {"type": "string"},
: [{
: "coaps://mylamp.example.com:5683/oh",
"mediaType": "application/json"
}]
}
]
"security": [{"hljs-attr">"scheme": "basic"}],
"properties": { "status" : { "type":
"hljs-string">"string",
"forms": [{
"hljs-attr">"href": "https://mylamp.example.com/status"}]
}
},
"actions": { "toggle" : { "forms": [{
"hljs-attr">"href": "https://mylamp.example.com/toggle"}]
}
},
"events":{ "overheating":{ "type":
"hljs-string">"string",
"forms": [{ "href":
"hljs-string">"https://mylamp.example.com/oh",
"hljs-attr">"subProtocol": "LongPoll"
}]
}
}
}
Based
on
this
content,
we
know
there
exists
one
Property
interaction
resource
with
the
name
status
.
In
addition,
information
is
provided
such
as
to
indicate
that
this
Property
is
accessable
over
accessible
via
(the
secure
form
of)
the
CoAP
HTTP
protocol
with
a
GET
method
(see
CoAP
protocol
binding
description
in
the
W3C
WoT
protocol
template
deliverable
[
WOT-PROTOCOL-BINDING
])
at
coaps://mylamp.example.com:5683/status
the
URI
https://mylamp.example.com/status
(announced
within
the
structure
by
the
form
forms
href
key),
which
and
will
return
a
string
status
value
within
a
JSON
structure
(JSON
as
payload
format
value.
The
use
of
the
GET
method
is
announced
by
not
stated
explicitly,
but
is
one
of
the
mediaType
field).
default
assumptions
defined
by
this
document.
In
a
similar
manner
manner,
an
Action
is
specified
to
toogle
toggle
the
switch
status
using
the
POST
method
that
is
applied
to
the
coaps://mylamp.example.com:5683/toggle
resource
(see
CoAP
protocol
binding
description
in
the
W3C
WoT
protocol
template
deliverable
[
WOT-PROTOCOL-BINDING
]).
https://mylamp.example.com/toggle
resource,
where
POST
is
again
a
default
assumption
for
invoking
Actions.
Events
which
are,
e.g.,
unexpected
or
irregular
can
be
specified
with
the
WoT's
The
Event
pattern
enables
a
mechanism
for
asynchronous
messages
to
be
sent
by
a
Thing.
Here,
a
subscription
model.
of
to
be
notified
upon
a
possible
overheating
event
of
the
lamp
can
be
applied
obtained
by
using
CoAP
OBSERVE
at
coaps://mylamp.example.com:5683/oh.
(see
CoAP
protocol
binding
description
in
the
W3C
WoT
protocol
template
deliverable
[
WOT-PROTOCOL-BINDING
]).
HTTP
with
its
long
polling
sub-protocol
at
https://mylamp.example.com/oh
.
The
Thing
Description
defines
This
example
also
specifies
the
basic
security
scheme,
requiring
a
relative
small
set
username
and
password
for
access.
In
combination
with
the
use
of
terms
to
describe
mainly
Thing's
interaction
models.
the
HTTP
protocol
this
indicates
the
use
of
HTTP
Basic
Authentication.
Specification
of
a
security
scheme
at
the
top
level
as
in
this
example
indicates
that
it
is
required
for
every
resource.
However,
security
schemes
can
also
be
specified
per-interaction
or
per-form,
with
lower-level
configurations
overriding
higher-level
ones,
allowing
for
the
specification
of
fine-grained
access
control.
Examples
are
provided
later.
The
TD
opens
in
Example
1
reflects
some
additional
defined
default
assumptions
that
are
not
explicitly
described.
For
example,
the
re-usage
media
type
of
existing
models
from
un-specific
(e.g.,
schema.org,
SSN)
and
specific
domains
(e.g.,
smart
home,
consumer
electronics,
industry,
automotive)
to
enrich
the
capabilities
exchange
format
of
the
interactions
is
assumed
to
be
JSON
(=
mediaType
)
and
the
Property
status
resource
is
not
writable
as
well
as
not
observable.
Specifically,
the
TD
specification
defines
vocabulary
terms
(
writable
,
observable
,
mediaType
)
that
have
default
values.
If
these
vocabulary
terms
are
not
explicitly
used
in
a
Thing
with
further
vocabulary
and
semantics.
Description
instance,
the
Thing
Description
processor
follows
default
assumptions
for
interpretation
as
defined
in
this
specification.
The
following
example
extends
TD
can
be
also
processed
as
an
RDF-based
model.
In
that
case,
the
previous
shown
example
Thing
Description
instance
needs
to
be
transformed
into
valid
JSON-LD
first.
In
terms
of
JSON-LD
1.1
serialization,
the
open-world
assumption
of
RDF
semantic
processing
requires
vocabulary
terms
with
further
semantics
from
default
values
to
be
always
present
explicitly
in
the
iotschema.org
context.
instances.
Example
2
shows
the
same
TD
in
a
JSON-LD
1.1
serialization
representing
exactly
the
same
information
as
in
Example
1;
however,
default
values
have
been
filled
in.
{
: ["https://w3c.github.io/wot/w3c-wot-td-context.jsonld",
{: "http://iotschema.org/"}],
: ["Thing", "iot:Light", "iot:BinarySwitch"],
: "http://www.w3.org/ns/td",
"id":
"hljs-string">"urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
: [
{
: ["Property", "iot:SwitchStatus"],
: "status",
: {"type": "string"},
: "scheme": "basic", "in": "header"}],
"properties": { "status": { "writable": false,
: true,
: [{
: "coaps://mylamp.example.com:5683/status",
"observable": false,
"type":
"hljs-string">"string",
"forms": [{ "href":
"hljs-string">"https://mylamp.example.com/status",
"hljs-attr">"http:methodName": "GET",
"mediaType": "application/json"
}]
},
{
: ["Action", "iot:ChangeSwitchStatus"],
: "toggle",
: [{
: "coaps://mylamp.example.com:5683/toggle",
"https://mylamp.example.com/toggle",
"hljs-attr">"http:methodName": "POST",
"mediaType": "application/json"
}]
},
{
: ["Event", "iot:TemperatureAlarm"],
: "overheating",
: {"type": "string"},
: [{
: "coaps://mylamp.example.com:5683/oh",
"string",
"forms": [{ "href":
"hljs-string">"https://mylamp.example.com/oh",
"hljs-attr">"subProtocol": "LongPoll",
"mediaType": "application/json"
}]
}
]
}]
}
}
}
For
more
examples,
including
the
samples
provided
in
use
of
other
protocols
besides
HTTP,
see
Section
6.7.
7.
Example
Thing
Description
Instances
.
The
generic
Generic
WoT
terminology
is
defined
in
[
WOT-ARCHITECTURE
]:
Thing
,
Thing
Description
(in
short
TD
),
Web
of
Things
(in
short
WoT
),
WoT
Interface
etc.
The
namespace
for
the
W3C
TD
is
http://www.w3.org/ns/td#
.
TD
itself
defines
a
minimal
set
of
classes
and
properties
of
its
own.
A
full
set
of
namespaces
and
prefixes
used
vocabulary
as
defined
in
this
document
is
shown
in
http://www.w3.org/ns/td
.
Using
content
negotiation,
this
namespace
serves
either
the
table
below.
TD
ontology
file
(Turtle)
or
the
TD
context
file
(JSON-LD).
The
suggested
prefix
for
the
TD
namespace
is
td
.
http://www.w3.org/ns/td#
rdf
http://www.w3.org/1999/02/22-rdf-syntax-ns#
The security ontology that can be used with the TD is available at https://www.w3.org/ns/wot-security .
The data schema ontology that can be used with the TD is available at https://www.w3.org/ns/json-schema .
ToDo:
complete
table
The
TD
will
reuse
existing
vocabulary
definitions
such
as
for
http
from
the
http://www.w3.org/2011/http#
namespace.
In
that
case
the
prefix
http
is
used.
However,
there
are
prefixes
such
as
coap
and
mqtt
which
have
no
namespace
yet.
Currently
there
are
efforts
to
have
such
namespace
representations
which
will
be
referenced
in
the
TD
specification
in
the
future.
In
the
meantime,
the
[
WOT-PROTOCOL-BINDING
]
provides
the
list
of
terms
that
can
be
used
to
specify
the
protocol
metadata
in
the
Thing
Description.
As well as all sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MUST , MUST NOT , REQUIRED , SHOULD , SHOULD NOT , RECOMMENDED , MAY , and OPTIONAL in this specification are to be interpreted as described in [ RFC2119 ].
A
Thing
Description
instance
complies
with
this
specification
if
it
follows
the
normative
statements
in
Section
5.
Vocabulary
Definition
Information
Model
.
In
case
of
JSON-LD
serializiation,
a
Thing
Description
instance
in
JSON-LD
format
complies
with
this
specification
if
it
follows
the
normative
statements
in
and
Section
6.
Thing
Description
Serialization
regarding
Thing
Description
serialization.
A JSON Schema [ JSON-SCHEMA-VALIDATION ] is provided in Annex A. JSON Schema for TD Instance Validation to validate Thing Description instances based on JSON-LD 1.1.
We
need
to
be
more
precise
here:
How
to
validate
a
TD?
E.g.,
structure
validation
and/or
In
the
future
some
information
about
RDF
validation?
Comments
are
welcome.
validation
will
be
provided.
The
W3C
Thing
Description
relys
on
provides
a
small
set
of
vocabulary.
vocabulary
for
describing
physical
and
virtual
Things.
To
increase
interoperability
the
vocabulary
terms
are
defined
using
the
Resource
Description
Framework
(RDF).
All
vocabulary
restrictions
noted
in
these
tables
MUST
be
followed,including
mandatory
items
and
default
values.
In
general,
the
Thing
Description
vocabulary
set
is
grouped
in
three
modules:
the
core
Thing
Description
vocabulary
reflecting
WoT's
paradigm
of
Properties
,
Actions
,
and
Events
(also
see
[
WOT-ARCHITECTURE
]);the
data
schema
vocabulary
reflecting
a
subset
of
the
terms
defined
in
JSON
Schema
[
JSON-SCHEMA-VALIDATION
]
in
a
linked
data
representation;
and
the
security
vocabulary
used
to
define
security
mechanismconfiguration
requirements.
An
overview
of
this
vocabulary
with
its
class
context
and
class
relation
is
given
by
the
following
figure.
three
figures:
the
TD
core
model,
the
TD
data
schema
model,
and
the
TD
security
model.
Please
note
that
the
figures
reflect
the
vocabulary
terms
and
structure
as
they
would
be
used
in
a
Thing
Description
instance
(see
Section
6.
Thing
Description
Serialization
).The
full
ontology
definitions
of
the
different
modules
can
be
viewed
by
following
the
namespaces
as
provided
in
Section
3.
Namespaces
.
There
is
an
information
missing
from
In
the
tables
figures
above,
and
in
subsequent
sub-sections
as
the
tables
to
follow,
items
which
vocabulary
is
have
default
values
are
indicated
as
being
optional.
However,
technically,
these
are
optional
or
mandatory.
Since
only
in
the
JSON
serialization
.
They
are
actually
mandatory
parts
of
the
information
model
and
are
also
mandatory
in
the
JSON-LD
serialization.
In
addition,
the
security
scheme
configuration
is
already
available
not
actually
optional
even
in
the
ontology
files,
tools
need
to
JSON
serialization.
Security
configuration
is
mandatory
at
least
one
of
the
three
levels
at
which
it
may
be
updated
to
extract
and
utilize
specified...
so
it
can
be
omitted
only
if
it
is
specified
at
a
different
level
for
each
form.
A
future
version
of
this
information
to
generate
document
should
better
express
the
content
status
of
these
tables.
attributes.
A detailed description of the vocabulary of the TD core model and TD data schema model is given in the next sub-section.
Thing
Describes
a
physical
and/or
virtual
Thing
(may
represent
one
or
more
physical
and
/
or
and/or
virtual
Things)
in
the
Web
of
Thing
Things
context.
| Field Name | Description |
|
Default
value
|
Type |
|---|---|---|---|---|
|
| yes | . |
|
|
| no | . |
|
|
|
yes | . |
|
support
| Provides information about the TD maintainer (e.g., author, link or telephone number to get support, etc). | no | . |
string
|
base
|
Define
the
base
URI
that
is
valid
for
all
defined
local
interaction
resources.
All
other
URIs
in
the
TD
must
then
be
resolved
using
the
algorithm
defined
in
[
RFC3986
].
|
no | . |
anyURI
|
|
| no | . |
Property
|
actions
|
All
Action-based
interaction
| no | . |
Action
|
events
| All Event-based interaction patterns of the Thing. | no | . |
Event
|
links
|
Provides
Web
links
to
arbitrary
resources
that
relate
to
|
no | . |
array
of
Link
|
| Set of security configurations, provided as an array, that must all be satisfied for access to resources at or below the current level, if not overridden at a lower level. | no | . |
array
of
SecurityScheme
|
InteractionPattern
Three interaction patterns are defined as subclasses: Property, Action and Event. When a concrete Property, Action or Event is defined in a Thing Description, it is called an "interaction resource". Interactions between Things can be as simple as one Thing accessing another Thing's data to get or (in the case the data is also writable) change the representation of data such as metadata, status or mode. A Thing may also be interested in getting asynchronously notified of future changes in another Thing, or may want to initiate a process served in another Thing that may take some time to complete and monitor the progress. Interactions between Things may involve exchanges of data between them. This data can be either given as input by the client Thing, returned as output by the server Thing or both.
Each
instance
of
a
Property
,
Action
,
and
Event
class
MUST
have
an
identifier
that
is
unique
within
the
context
of
a
Thing
Description
document.
See
Section
Representation
Format
for
more
details
about
JSON-LD
1.1
identifiers.
| Field Name | Description |
|
Default
value
|
Type |
|---|---|---|---|---|
|
Indicates
one
or
more
endpoints
from
which
an
interaction
pattern
is
|
yes | . |
array
of
Form
|
|
| no | . |
string
|
description
| Provides additional (human) readable information. | no | . |
string
|
security
|
Set
of
security
configurations,
provided
as
an
array,
that
must
all
be
| no | . |
array
of
SecurityScheme
|
scopes
| Set of authorization scope identifiers, provided as an array. These are provided in tokens returned by an authorization server and associated with forms in order to identify what resources a client may access and how. | no | . |
array
of
string
|
The
class
InteractionPattern
has
the
following
subclasses:
Property
Property
provides
readable
and/or
writeable
data
Properties
expose
internal
state
of
a
Thing
that
can
be
static
(e.g.,
supported
mode,
rated
output
voltage,
etc.)
or
dynamic
(e.g.,
current
fill
level
of
water,
minimum
recorded
temperature,
etc.).
Please
note,
this
class
directly
retrieved
(get)
and
optionally
modified
(set).
In
addition,
Things
can
also
inherited
all
vocabulary
from
choose
to
make
Properties
observable
by
pushing
the
InteractionPattern
class.
new
state
(not
an
event)
after
a
change;
this
must
follow
eventual
consistency
(also
see
CAP
Theorem).
| Field Name | Description |
|
Default
value
|
Type |
|---|---|---|---|---|
|
Indicates whether a remote servient can subscribe to ("observe") the Property, to receive change notifications or periodic updates (true/false). | no | false |
boolean
|
writable
|
Boolean
value
that
indicates
whether
a
property
is
writable
(=true)
or
not
| no | false |
boolean
|
Property
instances
may
also
be
instances
of
the
class
DataSchema
and
therefore
can
contain,
among
others,
the
type
term.
Action
The
Action
interaction
pattern
triggers
changes
or
processes
on
Actions
offer
functions
of
the
Thing.
These
functions
may
manipulate
the
internal
state
of
a
Thing
that
take
in
a
certain
time
to
complete
(i.e.,
actions
cannot
be
applied
instantaneously
like
property
writes).
way
that
is
not
possible
through
setting
Properties.
Examples
include
an
LED
fade
in,
moving
are
changing
internal
state
that
is
not
exposed
as
a
robot,
brewing
Property,
changing
multiple
Properties,
changing
Properties
over
time
or
with
a
cup
of
coffee,
etc.
Usually,
ongoing
process
that
should
not
be
disclosed.
Actions
are
modelled
as
Task
resources,
which
are
created
when
an
Action
invocation
is
received
by
the
Thing.
Please
note,
this
class
may
also
inherited
all
vocabulary
from
be
pure
functions,
that
is,
they
may
not
use
any
internal
state
at
all,
and
may
simply
process
input
data
and
return
a
result
that
directly
depends
only
on
the
InteractionPattern
class.
input
given.
| Field Name | Description |
|
Default
value
|
Type |
|---|---|---|---|---|
|
|
no | . |
DataSchema
|
|
|
no | . |
DataSchema
|
Event
This
class
embeds
the
terms
The
Event
Interaction
Pattern
describes
event
sources
that
asynchronously
push
messages.
Here
not
state,
but
state
transitions
(events)
are
defined
communicated
(e.g.,
"clicked").
Events
may
be
triggered
by
JSON
Schema
(
https://tools.ietf.org/html/draft-handrews-json-schema-validation-00#section-6
)
and
map
them
in
a
Linked
Data
form
to
allow,
e.g.,
the
representation
of
pairs
(data
type,
semantic
meaning
such
as
unit
of
measure)
internal
state
changes
that
are
expected
not
exposed
as
input
data
or
output
data
Properties.
Events
usually
follow
strong
consistency,
where
messages
need
to
be
queued
to
ensure
eventual
delivery
of
a
given
interaction
pattern.
all
events
that
have
occurred.
Instances
of
the
TD
deliverable
Event
class
contains
the
full
list
term
definitions
of
schema
terms
will
be
defined
here.
For
now,
please
check
the
data
schema
defintions
that
are
provided
in
Section
6.5
class
InteractionPattern
and
examples
provided
in
WoT
Binding
Template
DataSchema
.
Form
Communication metadata indicating where a service can be accessed by a client application. An interaction might have more than one form.
| Field Name | Description |
|
Default
value
|
Type |
|---|---|---|---|---|
href
|
URI
of
the
endpoint
where
an
interaction
pattern
is
| yes | . |
anyURI
|
mediaType
|
Assign
the
underlying
media
type
[
MEDIATYPES
]
of
| no | application/json |
string
|
rel
|
Indicates
the
expected
result
of
performing
the
operation
described
by
the
form.
For
example,
the
Property
interaction
allows
get
and
set
operations.
The
protocol
binding
may
contain
a
form
for
the
get
operation
and
a
different
form
for
the
set
operation.
The
The
value
of
the
|
no | . |
string
(one
of
|
subProtocol
| Indicates the exact mechanism by which an interaction will be accomplished for a given protocol when there are multiple options. For example, for HTTP and Events, it indicates which of several available mechanisms should be used for asynchronous notifications. | no | . |
string
(one
of
|
security
| Set of security configurations, provided as an array, that must all be satisfied for access to resources at or below the current level, if not overridden at a lower level. | no | . |
array
of
SecurityScheme
|
scopes
| Set of authorization scope identifiers, provided as an array. These are provided in tokens returned by an authorization server and associated with forms in order to identify what resources a client may access and how. | no | . |
array
of
string
|
Link
A
Web
link,
as
specified
by
IETF
RFC
8288
(
https://tools.ietf.org/html/rfc8288)
.
(https://tools.ietf.org/html/rfc8288).
| Field Name | Description |
|
Default
value
|
Type |
|---|---|---|---|---|
|
URI
of
the
endpoint
where
an
interaction
pattern
is
| yes | . |
anyURI
|
mediaType
|
Assign
the
underlying
media
type
[
MEDIATYPES
]
of
| no | application/json |
string
|
rel
|
Indicates
the
expected
result
of
performing
the
operation
described
by
the
form.
For
example,
the
Property
interaction
allows
get
and
set
operations.
The
protocol
binding
may
contain
a
form
for
the
get
operation
and
a
different
form
for
the
set
operation.
The
| no | . |
string
|
|
By
default,
the
context
of
a
link
is
the
| no | . |
anyURI
|
DataSchema
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
description
|
|
| . |
string
|
type
|
|
no | . |
string
(one
of
|
const
|
|
no | . |
field
|
enum
|
|
no | . |
array
of
type
field
definition
if
any
|
Each
field
in
Thing
The
class
(see
5.2.1
Thing
)
is
represented
by
the
namesake
JSON
field
described
in
DataSchema
has
the
above
table.
following
subclasses:
@context
ArraySchema
BooleanSchema
@context
IntegerSchema
NumberSchema
ObjectSchema
StringSchema
Property
ArraySchema
The
JSON-LD
representation
for
a
Property
interaction
definition
is
a
A
JSON
object
of
which
the
fields
are
defined
below.
array
specification
("type":
"array").
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
items
|
|
| . |
|
minItems
|
|
|
. |
unsignedInt
|
maxItems
|
|
no | . |
unsignedInt
|
Action
ObjectSchema
JSON-LD
representation
for
an
Action
interaction
definition
is
a
A
JSON
object
of
which
the
fields
are
defined
below.
specification
("type":
"object").
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
properties
|
|
| . |
|
required
|
|
no | . |
string
|
BooleanSchema
A JSON boolean value specification ("type": "boolean").
NumberSchema
A JSON number value specification ("type": "number").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
minimum
|
|
no | . |
double
|
maximum
|
|
no | . |
double
|
StringSchema
A
JSON
field
described
in
the
above
table.
string
value
specification
("type":
"string").
Event
interaction
pattern
(also
see
Event
vocabulary
definition
section
)
enables
a
mechanism
to
be
notified
by
a
Thing
on
a
certain
condition.
While
some
protocols
such
as
CoAP
can
provide
such
a
mechanism
natively,
others
do
not.
Furthermore,
Events
might
need
a
specific
configuration
that
requires
data
sent
and
stored
on
the
Thing
in
a
standard
way.
There
are
are
three
mandatory
terms
and
one
optional
term
defined
within
the
Event
IntegerSchema
The
JSON-LD
representation
for
an
Event
interaction
definition
is
a
A
JSON
object
of
which
the
fields
are
defined
below.
integer
value
specification,
that
is,
numbers
without
a
fractional
part
("type":
"integer").
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
|
|
|
. |
integer
|
maximum
|
|
no | . |
integer
|
This
section
describes
JSON-LD
serialization
for
For
the
instances
core
TD
vocabulary
only
well-established
security
mechanisms
are
supported,
such
as
those
built
into
protocols
supported
by
WoT
or
already
in
wide
use
with
those
protocols.
The
current
set
of
the
5.2.7
Form
HTTP
security
schemes
is
partly
based
on
OpenAPI
3.0.1
(see
also
[
OPENAPI
class.
Shown
below
is
an
example
]).
Note
however
that
while
the
HTTP
security
schemes,
vocabulary
and
syntax
given
in
this
specification
share
many
similarities
with
OpenAPI
they
are
not
fully
compatible.
Also,
since
OpenAPI
primarily
targets
web
services
built
around
HTTP,
it
does
not
cover
the
full
set
of
a
form
definition.
use
cases
required
for
the
IoT.
Security
schemes
appropriate
for
IoT-centered
protocols
such
as
CoAP
and
MQTT
are
therefore
also
included.
The
vocabulary
extension
mechanism
of
the
WoT
Thing
Description
allows
for
additional
security
schemes
if
needed.However,
for
more
information
about
what
additional
security
schemes
or
modifications
are
under
discussion
for
a
web
form
definition
is
a
JSON
array
with
name
"form".
Each
item
in
the
array
is
core
WoT
vocabulary(and
to
file
issues
if
you
have
a
JSON
object
that
consists
of
two
JSON
fields
as
summarized
below.
request)
please
visit
the
WoT
Security
TF
repository.
SecurityScheme
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
scheme
|
|
yes | . |
string
(one
of
|
description
|
|
| . |
string
|
proxyUrl
|
|
no | . |
|
The
form
field
is
used
to
pointing
a
URI
to
an
instance
of
the
interaction
and
descriptions
of
the
protocol
settings
and
options
expected
to
be
used
between
the
client
and
server
for
the
interaction.
The
different
opportunities
of
class
SecurityScheme
has
the
protocol
settings
(such
as
for
HTTP,
CoAP,
MQTT,
etc)
is
described
in
[
following
subclasses:
CertSecurityScheme
alg
)
and
the
issuing
authority
of
the
security
token
(
as
APIKeySecurityScheme
Property
BasicSecurityScheme
Event
BearerSecurityScheme
schema
DigestSecurityScheme
Action
NoSecurityScheme
inputSchema
OAuth2SecurityScheme
outputSchema
PSKSecurityScheme
Property
PoPSecurityScheme
schema
PublicSecurityScheme
NoSecurityScheme
A
security
configuration
corresponding
to
be
encoding-neutral
and
integrates
into
the
Linked
Data
vocabularies
("scheme":
"nosec"),
indicating
there
is
no
authentication
or
other
mechanism
required
to
allow
semantic
annotations.
It
can
not
only
be
directly
translated
into
JSON
schema,
but
also
can
be
handily
translated
into
XML
Schema.
Use
of
JSON-LD
equips
access
the
type
system
with
a
way
to
associate
data
elements
with
citations
and
semantic
concepts
defined
elsewhere.
resource.
inputSchema
BasicSecurityScheme
Basic authentication security configuration ("scheme": "basic"), using an unencrypted username and password. This scheme should be used with some other security mechanism providing confidentiality, for example, TLS.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
|
Specifies the location of security authentication information (one of header, query, body, or cookie). | no | header |
|
|
Name for query, header, or cookie parameters. | no | . |
|
CertSecurityScheme
JSON-LD
representation
for
primitive
data
type
definition
is
a
JSON
object
of
which
the
field
is
defined
below.
Certificate-base
asymmetric
key
security
configuration
("scheme":
"cert").
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
identity
|
|
| . |
string
|
DigestSecurityScheme
In
order
Digest
authentication
security
configuration
("scheme":
"digest").
This
scheme
is
similar
to
make
more
precise
data
type
defintions
the
TD
also
allows
the
usage
basic
authentication
but
with
added
features
to
avoid
man-in-the-middle
attacks.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
qop
|
Quality
of
| no | auth |
|
|
Specifies
the
| no | header |
string
|
name
| Name for query, header, or cookie parameters. | no | . |
string
|
BearerSecurityScheme
Bearer
token
authentication
security
configuration
("scheme":
"bearer").
This
scheme
is
intended
for
the
full
set
situations
where
bearer
tokens
are
used
independently
of
restrictions.
OAuth2.
If
the
oauth2
scheme
is
specified
it
is
not
generally
necessary
to
specify
this
scheme
as
well
as
it
is
implied.
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
authorizationUrl
|
|
no | . |
|
alg
|
|
no |
|
|
format
|
|
no |
|
string
|
in
|
|
no |
|
string
|
name
|
|
no | . |
string
|
inputSchema
PSKSecurityScheme
JSON-LD
representation
for
semantic
annotation
of
simple
type
within
schema
,
inputSchema
and
outputSchema
fields
is
defined
below.
Pre-shared
key
authentication
security
configuration
("scheme":
"psk").
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
identity
|
|
no | . |
string
|
form
PublicSecurityScheme
Let's
consider
the
simple
data
type
defintion
as
shown
in
Example
11.
When
the
Raw
public
key
asymmetric
key
security
configuration
("scheme":
"public").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
|
Pre-shared key identity. | no | . |
string
|
OAuth2SecurityScheme
With
OAuth2
authentication
security
configuration
("scheme":
"oauth2").
For
the
type
system,
it
is
also
possible
to
define
value
types
that
have
more
than
one
literal
value.
The
type
system
provides
two
distinct
constructs
to
define
a
structure
that
can
have
multiple
literal
values.
One
is
implicit
flow
the
object
,
authorizationUrl
and
scopes
are
required.
For
the
other
one
is
the
array
.
Both
object
password
and
array
client
flows
both
tokenUrl
and
scopes
are
assigned
as
required.
For
the
code
flow
authorizationUrl,
tokenUrl,
and
scopes
are
required.
| Field Name | Description | Mandatory |
Default
value
|
Type |
|---|---|---|---|---|
|
URI
of
the
| no | . |
|
|
URI
of
| no | . |
|
|
URI
of
the
| no | . |
|
|
Set
of
authorization
scope
identifiers,
provided
as
an
array.
These
are
provided
in
| no | . |
array
of
|
flow
|
Authorization flow (one of implicit, password, client, or code). | no | implicit |
string
|
brightness
APIKeySecurityScheme
JSON-LD
representation
API
key
authentication
security
configuration
("scheme":
"apikey").
This
is
for
object
data
type
definition
the
case
where
the
access
token
is
opaque
and
is
not
using
a
JSON
object
with
terms
as
defined
below.
standard
token
format.
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
|
|
|
|
string
|
name
|
|
no | . |
|
array
PoPSecurityScheme
JSON-LD
representation
for
array
type
definition
is
a
JSON
object
with
terms
as
defined
below.
Proof-of-possession
token
authentication
security
configuration
("scheme":
"pop").
| Field Name |
|
Mandatory |
| Type |
|---|---|---|---|---|
authorizationUrl
|
|
| . |
|
alg
|
|
| ES256 |
|
format
|
|
no |
|
string
|
in
|
|
no |
|
string
|
name
|
Name for query, header, or cookie parameters. | no | . |
string
|
This
is
the
case
first
draft
that
uses
JSON-LD
1.1
as
a
serialization
format
of
an
object-based
schema
decleration
the
expected
instance
Thing
Description.
As
that
is
straightforward
and
similar
handling
work
in
progress,
working
assumptions
are
based
on
the
latest
Community
Draft
of
JSON-LD
1.1
.
A
new
JSON-LD
Working
Group
has
already
been
chartered
.
It
is
planned
that
this
section
will
conform
to
JSON
Schema
the
latest
working
draft
of
their
JSON-LD
1.1
deliverable
and
only
use
stable
elements.
Thing
Description
instances
are
modeled
and
structured
based
on
Section
5.
Information
Model
.
This
section
defines
a
TD
serialization
based
on
JSON
instances.
Let's
consider
Example
18:
When
[
RFC8259
].
The JSON serialization of TDs follows the syntax of JSON-LD 1.1 in order to streamline semantic evaluation. Hence, serializations can be parsed either as raw JSON or with a JSON-LD 1.1 processor.
In order to enable this convergence, all vocabulary terms defined in Section 5. Information Model will have a JSON key representation.
In
addition,
Thing
Description
instances
MAY
contain
JSON-LD
1.1
keywords
such
as
brightness
@context
number
and
the
.name
string
values
being
exchanged
@type
The
data
types
of
the
vocabulary
as
defined
in
Section
5.3
Data
Schema
Vocabulary
Definition
will
be
transformed
to
JSON-based
types.
The
following
rules
are
200
used
for
vocabulary
terms
based
on
some
simple
type
definitions:
All
vocabulary
terms
in
Section
5.
Information
Model
associated
with
more
complex
class-based
types
are
defined
separately
for
structured
JSON
format
will
look
like
type
transformation
in
the
following.
following
subsections.
The
above
data
will
look
root
object
of
a
Thing
Description
instance
MAY
include
the
following
when
@context
key
from
JSON-LD
1.1
with
the
data
is
exchanged
in
XML.
value
URI
of
the
Thing
description
context
file
http://www.w3.org/ns/td
.
{ "@context":
"hljs-string">"http://www.w3.org/ns/td",
...
}
http://www.w3.org/ns/td
uses
content
negotiation
to
return
the
context
file.
Thus,
it
must
be
fetched
with
an
Accept
header
set
to
application/ld+json
.
When
a
Thing
Description
instance
is
processed
and
interpreted
by
a
JSON-LD
1.1
processor
the
@context
field
MUST
be
present
>
(see
also
Section
JSON-LD
1.1
Processing
).
When
a
single
Thing
Description
instance
involves
several
contexts,
additional
namespaces
with
prefixes
MUST
be
appended
to
the
@context
array
structure.
This
option
proves
relevant
if
one
wants
to
extend
the
existing
Thing
Description
context
without
modifying
it.
For
instance:
{
"@context": ["hljs-string">"http://www.w3.org/ns/td",
{"iot": "http://iotschema.org/"}],
...
}
In
both
JSON
Each
mandatory
and
XML
serialization,
values
can
appear
in
any
order
regardless
of
the
order
used
optional
field
name
as
defined
in
the
class
field
Thing
definition
of
MUST
be
serialized
as
a
JSON
key
in
the
root
object
.
of
the
Thing
Description
instance.
In
the
case
The
type
of
an
array
decleration
there
is
the
same
bahavior
from
JSON
Schema
fields
properties
,
actions
,
and
events
MUST
be
a
JSON
instances.
Let's
consider
Example
19:
When
object.
The
type
of
the
numbers
being
exchanged
are
520,
184
fields
links
,
scopes
,
and
1314,
data
serialization
in
security
MUST
be
a
JSON
format
will
look
like
array.
A
TD
snippet
based
on
the
following.
defined
fields
of
the
class
Thing
without
the
optional
field
@context
is
given
below:
{
"id": "hljs-string">"urn:dev:wot:com:example:servient:myThing",
"name":
"hljs-string">"MyThing",
"description":
"hljs-string">"Additional (human) readable information of the Thing.",
"support":
"hljs-string">"https://servient.example.com/contact",
"security": [...], "base":
"hljs-string">"https://servient.example.com/",
"properties": {...}, "actions": {...}, "events": {...}, "links": [...]
}
The
above
data
will
look
Alternatively,
the
following
when
same
example
can
be
written
instead
to
explicitly
include
the
data
is
exchanged
in
XML.
(semantic)
keys
used
by
JSON-LD
1.1
(
@context
and
@type
):
{
"@context": "hljs-string">"http://www.w3.org/ns/td",
"@type":
"hljs-string">"Thing",
"id":
"hljs-string">"urn:dev:wot:com:example:servient:myThing",
"name":
"hljs-string">"MyThing",
"description":
"hljs-string">"Additional (human) readable information of the Thing.",
"support":
"hljs-string">"https://servient.example.com/contact",
"security": [...], "base":
"hljs-string">"https://servient.example.com/",
"properties": {...}, "actions": {...}, "events": {...}, "links": [...]
}
properties
In
Properties
(and
sub-properties)
offered
by
a
Thing
MUST
be
collected
in
the
previous
section,
examples
showed
what
data
whose
value
type
is
described
using
JSON-object
based
properties
field
with
(unique)
Property
names
as
JSON
keys.
Property
,
as
well
as
its
two
superclasses
InteractionPattern
and
DataSchema
,
MUST
be
serialized
as
a
JSON
key
within
a
Property
object.
The
type
system
look
like
when
of
the
fields
properties
and
items
MUST
be
serialized
to
XML
in
parallel
to
corresponding
as
a
JSON
serializations.
object.
This
section
describes
how
The
type
definitions
described
using
of
the
type
system
can
fields
forms
,
required
,
and
enum
,
scopes
,
and
security
,
MUST
be
mapped
serialized
as
a
JSON
array.
A TD snippet based on the defined fields is given below:
{
...
"properties": { "on": { "label":
"hljs-string">"On/Off",
"type":
"hljs-string">"boolean",
"forms": [...]
},
"status": { "type":
"hljs-string">"object",
"properties": { "brightness": {
"hljs-string">"type": "number",
"hljs-string">"minimum": 0.0,
"hljs-string">"maximum": 100.0
},
"rgb": {
"hljs-string">"type": "array",
"items" : {
"hljs-string">"type" : "number",
"hljs-string">"minimum": 0,
"hljs-string">"maximum": 255
},
"hljs-string">"minItems": 3,
"hljs-string">"maxItems": 3
}
},
"hljs-string">"required": ["brightness", "rgb"],
"forms": [...]
}
}
...
}
Similar
to
XML
schema
definitions
the
case
at
the
Thing
level,
properties
MAY
have
additional
semantic
annotations
based
on
JSON-LD
1.1
keywords.
When
a
Thing
Description
instance
is
processed
and
interpreted
by
using
a
JSON-LD
1.1
processor,
each
property
MUST
contain
the
same
examples.
Given
these
type
definitions,
providing
vocabulary
terms
observable
and
writable
due
to
the
mapping
open-world
assumption
of
Linked
Data.
This
assumption
means
that
if
a
Linked
Data
model
of
a
Thing
Description
instance
were
to
XML
schema
allows
XML
tools
omit
these
vocabulary
terms,
then
the
interpreter
would
not
be
able
to
directly
validate
serialized
XML
data,
for
example.
The
XML
structure
for
which
this
mapping
is
designed
is
make
any
assumptions
about
their
actual
value.
A
snippet
of
a
JSON-LD
1.1
processable
TD
serialization
including
semantic
annotations
and
the
default
values
of
observable
and
writable
based
on
EXI4JSON
[
the
class
exi-for-json
Property
].
is
given
as
follows:
..."properties": { "on": { "@type":
"hljs-string">"iot:SwitchToggle",
"label":
"hljs-string">"On/Off",
"writable":
"hljs-literal">false,
"observable":
"hljs-literal">false,
"type":
"hljs-string">"boolean",
"forms": [...]
},
"status": { "writable":
"hljs-literal">false,
"observable":
"hljs-literal">false,
"type":
"hljs-string">"object",
"properties": { "brightness": {
"hljs-string">"@type": "iot:CurrentLevel",
"hljs-string">"type": "number",
"hljs-string">"minimum": 0.0,
"hljs-string">"maximum": 100.0
},
"rgb": {
"hljs-string">"@type": "iot:rgbData",
"hljs-string">"type": "array",
"items" : {
"hljs-string">"type" : "number",
"hljs-string">"minimum": 0,
"hljs-string">"maximum": 255
},
"hljs-string">"minItems": 3,
"hljs-string">"maxItems": 3
}
},
"required": [
"hljs-string">"brightness","rgb"],
"forms": [...]
}
}
...
actions
Shown
below
is
Actions
offered
by
a
Thing
MUST
be
collected
in
the
type
system
JSON-object
based
object
actions
definition
given
for
field
with
(unique)
Action
names
as
JSON
keys.
inputSchema
Action
object
InteractionPattern
The
type
of
two
named
literals
the
fields
id
input
(of
type
and
MUST
be
serialized
as
a
JSON
object.
integer
output
The
keys
of
input
)
and
name
output
(of
type
rely
on
the
the
class
string
DataSchema
)
where
.
The
type
of
the
fields
,id
forms
scopes
,
and
security
is
required
to
MUST
be
present.
serialized
as
a
JSON
array.
A TD snippet based on the defined fields is given below:
...
"actions": {
"fade" {
"label": "hljs-string">"Fade in/out",
"hljs-string">"description": "Smooth fade in and out animation.",
"input": { "type": "object",
: [
{
: "id",
: {
: "integer"
}
"properties": {
"from": {
"hljs-string">"type": "integer",
"hljs-string">"minimum": 0,
"hljs-string">"maximum": 100
},
"to": {
"hljs-string">"type": "integer",
"hljs-string">"minimum": 0,
"hljs-string">"maximum": 100
},
"hljs-string">"duration": {"type": "number"}
},
"hljs-string">"required": ["to","duration"],
},
{
: "name",
: {
: "string"
}
}
],
: ["id"]
"output": {"hljs-string">"type": "string"},
"forms": [...]
}
...
}
...
When
Definitions
within
the
object
actions
is
anonymous
(i.e.
it
is
field
MAY
have
additional
semantic
annotations
based
on
JSON-LD
1.1
keywords.
events
Events
offered
by
a
Thing
MUST
be
collected
in
the
root,
or
participates
JSON-object
based
events
field
with
(unique)
Event
names
as
JSON
keys.
Event
,
as
well
as
its
two
superclasses
InteractionPattern
and
DataSchema
,
MUST
be
serialized
as
a
JSON
key
within
an
Event
object.
The
type
of
the
fields
array
properties
definition),
and
items
MUST
be
serialized
as
a
JSON
object.
The
type
of
the
above
fields
,object
forms
required
,
and
enum
,
scopes
,
and
security
definition
transforms
to
MUST
be
serialized
as
a
JSON
array.
A
TD
snippet
based
on
the
following
XML
Schema
element
definition.
defined
fields
is
given
below:
...
"event": {
"overheated": {
"type": "hljs-string">"object",
"properties": {
"hljs-string">"temperature": { "type": "number" }
},
"forms": [...]
}
...
}
...
Otherwise
(i.e.
Definitions
within
the
object
events
is
a
member
of
another
field
MAY
have
additional
semantic
annotations
based
on
JSON-LD
1.1
keywords.
object
forms
Each
mandatory
and
optional
vocabulary
term
as
defined
in
the
class
object
Form
definition
transforms
to
the
following
XML
schema
element
definition.
Note
,
MUST
be
serialized
as
a
JSON
key.
If
required,
forms
MAY
be
supplemented
with
protocol-specific
vocabulary
terms
identified
with
a
prefix.
See
also
[
$name
WOT-PROTOCOL-BINDING
].
When
a
Thing
Description
instance
is
processed
and
interpreted
by
a
JSON-LD
1.1
processor,
each
forms
represents
(array)
entry
MUST
contain
a
mediaType
due
to
the
name
open-world
assumption
of
the
object
,
and
needs
Linked
Data.
This
assumption
means
that
if
a
Linked
Data
model
of
a
Thing
Description
instance
were
to
be
replaced
by
omit
these
vocabulary
terms,
then
the
interpreter
would
not
be
able
to
make
any
assumptions
about
their
actual
name
of
value.
A
TD
snippet
based
on
the
object
.
defined
fields
is
given
below:
...
"forms": [{
"href" : "hljs-string">"http://mytemp.example.com:5683/temp",
"mediaType":
"hljs-string">"application/json",
"hljs-string">"http:methodName": "POST",
"rel":
"hljs-string">"writeProperty",
"security": [{
"hljs-string">"scheme":"basic", "in":"header"}]
}]
...
links
Shown
below
is
Each
mandatory
and
optional
vocabulary
term
as
defined
in
the
type
system
class
array
Link
definition
,
MUST
be
serialized
as
a
JSON
key.
A
TD
snippet
based
on
the
defined
fields
is
given
for
below:
..."links": [{ "href":
"hljs-string">"https://servient.example.com/things/lampController",
"rel":
"hljs-string">"controlledBy",
"mediaType":
"hljs-string">"application/td+json"
}]
...
security
Each
mandatory
and
optional
vocabulary
term
as
defined
in
the
class
,
MUST
be
serialized
as
a
JSON
key.
inputSchema
SecurityScheme
The
following
TD
snippet
shows
a
simple
security
configuration
specifying
basic
username/password
authentication
in
Section
Array
.
the
header.
The
value
of
array
in
consists
given
is
actually
the
default
value
of
exactly
three
number
literals
header
.
..."security": [{ "scheme":
"hljs-string">"basic",
"in":
"hljs-string">"header"
}]
...
Here
is
a
more
complex
example:
a
TD
snippet
showing
digest
authentication
on
a
proxy
combined
with
each
value
within
bearer
token
authentication
on
an
endpoint.
Here
the
default
value
range
of
[
0
...
2047
].
in
in
the
digest
scheme,
header
,
is
implied.
...
"security": [
{
"scheme":
"hljs-string">"digest",
"proxyUrl":
"hljs-string">"https://portal.example.com/"
},
: 3,
: 3
}
{
"scheme":
"hljs-string">"bearer",
"format":
"hljs-string">"jwt",
"alg":
"hljs-string">"ES256",
"hljs-string">"authorizationUrl": "https://servient.example.com:8443/"
}
]
...
When
Security
definitions
can
be
given
at
more
than
one
level.
In
this
case,
definitions
at
the
lower
levels
override
(completely
replace)
the
definitions
at
the
higher
level.
Security
configuration
is
mandatory.
Every
form
in
a
Thing
MUST
have
a
security
configuration
either
provided
in
the
form
itself,
at
the
interaction
level
directly
above
it
(if
security
is
not
configured
in
the
form),
or
at
the
Thing
level
(if
security
is
not
configured
in
either
the
form
or
at
the
interaction
level).
In
the
vocabulary
defined
above,
note
that
is
array
security
anonymous
(i.e.
it
marked
as
non-mandatory.
However,
this
is
only
true
locally
(at
a
specific
level),
and
only
if
the
root,
security
is
configured
at
a
higher
or
participates
lower
level.
In
other
words,
a
security
configuration
must
be
provided
at
some
level
for
each
form.
Security
configuration
is
considered
binding.
The
security
configuration
metadata
provided
in
another
a
Thing
Description
MUST
accurately
reflect
the
security
requirements
of
the
Thing.
Some
protocols
can
ask
for
authentication
dynamically.
If
a
protocol
asks
for
a
form
of
security
credentials
not
declared
in
the
Thing
Description
then
the
Thing
Description
is
to
be
considered
invalid.
The
array
nosec
definition),
security
scheme
is
provided
for
the
case
that
no
security
is
needed.
The
minimal
security
configuration
for
a
Thing
is
configuration
of
the
above
array
nosec
definition
transforms
to
security
scheme
at
the
top
level,
as
in
the
following
XML
Schema
element
definition.
example:
{
"id": "hljs-string">"urn:dev:wot:com:example:servient:myThing",
"name":
"hljs-string">"MyThing",
"description":
"hljs-string">"Additional (human) readable information of the Thing.",
"support":
"hljs-string">"https://servient.example.com/contact",
"security": [{
"hljs-string">"scheme": "nosec"}],
"properties": {...}, "actions": {...}, "events": {...}, "links": [...]
}
Otherwise
(i.e.
To
give
a
more
complex
example,
suppose
we
have
a
Thing
where
all
interactions
require
basic
authentication
except
for
one
interaction
for
which
no
authentication
is
required.
In
the
following,
the
array
nosec
is
a
member
of
an
scheme
for
the
security
configuration
in
the
object
overheating
definition,
thus
has
a
name),
event
to
indicate
no
authentication
is
required.
For
the
array
status
definition
transforms
to
property
and
the
following
XML
schema
element
definition.
Note
toggle
action,
however,
basic
authentication
is
required
as
defined
at
the
top
level
of
the
Thing.
{
...
"security": [{
"hljs-string">"scheme": "basic"}],
"properties": { "status": {
...
"forms": [{
"hljs-string">"href": "https://mylamp.example.com/status",
"hljs-string">"mediaType": "application/json",
}]
}
},
"actions": { "toggle": {
...
"forms": [{
"hljs-string">"href": "https://mylamp.example.com/toggle",
"hljs-string">"mediaType": "application/json"
}]
}
},
"events": { "overheating": {
...
"forms": [{
"hljs-string">"href": "https://mylamp.example.com/oh",
"hljs-string">"mediaType": "application/json",
"hljs-string">"security": [{"scheme": "nosec"}]
}]
}
}
}
Security
definitions
can
also
can
be
given
for
different
elements
at
the
name
same
level.
This
may
be
required
for
devices
that
support
multiple
protocols,
for
example
CoAP
and
HTTP,
with
support
for
different
security
mechanisms.
This
is
also
useful
when
alternative
authentication
mechanisms
are
allowed.
Here
is
a
TD
snippet
demonstrating
three
possible
ways
to
access
a
resource:
via
HTTPS
with
basic
authentication,
via
HTTPS
via
digest
authentication,
or
via
CoAPS
with
an
API
key.
In
other
words,
the
use
of
multiple
security
configurations
at
the
same
level
provides
a
way
to
combine
security
mechanisms
an
in
"OR"
fashion.
In
contrast,
putting
multiple
security
configurations
in
the
same
field
combines
them
in
an
"AND"
fashion,
since
in
that
case
they
would
all
need
to
be
array
,
and
needs
security
replaced
by
satisfied
to
allow
access
to
the
actual
name
resource.
..."properties": { "status": {
...
"forms": [
{
"hljs-string">"href": "https://mylamp.example.com/status",
"hljs-string">"mediaType": "application/json",
"hljs-string">"security": [{"scheme": "basic"}]
},
{
"hljs-string">"href": "https://mylamp.example.com/status",
"hljs-string">"mediaType": "application/json",
"hljs-string">"security": [{"scheme": "digest"}]
},
{
"hljs-string">"href": "coaps://mylamp.example.com:5683/status",
"hljs-string">"mediaType": "application/json",
"hljs-string">"security": [{"scheme": "apikey"}]
}
]
}
},
...
The
JSON-based
serialization
of
the
TD
is
identified
by
the
media
type
[
MEDIATYPES
]
.
array
application/td+json
CoAP-based
WoT
implementations
can
use
the
experimental
Content-Format
65100
until
a
proper
identifier
has
been
registered.
The
media
type
application/td+json
MUST
be
also
associated
with
the
JSON-LD
context
http://www.w3.org/ns/td
.
>
That
means
that
this
media
type
can
also
be
used
for
contextual
identification
of
the
vocabulary
within
a
(simplified)
TD
instance
that
may
omit
the
@context
key
term.
Neither
the
application/td+json
media
type
nor
a
CoAP
Content-Format
identifier
have
been
registered
with
IANA
yet.
To
parse
The
minimum
requirement
to
read
the
content
of
a
valid
Thing
Description
instance
is
a
simple
JSON-based
parser
and
tools
can
(simple)
JSON
parser.
If
the
key
terms
writable
and/or
observable
are
not
present
within
a
properties
definition,
the
default
value
defined
in
5.
Information
Model
MUST
be
used
to
retrieve
assumed.
If
the
content.
mediaType
key
term
is
not
present
within
a
forms
definition,
the
default
value
as
defined
in
5.
Information
Model
MUST
be
assumed.
To
validate
the
semantic
meaning
and
follow
references
to
external
context
vocabulary,
vocabulary
terms
(e.g.,
iot.schema.org),
use
of
JSON-LD
or
RDF-based
parsing
tools
and
libraries
are
is
highly
recommended.
recommended
as
explained
in
the
next
sub-section.
In
To
interpret
the
following,
we
give
examples
semantic
meaning
of
full
TDs.
The
first
one,
a
temperature
sensor,
shows
how
to
define
relations
between
Thing
Properties.
As
a
second
example,
we
modeled
an
actuator
(LED
lamp)
where
Actions
have
all
been
characterized
semantically,
so
that
machines
could
unambiguously
interpret
them
Description
in
an
automated
manner.
At
last,
association
between
Things
is
shown
by
defining
terms
of
RDF
triples,
a
master
switch
controlling
other
LED
lamps.
Thing
Description
instance
first
requires
a
valid
JSON-LD
1.1
representation
based
on
this
Thing
Description
specification.
Then
this
representation
can
be
passed
to
a
JSON-LD
1.1
processor.
The following pre-processing steps of a Thing Description instance must be executed before starting JSON-LD 1.1 processing:
myTempSensor
defines
two
Properties:
myTemp
@context
reference
@context
Section
1.
Introduction
shows
an
external
agent
example
of
how
the
input
and
output
of
such
preprocessing
would
not
have
sufficient
information
to
interpret
it.
appear.
{
: ["https://w3c.github.io/wot/w3c-wot-td-context.jsonld",
"https://w3c.github.io/wot/w3c-wot-common-context.jsonld"],
: ["Lamp"],
: "myMasterLED",
: [
{
: ["Action", "Toggle"],
: "myMasterOnOff",
: {
: ["OnOff"],
: "boolean"
},
: [
{
: "coap://www.example.com:5683/master",
: "application/json"
},
{
: "http://www.example.com:80/master",
: "application/json"
"id": "hljs-string">"urn:dev:wot:com:example:servient:lamp",
"name":
"hljs-string">"MyLampThing",
"description" :
"hljs-string">"MyLampThing uses JSON-LD 1.1 serialization",
"security": [{
"hljs-attr">"scheme": "psk"}],
"properties": { "status": {
"hljs-attr">"description" : "Shows the current status of the lamp",
"type":
"hljs-string">"string",
"forms": [{ "href":
"hljs-string">"coaps://mylamp.example.com/status"
}]
}
},
"actions": { "toggle": {
"hljs-attr">"description" : "Turn on or off the lamp",
"forms": [{ "href":
"hljs-string">"coaps://mylamp.example.com/toggle"
}]
}
},
"events": { "overheating": {
"hljs-attr">"description" : "Lamp reaches a critical temperature (overheating)",
"type":
"hljs-string">"string",
"forms": [{ "href":
"hljs-string">"coaps://mylamp.example.com/oh"
}]
}
]
}
]
}
{
"@context": ["hljs-string">"http://www.w3.org/ns/td",
{"iot": "http://iotschema.org/"}],
"@type" :
"hljs-string">"Thing",
"id":
"hljs-string">"urn:dev:wot:com:example:servient:lamp",
"name":
"hljs-string">"MyLampThing",
"description" :
"hljs-string">"MyLampThing uses JSON-LD 1.1 serialization",
"security": [{
"hljs-attr">"scheme": "psk"}],
"properties": { "status": { "@type" :
"hljs-string">"iot:SwitchStatus",
"hljs-attr">"description" : "Shows the current status of the lamp",
"writable":
"hljs-literal">false,
"hljs-attr">"observable": false,
"type":
"hljs-string">"string",
"forms": [{ "href":
"hljs-string">"coaps://mylamp.example.com/status",
"hljs-attr">"mediaType": "application/json"
}]
}
},
"actions": { "toggle": { "@type" :
"hljs-string">"iot:SwitchStatus",
"hljs-attr">"description" : "Turn on or off the lamp",
"forms": [{ "href":
"hljs-string">"coaps://mylamp.example.com/toggle",
"hljs-attr">"mediaType": "application/json"
}]
}
},
"events": { "overheating": { "@type" :
"hljs-string">"iot:TemperatureAlarm",
"hljs-attr">"description" : "Lamp reaches a critical temperature (overheating)",
"type":
"hljs-string">"string",
"forms": [{ "href":
"hljs-string">"coaps://mylamp.example.com/oh",
"hljs-attr">"mediaType": "application/json"
}]
}
}
}
Please see the WoT Security and Privacy repository for work in progress regarding threat models, assets, risks, recommended mitigations, and best practices for security and privacy for systems using the Web of Things. Once complete, security and privacy considerations relevant to Thing Descriptions will be summarized in this section.
This schema is known to be too permissive. This issue will be resolved in the next release of this document.
{ "title": "WoT TD Schema for Bundang Plug Fest", "description": "JSON Schema representation of the TD serialization format.", "$schema ": "http://json-schema.org/draft-06/schema#", "type": "object", "properties": { "base": { "$ref": "#/definitions/url" }, "@type": { "$ref": "#/definitions/type_declaration" }, "@context": { "$ref": "#/definitions/context" }, "name": { "type": "string" }, "id": { "type": "string" }, "description": { "type": "string" }, "properties": { "type": "object", "items": { "$ref": "#/definitions/properties" } }, "actions": { "type": "object", "items": { "$ref": "#/definitions/actions" } }, "events": { "type": "object", "items": { "$ref": "#/definitions/events" } }, "links": { "type": "array", "items": { "$ref": "#/definitions/links" } }, "support": { "type": "string" }, "security": { "type": "array", "items": { "$ref": "#/definitions/securityScheme" } } }, "required": [ "name", "id" ], "additionalProperties": true, "definitions": { "context": { "oneOf": [ { "type": "array", "items": { "anyOf": [ { "$ref": "#/definitions/url" }, { "type": "object" } ] }, "contains": { "type": "string", "enum": [ "https://w3c.github.io/wot-thing-description/context/td-context.jsonld", "http://www.w3.org/ns/td" ] } }, { "type": "string", "enum": [ "https://w3c.github.io/wot-thing-description/context/td-context.jsonld", "http://www.w3.org/ns/td" ] } ] }, "type_declaration": { "oneOf": [ { "type": "string" }, { "type": "array" } ] }, "form_declaration": { "type": "array", "items": { "$ref": "#/definitions/form_element" } }, "form_element": { "type": "object", "properties": { "href": { "$ref": "#/definitions/url" }, "rel": { "type": "string" }, "mediaType": { "type": "string" }, "subProtocol": { "type": "string" }, "security": { "type": "array", "items": { "$ref": "#/definitions/securityScheme" } }, "scopes": { "type": "array", "items": { "type": "string" } } }, "required": [ "href" ], "additionalProperties": true }, "properties": { "additionalProperties": { "type": "object", "items": { "$ref": "#/definitions/property_element" } } }, "actions": { "additionalProperties": { "type": "object", "items": { "$ref": "#/definitions/action_element" } } }, "events": { "additionalProperties": { "type": "object", "items": { "$ref": "#/definitions/event_element" } } }, "property_element": { "type": "object", "properties": { "description": { "type": "string" }, "@type": { "$ref": "#/definitions/type_declaration" }, "label": { "type": "string" }, "writable": { "type": "boolean" }, "observable": { "type": "boolean" }, "forms": { "$ref": "#/definitions/form_declaration" }, "security": { "type": "array", "items": { "$ref": "#/definitions/securityScheme" } }, "scopes": { "type": "array", "items": { "type": "string" } } }, "required": [], "additionalProperties": true }, "action_element": { "type": "object", "properties": { "description": { "type": "string" }, "@type": { "$ref": "#/definitions/type_declaration" }, "label": { "type": "string" }, "forms": { "$ref": "#/definitions/form_declaration" }, "input": { "$ref": "#/definitions/data" }, "output": { "$ref": "#/definitions/data" }, "security": { "type": "array", "items": { "$ref": "#/definitions/securityScheme" } }, "scopes": { "type": "array", "items": { "type": "string" } } }, "required": [], "additionalProperties": true }, "event_element": { "type": "object", "properties": { "description": { "type": "string" }, "@type": { "$ref": "#/definitions/type_declaration" }, "label": { "type": "string" }, "forms": { "$ref": "#/definitions/form_declaration" }, "security": { "type": "array", "items": { "$ref": "#/definitions/securityScheme" } }, "scopes": { "type": "array", "items": { "type": "string" } } }, "required": [], "additionalProperties": true }, "links": { "type": "object", "properties": { "anchor": { "$ref": "#/definitions/url" }, "href": { "$ref": "#/definitions/url" }, "rel": { "type": "string" }, "mediatype": { "type": "string" } }, "required": [ "href" ], "additionalProperties": true }, "securityScheme": { "type": "object" }, "url": { "type": "string", "format": "uri", "pattern": "(([^:/?#]+):)?(//([^/?#]*))?([^?#]*)(([^#]*))?(#(.*))?" }, "jsonld_url": { "type": "string", "format": "uri", "pattern": "http://[^/?#]*|https://[^/?#]*" }, "data": { "title": "Data type", "anyOf": [ { "description": "URI of an XSD built-in type", "type": "string" }, { "description": "URI and media type for a complex type (XSD, SenML...)", "type": "object", "properties": { "name": { "type": "string" }, "href": { "type": "string" }, "mediatype": { "type": "string" } }, "required": [ "name", "href", "mediatype" ] }, { "$ref": "http://json-schema.org/draft-06/schema#" } ] }, "dataSchema": { "type": "object", "properties": { "description": { "type": "string" }, "enum": { "type": "array", "items": { "anyOf": [ { "type": "string" }, { "type": "boolean" }, { "type": "object" }, { "type": "number" }, { "type": "array" } ] } }, "type": { "type": "string", "enum": [ "string", "boolean", "object", "number", "array" ] } } } } }
@context
and
@type
for
facilitating
semantic
evaluation
of
TDs.
(see
Section
6.1
Representation
Format
)
form
.
writable
,
observable
,
mediaType
)
now
id
for
uniquely
identifying
a
Thing,
and
an
optional
field
support
to
provide
information
about
Thing
Description
maintainer.
label
field
providing
text
for
such
uses
as
user
interfaces.
rel
attribute
for
form
now
has
enumerated
allowable
values
specified.
http://www.w3.org/ns/td
.
Changes from First Public Working Draft are described in the Second Public Working Draft
This
document
contains
a
significant
contribution
from
Web
of
Things
members:
...
The
editors
would
like
to
thank
Dave
Raggett,
Matthias
Kovatsch,
Michael
McCool,
Michael
Koster,
Victor
Charpenay,
Kawaguchi
Toru,
Michael
Lagally,
Kazuyuki
Ashimura,
María
Poveda,
Daniel
Peintner,
Ben
Francis
for
their
contributions,
comments,
and
guidance.


Generic Fuzzing in URLs
Typically occurs is GET requests
Methodology:
Identify variables/injection points
Fuzz with known string
Filter for known string and note changes
Adapt and Overcome
Identify
To fuzz for a XSS vulnerability in a remote file, one has to look for every single variable that the site uses in GET requests for user-input. In other words, we're looking for any of the following two in URLs:
?[variable]=[value]
or
&[variable]=[value]
The values to the variables are the important parts.
Fuzz with known string
This time, to scan for XSS, lets reset every [value] for every [variable] to "AAAaaabbCCddD".
Search for the string AAAaaabbCCddD, because no one will randomly have that in their source code. If its there, modify the value from AAAaaabbCCddD to:
">'"();><
or
'';!--"<CSS_Check>=&{()}
and determine how many of these characters make it through.
Note changes
Due to filtering, sometimes these characters (used during attacks) are stripped to their HTML counterparts.
If the following signs appear in the affected area of code, one knows that HTML tags can slip through the filter:
< >
If these following characters slip through, attributes to the tags can be assigned:
' "
If any of these characters slip through, we know that JavaScript injection is possible:
() ;
Just scan the ENTIRE site, every single possible request variable and value for a vulnerability, and usually, in less than one hour, you're in.
Adapt and overcome
Scripting tags that are most often used to embed malicious content include
http://trusted.org/search.cgi?val=
http://trusted.org/COM2.IMG%20src= "Javascript:alert(document.domain)"
Forced Error Responses
http://trusted.org/
This insertion facet usually occurs due to poor error handling by the web server or application component. The application fails to find the requested page and reports an error which unfortunately includes the unprocessed script data.
http://trusted.org/search.cgi?blahblahblahblahblah
If a Java application such as a servlet fails to handle an error gracefully, and allows stack traces to be sent to the users browser, an attacker can construct a URL that will throw an exception and add his malicious script to the end of the request.
http://trusted.og/servlet/ org.apache.catalina.servlets.WebdavStatus/
In the example above, when the Tomcat servlet is called with the training illegitimate request, an error page is served containing the offending text verbatim.
Non

click-me
Scripts which are vulnerable to POST insertion are only slightly more difficult to attack. Since POST variables are transmitted independently of the request URI an intermediary page must be used. The goal of the intermediary page is to force the client to execute a POST request containing the jump code. The code below creates a form with the attacker controlled variables set, and then submits it on behalf of the user:
<form name=f method=POST action=”http://host/hello.php”>
<input type=hidden name=”name”
value=””>
</form>


Extinguish
May 17th, 2009
Forever realized by nothing but ash and electricity,
water and sunlight and my paper
ground of being
rest in certainty
Dead and be buried,
or grown into something different
Evermore bloodless residue
colorless and non-human
odorless, spiritless and blanched
baked bleach and snow-blindness bright
broken down crushed into vapor
Respire something, take a breath
suddenly and on one's own accord
tend to the fire that puts forth the light
so we can see and be warm
Did the wind you meet?
Did you catch a storm on a ship at sea?
Lean into my ear, you can speak to me
If you need, I will orate for you;
lay shadows behind me if you are the light I see-
Would be lost but I find you
would be but are saved.
would have been willed to be destroyed
But god did not smile, you did
I betray only myself now
the birds do not move any more
they flap their wings,
caught immobile in a breeze
Time and space be and so be caught up
twisted and bent out of line
alone by the sun, by the water the moon
let alone by you and by me.
did our frames not cascade?
did our metaphors coincide?
I am here to see the sun with you
the moon can be our child
the stars can be
our eyes
other matters far out of reach
yet they reach to me
and they signify you
-here on this planet
I will find you
when the sun rises and the moon sets
when the stars are right
aligned to the ash in me
the ground at my feet was spinning before it even coalesced
-from whence it was dust
there we were, there we met
Here we have always been
How you left me soft spoken
In a valley with a gossamer mist
that was pain to me
my deepest fear is that it will pain forever you too
the rain began falling to bring in the night
extinguish the fire the warmth and the light


Ensure to keep in mind local traffic as the location is a popular place for people to be
Taken at 9:00 am with natural light and standard tripod


Thanks
We’ve received your information and we will be in touch when research relevant to you is happening.
You can choose to leave the research panel at any time by going to gov.uk/research-panel.
We’ve received your information and we will be in touch when research relevant to you is happening.
You can choose to leave the research panel at any time by going to gov.uk/research-panel.


When: PM, Sunday, September 16, 2018
Where: MICCAI 2018 @ Granada, Spain, Saray Hotel, Mocarabes Salon 6
The objective of this tutorial is to introduce the MICCAI community to the new kinds of DICOM objects and capabilities that can be used for storage and communication of the data typically produced in the process of quantitative image analysis (such as image segmentation results, measurements, radiomics features, parametric maps).
Over the course of presentations and hands-on sessions, we explain how DICOM can, and we believe should, be used for storing your processing results such as segmentations, parametric maps and volumetric measurements.
After completing this tutorial, attendees are expected to develop an understanding of the relevant new and long-established capabilities of the DICOM standard, as well as some of the tools that they can use to experiment with adoption of the standard in their everyday research.
This talk will introduce the main concepts of the DICOM standard, the role it plays in the modern healthcare enterprise, its overall purpose and capabilities.
This talk will discuss the relevance of the DICOM standard in quantitative imaging research, motivate its use and discuss specific capabilities as applied to the storage of common image analysis outputs, such as image segmentation results, parametric maps and region-based quantitative measurements.
An overview, capabilities and summary of experience with the various data management platforms that can work with the DICOM data for medical image computing applications. Some of the tools we plan to cover will include XNAT and dcm4chee.
Attendees will be guided over the steps of installing the free open source software tools that will be used in the tutorial, and which can help the attendees work with the DICOM data in their everyday work after the conference. The tools utilized in the tutorial will include 3D Slicer, MITK, DCMTK, Atom, and dcmqi. We will also distribute the sample dataset that will be used in the tutorial.
Closer to the event we will provide instructions on how to install the prerequisites for your platform in advance of the tutorial!In this hands-on exercise attendees will use one or more open source tools (3D Slicer, MITK, dcmqi) to load DICOM data, segment regions of interest, and extract radiomics features. The results will be stored using standard (no private attributes) DICOM objects. The resulting standard-compliant data storage will be contrasted with the alternative approaches used in the community.
In this session we will go over the steps of extracting various data attributes (both in the source images, and in the research results stored in DICOM representation) from the standard DICOM representations of the analysis results, generating summary visualizations and preparing representations (e.g., CSV spreadsheets) suitable for the analysis by non-DICOM-enabled tools.
Radiologist, medical informaticist, DICOM open source software author and editor of the DICOM standard. Formerly the co-chair of the IHE Radiology Technical Committee and industry co-chairman of the DICOM Standards Committee.
Assistant Professor in Radiology at the Brigham and Women's Hospital Department of Radiology, and Harvard Medical School. Together with Ron Kikinis, Andrey is a co-PI of the Quantitative Image Informatics for Cancer Research project.
Medical Imaging Interaction Toolkit (MITK) team lead at the German Cancer Research Center. His work focuses on research enabling technologies, interoperability, open source and application-oriented research in radiology, surgery and radiation oncology.
DICOM4MICCAI tutorial first took place during MICCAI 2017 in beautiful Quebec City, Canada.
If interested, we welcome you to check out the archived event page from DICOM4MICCAI 2017 that includes downloadable slides, pointers to the related tools, and hands-on materials presented at that event.


Hello, My name is DAVID ELLIS, a nationality of United Kingdom,I have been diagnosed with Esophageal cancer. It has defied all forms of medical treatment, and right now I have only about a few months to live, according to medical experts.I have not particularly lived my life so well, as I never really cared for anyone(not even myself)but my business. Though I am very rich, I was never generous, I was always hostile to people and only focused on my business as that was the only thing I cared for. But now I regret all this as I now know that there is more to life than just wanting to have or make all the money in the world.I believe when God gives me a second chance to come to this world I would live my life a different way from how I have lived it. Now that God has called me, I have willed and given most of my property and assets to my immediate and extended family members as well as a few close friends.I want God to be merciful to me and accept my soul so, I have decided to give alms to charity organizations, as I want this to be one of the last good deeds I do on earth. So far, I have distributed money to some charity organizations in the U.A.E, Somalia and Malaysia. Now that my health has deteriorated so badly, I cannot do this myself anymore. I once asked members of my family to close one of my accounts and distribute the money which I have there to charity organization in Bulgaria and Rwanda, they refused and kept the money to themselves. Hence, I do not trust them anymore, as they seem not to be contended with what I have left for them. The last of my money which no one knows of is the huge cash deposit of Twenty Eight Million USD that I have with a finance/Security Company abroad. I will want you to help me collect this deposit and despatch it to charity organizations. I have set aside 20% for you and for your time. Please reply to my personal e.mail address<EMAIL_ADDRESS>God be with you. DAVID ELLIS


Back to Index
OAuth Flow
Login or Link
Login
Link
Popup or Redirect
Popup
Redirect
On User Duplicate
Abort
Merge
Create
Provider ID
Submit
Synopsis
Result
Access Token Flow
Login or Link
Login
Link
On User Duplicate
Abort
Merge
Create
Provider ID
Access Token
Access Token Flow is disabled by default. You have to enable it first.
Submit
Synopsis
Result
Delete OAuth Provider
Provider ID
Submit
Synopsis
Result


Open debugger and set model.firstname="[some value]" to see input value change from code.
Hello ${firstname}
Hello ${firstname}
First Name:


Profile Completeness:
40%
First Name
Last Name
Birthday
Gender
Male
Female
Rather not say
Occupation


Hi,
because of other attached equipment I need to power my Pi vi GPIO Pins (5V/GND).
Is this possible?
The RFM12Pi sits over the 5V pin, but isn't used, or?
Thanks for help
giovanne
Archived Forum |
|
Using RFM12Pi V2 and also Power over GPIO possible?Submitted by giovanne on Wed, 14/01/2015 - 18:57Hi, because of other attached equipment I need to power my Pi vi GPIO Pins (5V/GND). Is this possible? The RFM12Pi sits over the 5V pin, but isn't used, or?
Thanks for help giovanne » |
Re: Using RFM12Pi V2 and also Power over GPIO possible?
Don't use 5V on the RFM2Pi because that will kill the radio module, it is a strictly 3.3V device;
Powering the Raspberry Pi from GPIOs may be risky, but possible: see http://www.raspberrypi.org/forums/viewtopic.php?f=44&t=10500
Re: Using RFM12Pi V2 and also Power over GPIO possible?
Hi,
I met a similar problem when trying to connect a LCD screen to my Pi (equipped with a RFM12Pi).
I used the P5 header which is a secondary GPIO port. You will have to do some soldering. In my case, I soldered a right-angled male header on top of the board. Sorry, no photo, but everything goes in a standard case.
Eric
EDIT : the P5 header is only available on the Model B Rev2
Re: Using RFM12Pi V2 and also Power over GPIO possible?
Hi Martin,
I don't want to use 5V for the RFM12Pi. The RFM12Pi will be used as it is.
But I want to power my Pi from GPIO. Already done on one Pi system.
Now I want to power my Pi from GPIO and also use the RFM12Pi on the same Pi.
Because the RFM12Pi sits over the 5V Pin2, my question is, if the 5V Pin is used from the RFM12Pi Board? I think not.
If it is so I can connect mit power supply like I have already done to the GPIO Pin2 and that has no effect to the RFM12Pi Board.
Am I right?
Thanks
giovanne
Re: Using RFM12Pi V2 and also Power over GPIO possible?
OK - I have tested it. Like on the schematic on http://wiki.openenergymonitor.org/index.php?title=RFM12Pi_V2 the corresponding 5V Pins on the RFM12Pi Pin 1+3 aren't used.
I have connected my power supply there and everything ist working.
Pi is powered vi GPIO for the hyperion ambilight setup.
And parallel the Pi is getting / sending data over RFM12Pi ;-)
[Please do not double-post. If your comment has been held for moderation, please wait until it is attended to.]


NEO is a cryptocurrency project that was launched in 2016 in China as a rival to Ethereum offering similar functional features under the name of Ant Shares and nicknamed Chinese Ethereum and Ethereum Killer. In 2017, the project was rebranded and the coin was named NEO. The total supply for the issuance of NEO is 100 million coins.
In essence, NEO is a digital, decentralized ledger network with smart contracts and a platform for decentralized applications based on the proof-of-stake consensus. Using the NEO blockchain, its users can make digital assets out physical ones through smart contracts, i. e. tokenize them, develop Dapps and stake NEO coins for passive income generated in GAS – another cryptocurrency distributed as a block reward in the NEO blockchain.
The reward for new NEO blocks in 2019 is 8 GAS, the blocks are generated every 15 – 20 seconds and the limit for the emission of GAS constitutes 100 million coins as well as for NEO. Every year, the block reward decreases in order to provide upkeep for the price of GAS and make the rewarding process last longer. The suggested term at the end of which the GAS issuance stops is 22 years.
GAS and NEO are different cryptocurrencies that go in tandem. NEO is a platform that acts as an all-round crypto-financial platform combining smart contracts, tokenization of assets, Dapps and the digital identity. GAS is a cryptocurrency that is given to NEO owners as a reward for their stake in NEO.
In order to receive a passive income from NEO, firstly, you will need to get some NEO (the simplest way to do that would be to buy it on a cryptocurrency exchange). Secondly, you will need to install a NEO-compatible wallet. We suggest using a cold atomic wallet for security.
Thirdly, install the Neon wallet to your computer for GAS. Because it is the only wallet that can receive GAS. But it will act fully automatically once you complete the installation process and sync the two wallets.
To receive the GAS reward for staking your NEOs, use Atomic Wallet. It supports all major cryptocurrencies and over 500 tokens, it provides anonymity to its owner and it works on a decentralized network. Also, a huge plus of using the Atomic Wallet is that you will not have the need to use the Neon wallet, which is otherwise necessary for generation and storage of GAS. In order to download the Atomic Wallet proceed to https://atomicwallet.io.
After you install the Atomic Wallet you will need to transfer your NEOs to a NEO account in it the address for which will be generated automatically. As with most cryptocurrency wallets, it will be your obligation to keep secure your private key to the wallet because if you lose it you will lose access to your wallets and funds in it forever.
The GAS reward will be generated after you top up your NEO wallet. The amount of time will depend on how much NEO you stake. In order to withdraw the generated GAS, you will simply need to send NEO to yourself with zero fees and GAS will be automatically claimed.
Thereupon, you can spend it on a cryptocurrency exchange where GAS is listed and convert it into a fiat currency or a different cryptocurrency. You can convert it into NEO, too, to top up your NEO account and grow the passive earnings in GAS.


Match Play. Red leads 3-2 to 7. How should Red play 33?
pips Red=158 White=170
(CorrectAnswer= 0/0, ErrorScore= 0)
This is a difficult problem.
Over the board I played 11/8, 10/7(3) which turned to be nearly a double blunder.
11/2*, 5/2 wins more gammons than any other play but leaves a somewhat disjointed position and White has an anchor so he cannot be blitzed. The extra gammons don’t compensate for the lower percentage of games won.
Red is ahead in the race, so he should bear that in mind. White also has three rear checkers so a priming play looks logical. Combining these ideas, we find 24/21(2), 10/7(2).
Now Red has an advanced anchor so he doesn’t have to worry about the blots he has left (and to a certain extent this play will help protect his racing lead as he won’t lose that many gammons), he has progressed in the race by moving his rear checkers and he has a solid prime in front of White’s three rear checkers - mission accomplished!
I don’t think many would get this problem right over the board and even in the calm of one’s study it is none too easy. Difficult problems like this help us to understand the complexities of the game and accelerate our learning.
Any play other than 24/21(2), 10/7(2) is at least an error. Even for money 24/21(2), 10/7(2)
Is correct.
Over the board I played 11/8, 10/7(3) which turned to be nearly a double blunder.
11/2*, 5/2 wins more gammons than any other play but leaves a somewhat disjointed position and White has an anchor so he cannot be blitzed. The extra gammons don’t compensate for the lower percentage of games won.
Red is ahead in the race, so he should bear that in mind. White also has three rear checkers so a priming play looks logical. Combining these ideas, we find 24/21(2), 10/7(2).
Now Red has an advanced anchor so he doesn’t have to worry about the blots he has left (and to a certain extent this play will help protect his racing lead as he won’t lose that many gammons), he has progressed in the race by moving his rear checkers and he has a solid prime in front of White’s three rear checkers - mission accomplished!
I don’t think many would get this problem right over the board and even in the calm of one’s study it is none too easy. Difficult problems like this help us to understand the complexities of the game and accelerate our learning.
Any play other than 24/21(2), 10/7(2) is at least an error. Even for money 24/21(2), 10/7(2)
Is correct.
1. Cubeful 2-ply 24/21(2) 10/7(2) Eq.: +0.656 0.651 0.253 0.024 - 0.349 0.091 0.004 2. Cubeful 2-ply 11/2* 5/2 Eq.: +0.607 (-0.048) 0.625 0.301 0.040 - 0.375 0.090 0.005 3. Cubeful 2-ply 11/8 10/7(3) Eq.: +0.552 (-0.103) 0.619 0.255 0.027 - 0.381 0.104 0.007 4. Cubeful 2-ply 24/21 8/2* 5/2 Eq.: +0.519 (-0.137) 0.605 0.294 0.039 - 0.395 0.113 0.009 5. Cubeful 2-ply 8/2*(2) Eq.: +0.507 (-0.148) 0.596 0.290 0.038 - 0.404 0.105 0.006


RT @recompilermag: Issue 0 of The Recompiler is online now! http://recompilermag.com/issues/issue-0/ Four articles about tech, teaching, learning, and histor…
6/17/2015, 11:06:51 PM
Favs: 0
Retweets: 0
link--- layout: tweet ---
RT @recompilermag: Issue 0 of The Recompiler is online now! http://recompilermag.com/issues/issue-0/ Four articles about tech, teaching, learning, and histor…
6/17/2015, 11:06:51 PM
Favs: 0
Retweets: 0
link


I am an isotope geochemist who seeks to understand the co-evolution of interlinked cryospheric, geologic, biologic, and oceanographic systems. My research centers on the the application of geochemical tools to extend our record of Antarctic Ice Sheet change into the recent geologic past using presently ice covered archives.
I am currently (beginning February, 2021) a postdoctoral fellow at Tulane University working to understand the recent history of the Thwaites-Pine Island glacier system as part of the International Thwaites Glacier Collaboration. I recently completed my Ph.D. at the University of South Florida (January, 2021) where I worked to reconstruct Holocene grounding line history in the southern Ross Sea Embayment as part of the
Subglacial Antarctic Lakes Scientific Access (SALSA) Project.
Click the buttons below to get in contact via email and twitter, or keep scrolling to learn more about what I'm currently working on!


Victor Litzau
About
Portfolio
Contact
Portfolio
Hover Over Projects to see Development Technologies
Click Project To See The Technologies Page
Voting App
Developed using MERN: MongoDB, Express, React, Node.js. Plus: Passport, React-Router-Dom, Axios, Material-UI
Budgeting App
Developed with Node js, Sequelize, Passport, Express,handlebarsjs, Axios, Chart.js, dotenv, MySql, Api routes Click to see project tech page
Devour Burgers App
Developed with Node.js, MVC, ORM, MYSQL, EXPRESS, and Express-Handlebars Click to see project tech page
Movie Search
Collaboration Project: Developed using Bulma.io, jQuery, Javascript, HTML, CSS, and API queries Click to see project tech page
Weather Dashboard
Developed using Bootstrap, jQuery, Javascript, HTML, CSS, and Server side API calls Click to see project tech page
Work Day Scheduler
Developed using Bootstrap, Javascript, HTML, CSS, jQuery, moment.js, and local storage Click to see project tech page


@color-infographic-red-lightest;
@color-infographic-red-light;
@color-infographic-red;
@color-infographic-red-interaction;
@color-infographic-green-lightest;
@color-infographic-green-light;
@color-infographic-green;
@color-infographic-green-interaction;
@color-infographic-blue-lightest;
@color-infographic-blue-light;
@color-infographic-blue;
@color-infographic-blue-interaction;
@color-infographic-orange-lightest;
@color-infographic-orange-light;
@color-infographic-orange;
@color-infographic-orange-interaction;
@color-infographic-purple-lightest;
@color-infographic-purple-light;
@color-infographic-purple;
@color-infographic-purple-interaction;
@color-infographic-gray-lightest;
@color-infographic-gray-light;
@color-infographic-gray;
@color-infographic-gray-interaction;


Learn about the policy proposals relevant to your community, express your views by voting or commenting on issues, and get the word out by sharing your views with your friends. Be heard by your elected officials and be engaged in civic discourse.
Post policy proposals and get real-time feedback from your constituents. Get breakdowns and analytics about constituent views. Display your platform on your public profile to get your message out. Reach out to and engage with potential supporters.
Raise awareness and mobilize communities by encouraging supporters to share their views with their friends. Translate awareness into action. Track policy proposals, constituent support, and politicians' stances to coordinate your activism strategy.


Deuteronomy 27:19
Cursed be he that perverteth the judgment of the stranger, fatherless, and widow. And all the people shall say, Amen.


Otter Grader¶
Otter is a light-weight scalable autograding tool that allows instructors to customize their grading methodology. It is a command line tool divded into four tools that span the assignment generation and grading process: Otter Assign, Otter Generate, Otter Check, and Otter Grade.
Otter Tools¶
Otter Assign is a fork of OkPy’s jassign that allows instructors to create a master notebook containing questions, solutions, and tests and parses them into autograder and students distribution versions. It fully integrates with the other Otter tools, e.g. allowing instructors to generate an autograding file for Gradescope as a part of the Assign process.
Otter Generate is a tool for creating the zipfile required to use Otter to grade assignments on Gradescope’s autograding platform. It allows instructors to collect tests and any support files necessary (e.g. data files) into an autograder that grades students’ submissions when they upload to Gradescope. Instructors can configure the grading process and the visibility of results, including setting seeds for each cell that is executed to ensure the same results are reached by students’ code.
Otter Check is the student-facing component of Otter and is comprised of an IPython API
otter.Notebook
and a command line script checker that execute tests against a student’s work and let them know whether or not they’re passing any tests distributed with the notebook. It also allows students to generate PDFs of their submissions that can be submitted with or instead of the Jupyter Notebook file to make grading e.g. written questions easier.Otter Grader is the core functionality of Otter that allows instructors to grade student submissions locally in sandboxed Docker containers. This tool supports submission export formats from Learning Management Systems (LMS) like Gradescope and Canvas and returns to instructors a CSV of grades for each submission. Optionally, the instructor can opt for a generated filterable PDF of each submission for manual grading.
Instructor Workflow¶
Because of the various ways in which Otter can be used, the workflow is very customizable and allows instructors to do whatever works best for them. In this section, we outline two of the more common workflows.
Otter + Gradescope¶
In this workflow, the instructor starts by using Otter Assign to create a master notebook and the Otter Generate integration to simultaneously generate a zipfile to upload to Gradescope. The instructor then creates the Gradescope assignment, uploads this zipfile to create the autograder, and distributes the student notebook however they prefer. Students can run through public tests in the notebook and, when they are ready to submit, download their notebook (and possibly a PDF) and upload these files to Gradescope. Gradescope grades these on submission and instructors can also grade questions manually.
Otter Locally¶
This workflow is very similar to the previous version, except without Gradescope. Instructors create a distribution of an assignment with Otter Assign and distribute it to students in some form or fashion. Students then submit their finished work to instructors through a channel of their choice and instructors collect these files locally and grade them using Otter Grade.