Frequently Asked Questions
What is Bitnation?
Bitnation is the organization that is building world’s first Decentralized Borderless Voluntary Nation (DBVN) - the Pangea Blockchain Jurisdiction. There are Bitnation entities incorporated in Singapore, Switzerland, Estonia, Belize and Netherlands, and Bitnation Embassies and Consulates in over 30 countries. Bitnation’s HQ is based in Amsterdan and our core contributors are spread all around the globe.
You keep mentioning your Blockchain Jurisdiction - what can you do with it?
 At the heart of our technology is a surveillance-resistant mesh network which can write smart contracts to any integrated blockchain from a fully encrypted chat frontend.
What global problems does Bitnation’s Jurisdiction solve?
Your security and choice of governance services, jurisdiction, values and economic opportunity is arbitrarily dictated by the place where you were born or reside. We can only truly reclaim our sovereignty through an independent legal domain - a jurisdiction.
Bitnation has created a blockchain jurisdiction in which communities can be built, contracts made, disputes resolved, and agreements positively enforced through reputation. Within this jurisdiction, governance services such as peer-to-peer security, insurance and education can be accessed via 3rd-party dapps.
What are Decentralised Borderless Voluntary Nations (DBVN)? Can I start my own Nation?
DBVN’s are autonomous organizations formed as smart contracts on the Ethereum blockchain under any code of law or set of rules. They are the governance service equivalent of Decentralised Autonomous Organisations (DAO).
You can absolutely start your own nation! Download the app and have a go yourself!Wow, this all sounds amazing! But how does it work under the hood? What does the tech stack look like?
We use an encrypted chat as the primary user interface because as all agreements begin with a conversation. It’s built on an off-chain mesh network that allows each client in the mesh to write smart contracts to a blockchain.
Currently, only the Ethereum chain is integrated - but we will add others in the future and offer users a choice of which blockchain they want their nation/community or individual contracts to run on.
I see XPAT is an ERC20 token, does that mean the Jurisdiction is built on Ethereum?
No, Bitnation is built on a blockchain agnostic mesh network which can write smart contracts to any integrated chain. Currently the Ethereum chain is the only one integrated, but we intend to add Bitcoin through the Rootstock protocol, Lisk, EOS and others. Citizens will be able to choose between blockchains depending on their requirements. Our architecture has been shaped to be configurable to new technologies as they emerge, including quantum resistant cryptography, which has been anticipated at the design-stage of our software.
Interesting, but how will Bitnation’s Jurisdiction create a free market for governance services?
Our core infrastructure - an off-chain mesh network linked to blockchains - is flexible and configurable. It allows many other third party blockchain services to be offered to users and communities - creating an ecosystem of competing service providers. The public API will be released during 2018, including a dapp fund to help 3rd party developers get started on their governance applications.
What is the target audience for Bitnation’s Blockchain Jurisdiction?
Over 1 billion people will be online workers by 2025. These people will be offering their services globally and requiring jurisdictions and governance service providers that transcend national and legal boundaries.
A further 2 billion people working in the informal economy or are stateless and have few legal protections.
The existing legal services industry doesn't offer enough services in either emerging or developed markets and so that’s a US$600 billion market ripe for disruption.
Bitnation’s Jurisdiction is an awesome concept, but is it realistic?
Before the release of our Jurisdiction software in January 2018, Bitnation had already registered over 12,000 citizens and 200 voluntary nations on our website. Thousands of users have notarised documents or registered ID’s using our earlier Public Notary software - demonstrating significant demand for opt-in jurisdiction and governance services. Now, based on the feedback we got from our POC and MVP, we have designed a credible and fullstack blockchain jurisdiction.
How will Bitnation’s Jurisdiction Interact with Nation State Jurisdictions?
We can only succeed if we outcompete existing systems. A useful analogy is email and the postal service - email reduced the importance of the postal service but it was never necessary to explicitly compete against it. The benefits of email over a postal service are clear, and users intuitively choose to send email instead of letters.
Similarly, the benefits of using a transparent, fast, cheap and voluntary governance service instead of slow, expensive and opaque centralised services will be clear. Our user-base will thus grow organically as the utility of our technology increases.
Some forward thinking governments are realizing this new paradigm and are integrating blockchain technology as well, others are aiming to compete on a global market for opt-in governance services such as Singapore, Estonia, Dubai, Switzerland and others.
Is the Bitnation Jurisdiction available on Android and iOS?
Yes! It’s available to download at the Google Play store for Android and on TestFlight for iOS. Updated versions with new features integrated will be released every few weeks to the stores.
We expect to have a fully functional Pangea software available for iOS, Android as well as Windows, Mac and Linux clients by the end of Q4 2018.
What is the Pangea Arbitration Token (XPAT) and how do I earn it on the Bitnation Jurisdiction?
XPAT is an ERC20 token which serves as a contract enforcement mechanism and drives the reputation system on Pangea, our Jurisdiction. Pangea awards three non-tradable sub-tokens for 1) making and completing contracts, or arbitrating disputes related to contracts, 2) building nations and communities that offer high-rated services, 3) developing and updating smart contracts that are highly rated by users.
Users can only rate smart contracts and nations - not other users - to prevent popularity contests. The AI rates users against set criteria. Once you’ve accumulated enough non-tradable reputation tokens you get awarded with XPAT, similar to Air Miles or Amazon points.
Which Exchanges are XPAT listed on?
XPAT can be traded,on Bancor, LAToken, ForkDelta, TokenJar, Komodo, Chainrift, Citowise and others. More wallets and exchanges are being added each month.
When will Phase III of the ICO start?
We held a pre-sale in Q4 2017 and a public auction in Q2 2018 and we will sell 1% per month in a slow release ICO phase from later this year. There is no official whitelist, but if you are interested in the slow release phase or private sales you can register to receive regular emailed updates on our token sale website by pressing the “Buy XPAT” button. Tokens are sold direct by Bitnation at market price with a bonuses schedule based on volumes.
How are ICO proceeds being used?
All capital raised during the ICO is being used to: further develop our technology (51%); expand our operations (22%); build market adoption and educate users (17%); and expand the ecosystem of nations, dapps and governance service providers on Pangea (10%).


Average house prices in east 'will rise from £292k to £323k over next five years'
by Sarah ChambersThe price of homes in the East of England should rebound and rise by 11% over the next five years with good properties in Ipswich - and some Suffolk's coastal towns - in demand, experts predict.
Estate agents at Savills believe that despite political turmoil in the UK and a slowdown in price rises, the average house price will increase from £291k this year to £323k by 2024 - good news for sellers, but bad news for prospective buyers.
However, the rises here will be lower than the national average, it predicts.
Savills expect average UK prices to increase by 15.3%, with central London prime locations outperforming the rest of the country with rises of 20.5%. However, overall, London prices will see only a 4% increase, it says.
Although Savills expects Brexit and election-related angst to continue to act as a drag on the market over the short term, it sees prices rising broadly in line with incomes beyond that.
Tom Orford, who leads the residential team at Savills Ipswich, said even this year, in the face of considerable political and economic uncertainty, there had been strong demand in Suffolk from motivated buyers.
"Over the last 10 years or so the East of England has experienced consistently strong house price growth that has been on par with or in excess of the national average, so it's perhaps no surprise that we are now predicting a slight slowdown in the market," he said.
"However, I would expect there to be significant variations across the region."
He predicts that Ipswich, and homes in some of Suffolk's popular coastal towns, will continue to be a draw for buyers.
"We are fortunate to live in a very sought after area - with great connectivity and superb schools that offers excellent value for money when compared to the south and in particular London," he said.
"Well maintained properties in Ipswich town centre - close to the railway station, Christchurch Park and within easy reach of shops and restaurants - have proved particularly popular, as have those in well-connected villages and the usual property hot spots of Woodbridge, Aldeburgh and Southwold."
Savills believes the average UK home will increase in value from £231k to £266k over the next five years. The average price of a home in London is expected to rise from £462k to £480k.


The area around Naples, Florida, is famous for high-end shopping, golf courses, fishing, and dolphin-sightings. It is one of the wealthiest cities in the United States with the second highest proportion of millionaires per capita. Real estate is also some of the most expensive in the country.
This high proportion of wealth means that the area is dotted with numerous marinas and yacht clubs. But do not be put-off by the idea that dockage may be equally expensive: at most Naples marinas prices are comparable with elsewhere on the Gulf Coast of Florida.
Last updated September 2016.
This is a Port of Entry.
See USA Formalities for full details on clearing into and out of the USA.
All vessels returning from foreign ports to the Naples area are required to first call +1<PHONE_NUMBER> or +1<PHONE_NUMBER> and obtain an arrival number before discharging passengers, crew, cargo or garbage. This includes US citizens registered in trusted traveler programs, and must be completed before contacting the Fort Myers office for further clearances if required.


Generally, the larger your objects and the smaller the deltas, the greater the benefits of using delta propagation. Partitioned regions with higher redundancy levels generally benefit more from delta propagation. However, in some application scenarios, delta propagation does not show any significant benefits. On occasion it results in performance degradation.
By default, delta propagation is enabled in your distributed system.
These are the main factors that can reduce the performance benefits of using delta propagation:
- The added costs of deserializing your objects to apply deltas. Applying a delta requires the entry value to be deserialized. Once this is done, the object is stored back in the cache in deserialized form. This aspect of delta propagation only negatively impacts your system if your objects are not already being deserialized for other reasons, such as for indexing and querying or for listener operations. Once stored in deserialized form, there are reserialization costs for operations that send the object outside of the member, like distribution from a gateway sender, values sent in response to
netSearch
or client requests, and storage to disk. The more operations that require reserialization, the higher the overhead of deserializing the object. As with all serialization efforts, you can improve performance in serialization and deserialization by providing custom implementations ofDataSerializable
for your objects. - Cloning when applying the delta. Using cloning can affect performance and generates extra garbage. Not using cloning is risky however, as you are modifying cached values in place. Without cloning, make sure you synchronize your entry access to keep your cache from becoming inconsistent.
- Problems applying the delta that cause the system to go back to the originator for the full entry value. When this happens, the overall operation costs more than sending the full entry value in the first place. This can be additionally aggravated if your delta is sent to a number of recipients, all or most of them request a full value, and the full value send requires the object to be serialized.
- Disk I/O costs associated with overflow regions. If you use eviction with overflow to disk, on-disk values must be brought into memory in order to apply the delta. This is much more costly than just removing the reference to the disk copy, as you would do with a full value distribution into the cache.


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 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 a JSON format that also allows JSON-LD processing. The latter provides a powerful foundation to represent knowledge about Things in a machine-understandable way. A Thing Description instance can be hosted by the Thing itself or hosted externally when a Thing has resource restrictions (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 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>(archives).
Changes from the previous publication can be found in Appendix 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 Thing Description (TD) is a central building block in
the W3C Web of
Things (WoT) and can be considered as the entry point of a
Thing (much like the index.html of a Web site). The TD
consists of semantic metadata for the Thing itself, an
interaction model based on WoT's Properties
,
Actions
, and 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 parameters, such as getting the current 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 are used for the push model of communication where notifications, discrete events, or streams of values are sent asynchronously to the receiver. In general, the TD provides metadata for different communication bindings identified by URI schemes (e.g., "http", "coap", "mqtt", etc.), media types (e.g., "application/json", "application/xml", "application/cbor", "application/exi" etc.), and security mechanisms (for authentication, authorization, confidentiality, etc.). Serialization of TD instances is 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 in such a JSON
serialization and depicts WoT's Properties
,
Actions
, and Events
paradigm by
describing a lamp Thing with the name MyLampThing.
{
"id": "urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
"security": [{"scheme": "basic"}],
"properties": {
"status" : {
"type": "string",
"forms": [{"href": "https://mylamp.example.com/status"}]
}
},
"actions": {
"toggle" : {
"forms": [{"href": "https://mylamp.example.com/toggle"}]
}
},
"events":{
"overheating":{
"type": "string",
"forms": [{
"href": "https://mylamp.example.com/oh",
"subProtocol": "LongPoll"
}]
}
}
}
Based on this content, we know there exists one
Property
interaction resource with the name
status. In addition, information is provided to indicate
that this Property is accessible via (the secure form of) the
HTTP protocol with a GET method at the URI
https://mylamp.example.com/status
(announced
within the forms
structure by the
href
key), and will return a string status value.
The use of the GET method is not stated explicitly, but is one
of the default assumptions defined by this document.
In a similar manner, an Action
is specified to
toggle the switch status using the POST method applied to the
https://mylamp.example.com/toggle
resource, where
POST is again a default assumption for invoking Actions.
The Event
pattern enables a mechanism for
asynchronous messages to be sent by a Thing. Here, a
subscription to be notified upon a possible overheating event
of the lamp can be obtained by using the HTTP with its long
polling sub-protocol at
https://mylamp.example.com/oh
.
This example also specifies the basic
security
scheme, requiring a username and password for access. In
combination with the use of 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 in Example 1 reflects some additional defined default
assumptions that are not explicitly described. For example, the
media type of the 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 Description instance, the Thing Description
processor follows default assumptions for interpretation as
defined in this specification.
The TD can be also processed as an RDF-based model. In that case, the 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 default values to be always present explicitly in the 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.
{
"@context": "http://www.w3.org/ns/td",
"id": "urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
"security": [{"scheme": "basic", "in": "header"}],
"properties": {
"status": {
"writable": false,
"observable": false,
"type": "string",
"forms": [{
"href": "https://mylamp.example.com/status",
"http:methodName": "GET",
"mediaType": "application/json"
}]
}
},
"actions": {
"toggle": {
"forms": [{
"href": "https://mylamp.example.com/toggle",
"http:methodName": "POST",
"mediaType": "application/json"
}]
}
},
"events": {
"overheating": {
"type": "string",
"forms": [{
"href": "https://mylamp.example.com/oh",
"subProtocol": "LongPoll",
"mediaType": "application/json"
}]
}
}
}
For more examples, including the use of other protocols besides HTTP, see Section 7. Example Thing Description Instances.
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 vocabulary as defined in this document is http://www.w3.org/ns/td.
Using content negotiation, this namespace serves either the TD ontology file (Turtle) or the TD context file (JSON-LD).
The suggested prefix for the TD namespace is
td
.
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.
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. Information Model 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.
In the future some information about RDF validation will be provided.
The W3C Thing Description provides a set of 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 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.
In the figures above, and in the tables to follow, items which have default values are indicated as being optional. However, technically, these are optional 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 not actually optional even in the JSON serialization. Security configuration is mandatory at least one of the three levels at which it may be specified... so it can be omitted only if it is specified at a different level for each form. A future version of this document should better express the status of these 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 virtual Things) in the Web of Things context.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
id |
unique identifier of the Thing (URI, e.g. custom URN) | yes | . |
anyURI
|
description |
Provides additional (human) readable information. | no | . |
string
|
name |
Name of the Thing. | yes | . |
string
|
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
|
properties |
All Property-based interaction patterns of the Thing. | no | . |
Property
|
actions |
All Action-based interaction patterns of the Thing. | no | . |
Action
|
events |
All Event-based interaction patterns of the Thing. | no | . |
Event
|
links |
Provides Web links to arbitrary resources that relate to the specified Thing Description. | no | . |
array of Link
|
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
|
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 | Mandatory | Default value | Type |
|---|---|---|---|---|
forms |
Indicates one or more endpoints from which an interaction pattern is accessible. | yes | . |
array of Form
|
label |
Provides a label (e.g., display a text for UI representation) of the interaction pattern. | no | . |
string
|
description |
Provides additional (human) readable information. | no | . |
string
|
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
|
The class InteractionPattern
has the
following subclasses:
Property
Properties expose internal state of a Thing that can be directly retrieved (get) and optionally modified (set). In addition, Things can also choose to make Properties observable by pushing the new state (not an event) after a change; this must follow eventual consistency (also see CAP Theorem).
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
observable |
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 (=false). | no | false |
boolean
|
Property instances may also be instances of
the class DataSchema and therefore can contain, among
others, the type
term.
Action
Actions offer functions of the Thing. These functions may manipulate the internal state of a Thing in a way that is not possible through setting Properties. Examples are changing internal state that is not exposed as a Property, changing multiple Properties, changing Properties over time or with a process that should not be disclosed. Actions may also 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 input given.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
input |
Link to the n-ary class that allows the declaration of the accepted data type of an action. | no | . |
DataSchema
|
output |
Link to the n-ary class that allows the declaration of the data type returned by an action. | no | . |
DataSchema
|
Event
The Event Interaction Pattern describes event sources that asynchronously push messages. Here not state, but state transitions (events) are communicated (e.g., "clicked"). Events may be triggered by internal state changes that are not exposed as Properties. Events usually follow strong consistency, where messages need to be queued to ensure eventual delivery of all events that have occurred.
Instances of the Event
class contains the
term definitions of the class InteractionPattern and 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 | Mandatory | Default value | Type |
|---|---|---|---|---|
href |
URI of the endpoint where an interaction pattern is provided. | yes | . |
anyURI
|
mediaType |
Assign the underlying media type [MEDIATYPES] of an interaction pattern. | 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 rel attribute indicates which form
is which and allows the client to select the
correct form for the operation required.
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).
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
href |
URI of the endpoint where an interaction pattern is provided. | yes | . |
anyURI
|
mediaType |
Assign the underlying media type [MEDIATYPES] of an interaction pattern. | 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 rel attribute indicates which form is which and allows the client to select the correct form for the operation required. | no | . |
string
|
anchor |
By default, the context of a link is the URL of the representation it is associated with, and is serialized as a URI. When present, the anchor parameter overrides this with another URI, such as a fragment of this resource, or a third resource (i.e., when the anchor value is an absolute URI). | no | . |
anyURI
|
DataSchema
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
description |
Provides additional (human) readable information. | no | . |
string
|
type |
Assignment of JSON-based data types compatible with JSON Schema (one of boolean, integer, number, string, object, array, or null). | no | . |
string
(one of |
const |
Provides a constant value. | no | . | a value of any type that is consistent with the
type given to the above type field
definition if any |
enum |
Restricted set of values provided as an array. | no | . | array of values of any type with each consistent
with the type given to the above type
field definition if any |
The class DataSchema
has the following
subclasses:
ArraySchema
A JSON array specification ("type": "array").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
items |
Used to define the characteristics of an array. | no | . |
DataSchema
|
minItems |
Defines the minimum number of items that have to be in the array. | no | . |
unsignedInt
|
maxItems |
Defines the maximum number of items that have to be in the array. | no | . |
unsignedInt
|
ObjectSchema
A JSON object specification ("type": "object").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
properties |
Data schema nested definitions. | no | . |
DataSchema
|
required |
Defines which members of the object type are mandatory. | no | . |
array of
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 |
Specifies a minimum numeric value. Only applicable for associated number or integer types. | no | . |
double
|
maximum |
Specifies a maximum numeric value. Only applicable for associated number or integer types. | no | . |
double
|
StringSchema
A JSON string value specification ("type": "string").
IntegerSchema
A JSON integer value specification, that is, numbers without a fractional part ("type": "integer").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
minimum |
Specifies a minimum numeric value. Only applicable for associated number or integer types. | no | . |
integer
|
maximum |
Specifies a maximum numeric value. Only applicable for associated number or integer types. | no | . |
integer
|
For the 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 HTTP security schemes is partly based on OpenAPI 3.0.1 (see also [OPENAPI]). 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 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 the core WoT vocabulary(and to file issues if you have a request) please visit the WoT Security TF repository.
SecurityScheme
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
scheme |
Identification of security mechanism being configured. | yes | . |
string
(one of |
description |
Provides additional (human) readable information. | no | . |
string
|
proxyUrl |
URI of the proxy server this security configuration provides access to. If not given, the corresponding security configuration is for the endpoint. | no | . |
anyURI
|
The class SecurityScheme
has the following
subclasses:
NoSecurityScheme
A security configuration corresponding to ("scheme": "nosec"), indicating there is no authentication or other mechanism required to access the resource.
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 |
|---|---|---|---|---|
in |
Specifies the location of security authentication information (one of header, query, body, or cookie). | no | header |
string
|
name |
Name for query, header, or cookie parameters. | no | . |
string
|
CertSecurityScheme
Certificate-base asymmetric key security configuration ("scheme": "cert").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
identity |
Pre-shared key identity. | no | . |
string
|
DigestSecurityScheme
Digest authentication security configuration ("scheme": "digest"). This scheme is similar to basic authentication but with added features to avoid man-in-the-middle attacks.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
qop |
Quality of protection (one of auth or auth-int). | no | auth |
string
|
in |
Specifies the location of security authentication information (one of header, query, body, or cookie). | 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 situations where bearer tokens are used independently of OAuth2. If the oauth2 scheme is specified it is not generally necessary to specify this scheme as well as it is implied.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
authorizationUrl |
URI of the authorization server. | no | . |
anyURI
|
alg |
Encoding, encryption, or digest algorithm (one of MD5, ES256, or ES512-256). | no | ES256 |
string
|
format |
Specifies format of security authentication information (one of jwt, jwe, or jws). | no | jwt |
string
|
in |
Specifies the location of security authentication information (one of header, query, body, or cookie). | no | header |
string
|
name |
Name for query, header, or cookie parameters. | no | . |
string
|
PSKSecurityScheme
Pre-shared key authentication security configuration ("scheme": "psk").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
identity |
Pre-shared key identity. | no | . |
string
|
PublicSecurityScheme
Raw public key asymmetric key security configuration ("scheme": "public").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
identity |
Pre-shared key identity. | no | . |
string
|
OAuth2SecurityScheme
OAuth2 authentication security configuration ("scheme": "oauth2"). For the implicit flow the authorizationUrl and scopes are required. For the password and client flows both tokenUrl and scopes are required. For the code flow authorizationUrl, tokenUrl, and scopes are required.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
authorizationUrl |
URI of the authorization server. | no | . |
anyURI
|
tokenUrl |
URI of the token server. | no | . |
anyURI
|
refreshUrl |
URI of the refresh server. | no | . |
anyURI
|
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
|
flow |
Authorization flow (one of implicit, password, client, or code). | no | implicit |
string
|
APIKeySecurityScheme
API key authentication security configuration ("scheme": "apikey"). This is for the case where the access token is opaque and is not using a standard token format.
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
in |
Specifies the location of security authentication information (one of header, query, body, or cookie). | no | query |
string
|
name |
Name for query, header, or cookie parameters. | no | . |
string
|
PoPSecurityScheme
Proof-of-possession token authentication security configuration ("scheme": "pop").
| Field Name | Description | Mandatory | Default value | Type |
|---|---|---|---|---|
authorizationUrl |
URI of the authorization server. | no | . |
anyURI
|
alg |
Encoding, encryption, or digest algorithm (one of MD5, ES256, or ES512-256). | no | ES256 |
string
|
format |
Specifies format of security authentication information (one of jwt, jwe, or jws). | no | jwt |
string
|
in |
Specifies the location of security authentication information (one of header, query, body, or cookie). | no | header |
string
|
name |
Name for query, header, or cookie parameters. | no | . |
string
|
This is the first draft that uses JSON-LD 1.1 as a serialization format of the Thing Description. As that is 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 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 [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 @context
and
@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 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 type transformation in the following subsections.
The root
object of a Thing Description instance MAY include the @context
key
from JSON-LD 1.1 with the value URI of the Thing
description context file
http://www.w3.org/ns/td
.
{
"@context": "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": ["http://www.w3.org/ns/td",
{"iot": "http://iotschema.org/"}],
...
}
Each mandatory and optional field
name as defined in the class Thing
MUST be serialized as a JSON key in the root
object of the Thing Description instance.
The type
of the fields properties
,
actions
, and events
MUST be a JSON
object.
The type
of the fields links
, scopes
, and
security
MUST be a JSON array.
A TD snippet based on the defined fields of the class
Thing
without the optional field @context
is given
below:
{
"id": "urn:dev:wot:com:example:servient:myThing",
"name": "MyThing",
"description": "Additional (human) readable information of the Thing.",
"support": "https://servient.example.com/contact",
"security": [...],
"base": "https://servient.example.com/",
"properties": {...},
"actions": {...},
"events": {...},
"links": [...]
}
Alternatively, the same example can be written instead
to explicitly include the (semantic) keys used by JSON-LD
1.1 (@context
and @type
):
{
"@context": "http://www.w3.org/ns/td",
"@type": "Thing",
"id": "urn:dev:wot:com:example:servient:myThing",
"name": "MyThing",
"description": "Additional (human) readable information of the Thing.",
"support": "https://servient.example.com/contact",
"security": [...],
"base": "https://servient.example.com/",
"properties": {...},
"actions": {...},
"events": {...},
"links": [...]
}
properties
Properties (and sub-properties) offered by
a Thing MUST be
collected in the 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 of the fields
properties
and items
MUST be serialized as a JSON
object.
The type of the fields
forms
, required
, and
enum
, scopes
, and
security
, MUST be serialized as a JSON array.
A TD snippet based on the defined fields is given below:
{
...
"properties": {
"on": {
"label": "On/Off",
"type": "boolean",
"forms": [...]
},
"status": {
"type": "object",
"properties": {
"brightness": {
"type": "number",
"minimum": 0.0,
"maximum": 100.0
},
"rgb": {
"type": "array",
"items" : {
"type" : "number",
"minimum": 0,
"maximum": 255
},
"minItems": 3,
"maxItems": 3
}
},
"required": ["brightness", "rgb"],
"forms": [...]
}
}
...
}
Similar to 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 a JSON-LD 1.1 processor, each
property
MUST contain the vocabulary terms
observable
and writable
due to
the open-world
assumption of Linked Data. This assumption means
that if a Linked Data model of a Thing Description instance
were to omit these vocabulary terms, then the interpreter
would not be able to 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
the class Property
is given as
follows:
...
"properties": {
"on": {
"@type": "iot:SwitchToggle",
"label": "On/Off",
"writable": false,
"observable": false,
"type": "boolean",
"forms": [...]
},
"status": {
"writable": false,
"observable": false,
"type": "object",
"properties": {
"brightness": {
"@type": "iot:CurrentLevel",
"type": "number",
"minimum": 0.0,
"maximum": 100.0
},
"rgb": {
"@type": "iot:rgbData",
"type": "array",
"items" : {
"type" : "number",
"minimum": 0,
"maximum": 255
},
"minItems": 3,
"maxItems": 3
}
},
"required": ["brightness","rgb"],
"forms": [...]
}
}
...
actions
Actions
offered by a Thing MUST be collected in the JSON-object based
actions
field with (unique) Action names as
JSON keys.
Action
and its superclass
InteractionPattern
MUST be serialized as a JSON
key within an Action object.
The type of the fields
input
and output
MUST be serialized as a JSON
object.
The keys of input
and output
rely on the the class DataSchema
.
The type of the fields
forms
, scopes
, and
security
MUST be serialized as a JSON array.
A TD snippet based on the defined fields is given below:
...
"actions": {
"fade" {
"label": "Fade in/out",
"description": "Smooth fade in and out animation.",
"input": {
"type": "object",
"properties": {
"from": {
"type": "integer",
"minimum": 0,
"maximum": 100
},
"to": {
"type": "integer",
"minimum": 0,
"maximum": 100
},
"duration": {"type": "number"}
},
"required": ["to","duration"],
},
"output": {"type": "string"},
"forms": [...]
}
...
}
...
Definitions within the
actions
field MAY have additional semantic annotations based
on JSON-LD 1.1 keywords.
events
Events
offered by a Thing MUST be collected in the 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
properties
and items
MUST be serialized as a JSON
object.
The
type of the fields forms
,
required
, and enum
,
scopes
, and security
MUST be serialized as a JSON
array.
A TD snippet based on the defined fields is given below:
...
"event": {
"overheated": {
"type": "object",
"properties": {
"temperature": { "type": "number" }
},
"forms": [...]
}
...
}
...
Definitions within the
events
field MAY have additional semantic annotations based on
JSON-LD 1.1 keywords.
forms
Each
mandatory and optional vocabulary term as defined in the
class Form
, MUST be serialized as a JSON key.
If required, forms
MAY be supplemented
with protocol-specific vocabulary terms identified with a
prefix. See also [WOT-PROTOCOL-BINDING].
When a Thing Description instance is
processed and interpreted by a JSON-LD 1.1 processor, each
forms
(array) entry MUST contain a mediaType
due to
the open-world
assumption of Linked Data. This assumption means
that if a Linked Data model of a Thing Description instance
were to omit these vocabulary terms, then the interpreter
would not be able to make any assumptions about their
actual value.
A TD snippet based on the defined fields is given below:
...
"forms": [{
"href" : "http://mytemp.example.com:5683/temp",
"mediaType": "application/json",
"http:methodName": "POST",
"rel": "writeProperty",
"security": [{"scheme":"basic", "in":"header"}]
}]
...
links
Each
mandatory and optional vocabulary term as defined in the
class Link
, MUST be serialized as a JSON key.
A TD snippet based on the defined fields is given below:
...
"links": [{
"href": "https://servient.example.com/things/lampController",
"rel": "controlledBy",
"mediaType": "application/td+json"
}]
...
security
Each
mandatory and optional vocabulary term as defined in the
class SecurityScheme
, MUST be serialized as a JSON
key.
The following TD snippet shows a simple security
configuration specifying basic username/password
authentication in the header. The value of in
given is actually the default value of
header
.
...
"security": [{
"scheme": "basic",
"in": "header"
}]
...
Here is a more complex example: a TD snippet showing
digest authentication on a proxy combined with bearer token
authentication on an endpoint. Here the default value of
in
in the digest
scheme,
header
, is implied.
...
"security": [
{
"scheme": "digest",
"proxyUrl": "https://portal.example.com/"
},
{
"scheme": "bearer",
"format": "jwt",
"alg": "ES256",
"authorizationUrl": "https://servient.example.com:8443/"
}
]
...
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 security
is marked as
non-mandatory. However, this is only true locally (at a
specific level), and only if the security is configured at
a higher or 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 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 nosec
security scheme is provided for
the case that no security is needed. The minimal security
configuration for a Thing is configuration of the
nosec
security scheme at the top level, as in
the following example:
{
"id": "urn:dev:wot:com:example:servient:myThing",
"name": "MyThing",
"description": "Additional (human) readable information of the Thing.",
"support": "https://servient.example.com/contact",
"security": [{"scheme": "nosec"}],
"properties": {...},
"actions": {...},
"events": {...},
"links": [...]
}
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 nosec
scheme
for the security configuration in the
overheating
event to indicate no
authentication is required. For the status
property and the toggle
action, however,
basic
authentication is required as defined at
the top level of the Thing.
{
...
"security": [{"scheme": "basic"}],
"properties": {
"status": {
...
"forms": [{
"href": "https://mylamp.example.com/status",
"mediaType": "application/json",
}]
}
},
"actions": {
"toggle": {
...
"forms": [{
"href": "https://mylamp.example.com/toggle",
"mediaType": "application/json"
}]
}
},
"events": {
"overheating": {
...
"forms": [{
"href": "https://mylamp.example.com/oh",
"mediaType": "application/json",
"security": [{"scheme": "nosec"}]
}]
}
}
}
Security definitions can also can be given for different
elements at the 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 security
field combines them in an "AND"
fashion, since in that case they would all need to be
satisfied to allow access to the resource.
...
"properties": {
"status": {
...
"forms": [
{
"href": "https://mylamp.example.com/status",
"mediaType": "application/json",
"security": [{"scheme": "basic"}]
},
{
"href": "https://mylamp.example.com/status",
"mediaType": "application/json",
"security": [{"scheme": "digest"}]
},
{
"href": "coaps://mylamp.example.com:5683/status",
"mediaType": "application/json",
"security": [{"scheme": "apikey"}]
}
]
}
},
...
The JSON-based serialization of the TD is identified by
the media type [MEDIATYPES]
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.
The minimum requirement to read the content of a Thing Description instance is a (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 assumed.
If the 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 terms (e.g., iot.schema.org), use of JSON-LD or RDF-based tools and libraries is highly recommended as explained in the next sub-section.
To interpret the semantic meaning of a Thing Description in terms of RDF triples, a 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:
@context
key from JSON-LD 1.1 as defined in
Section 6.1.1 Thing as a whole.@context
field.Section 1. Introduction shows an example of how the input and output of such preprocessing would appear.
{
"id": "urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
"description" : "MyLampThing uses JSON-LD 1.1 serialization",
"security": [{"scheme": "psk"}],
"properties": {
"status": {
"description" : "Shows the current status of the lamp",
"type": "string",
"forms": [{
"href": "coaps://mylamp.example.com/status"
}]
}
},
"actions": {
"toggle": {
"description" : "Turn on or off the lamp",
"forms": [{
"href": "coaps://mylamp.example.com/toggle"
}]
}
},
"events": {
"overheating": {
"description" : "Lamp reaches a critical temperature (overheating)",
"type": "string",
"forms": [{
"href": "coaps://mylamp.example.com/oh"
}]
}
}
}
{
"@context": ["http://www.w3.org/ns/td",
{"iot": "http://iotschema.org/"}],
"@type" : "Thing",
"id": "urn:dev:wot:com:example:servient:lamp",
"name": "MyLampThing",
"description" : "MyLampThing uses JSON-LD 1.1 serialization",
"security": [{"scheme": "psk"}],
"properties": {
"status": {
"@type" : "iot:SwitchStatus",
"description" : "Shows the current status of the lamp",
"writable": false,
"observable": false,
"type": "string",
"forms": [{
"href": "coaps://mylamp.example.com/status",
"mediaType": "application/json"
}]
}
},
"actions": {
"toggle": {
"@type" : "iot:SwitchStatus",
"description" : "Turn on or off the lamp",
"forms": [{
"href": "coaps://mylamp.example.com/toggle",
"mediaType": "application/json"
}]
}
},
"events": {
"overheating": {
"@type" : "iot:TemperatureAlarm",
"description" : "Lamp reaches a critical temperature (overheating)",
"type": "string",
"forms": [{
"href": "coaps://mylamp.example.com/oh",
"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 have
default values that are used by Thing Description processors
when they are absent in TD instances (see Section 5.2 Core Vocabulary Definition). Note
that some security vocabulary terms can also have such
values (see Section 5.4 Security Vocabulary Definition).
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
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.


HAVE A QUESTION?NEED TO TALK TO A TECH OR DESIGN EXPERT?
Leave your request below and our consultant will contact you within 3 days.
Thanks! We'll get back to you very soon.
WANT TO EXTEND YOUR VOLUNTEERING EXPERIENCE AND BECAME A TECHNICAL CONSULTANT?
Contact us for more info.


_meme
_compliment
_trivia
_ptrivia
_mean <word>
_math <problem>
_confess <confession>
_f m <number>
_f y <year>
_joke
_inspire
_wea <city, country code>
_wiki <query>
_search <query>
_movie <movie>
_song <song or artist>
_rank
_hi
_contribute
_rolldice
_tosscoin
Sends a meme from reddit
Gives a random complement
Sends a trivia
Interactive trivia with user
Finds the meaning of the word
Solves the math problem
Deletes the user's confession and forwards the message to configured confession channel
Tells an intersting fact about the number
Tells an intersting fact about the year
Tells a joke
Sends an inspirational quote which will surely enlighten you
Tells the current weather condition of the city
Searches the wikipedia for the query
Searches DuckDuckGo for the query
Tells the details of the movie
Tells the detail about the song or finds the most famous song of the artist
Tells the current friendship level of roBOT with you
Provides you with a link to find roBOT's commands
Provides you a link to roBOT's source code
Rolls a dice
Tosses a coin


--- layout: default title: "Cookie policy - Cathy Dutton" description: "Cookie policy for cathydutton.co.uk" intro: "Cookie policy" heading: "Last updated 30 June 2018" group: "navigation" page: "Cookie" active: "Cookie" ---
A cookie is a small text file which is placed onto your computer or electronic device when you access our website. Similar technologies include web beacons, action tags, local shared objects ('flash cookies') and single-pixel gifs. Such technologies can be used to track users' actions and activities, and to store information about them. We use these cookies and/or similar technologies on this website for the following purposes:
Google analytics to record track visitor detailsWe may obtain information about your computer or any other electronic device which you use to access our website, such as your IP address, your browser and/or other internet log information. We will treat this information as your personal information.
In most cases we will need your consent in order to use cookies on this website. The exception is where the cookie is essential in order for us to provide you with a service you have requested, or essential to the inherent functionality of the website (e.g to enable you to store items in a shopping basket and/or to use our check-out process).
Where we wish to use cookies that require your consent you will be asked whether you consent to the use of cookies in the following manner:
On the first visit a pop up window will ask for your to consent via clicking a confirmation button. This preference will then be saved for future visits.
Thereafter you will be provided with an opportunity to opt-out of the use of cookies which can be done in the following manner:
The pop up banner will display every 30 days giving users the option to opt out of cookies in future.
We work with third party suppliers who may also set cookies on our website. These cookies and their third party owners, are included in the table below. By consenting to the use of cookies on our site you will be consenting to the use of these cookies. These cookies may be used to collect the following information:


Slider Revolution Hero Templates
All example sliders you find below are included with the download of the Slider Revolution 5.0 Plugin. Oh, and it also comes with all assets like images and videos. Browse the Examples Folder through to find your favorite Example. Duplicate it and just start to build your own Slider based on our examples!
- All Example
- 3D
- Landing Page
- Slider
- Hero Scene
- Timer
- Carousel
- Auto-Size
- Full-Width
- Full-Screen
- Tabs
- Scroll Navigation
- Menu Navigation
- Front Page
- Special Content
- Parallax
- HTML5 Video
- YouTube Video
- Vimeo Video
(Only Server Environment)


Russell Crowe's property torched by raging Australian bushfires
Oscar-winning actor Russell Crowe could only watch on as bushfires destroy buildings at his rural property in Eastern Australia as help try to douse flames
by James Brinsford, https://www.facebook.com/james.brinsfordRussell Crowe's sprawling mansion in New South Wales has been hit by the raging bushfires that are spreading across eastern Australia.
The Oscar-winning actor revealed on social media that his rural property had seen two buildings destroyed by the fires.
The Gladiator star tweeted that while he was out of the country, his 400-hectare property near Coffs Harbour was hit by the "catastrophic" bushfires.
After confirming that his family and friends were safe, the 55-year-old posted a video and pictures on his Twitter feed of a helicopter water-bombing smoke-filled trees near a fence and driveway, commenting "Top shot son!"
He added three pictures of the grounds around his home on fire, showing firefighters containing the blaze.
Crowe did not specify how badly his property was affected but no photos showed the house on fire. He did not say who took the photos.
Bushfires are a common and deadly threat in Australia's hot summers, but the blazes have arrived earlier this year, spurred by dry conditions after three years of drought, and have already claimed three lives.
In a post showing burned ground and charred objects at his his property in northeast New South Wales state, Crowe said: "lost a couple of buildings, but overall very lucky so far. Chapel roof scorched."
He thanked those on the ground and said no livestock or horses had died.
"Let the chickens out and they are back, warm worms for breakfast!", the actor tweeted.
There were a few non-plussed residents in Nana Glen though, as they claimed firefighters prioritised Crowe's property, which had led to some of their homes getting damaged.
One resident, Debbie Waldon, was emotional as she tearfully told Seven News that she thought there was an unfair biased being shown towards Crowe's residence.

"What about normal, everyday people?"
This claim has been refuted by the NSW Rural Fire Service who said that Ms Waldon's claims were nonsense.
A spokesperson said: "Firefighters are not aware of whose homes they are being sent to – aerial crews wouldn't be aware of whose property they are going to either.
"Crews are dispatched on priority of jobs and the properties that need it the most, we are not aware of who owns the properties."
Do you have a story to sell? Get in touch with us at<EMAIL_ADDRESS>or call us direct 0207 29 33033.


Test model reads the first character from resources/y.txt during initialization and applies its integer value to y.
resources/y.txt
y
The plot shows the reference result computed with simulatefmi3me.c.


git-sh-i18n--envsubst - Git*(Aqs own envsubst(1) for i18n fallbacks
eval_gettext () { printf "%s" "$1" | ( export PATH $(git sh-i18n--envsubst --variables "$1"); git sh-i18n--envsubst "$1" ) }
This is not a command the end user would want to run. Ever. This documentation is meant for people who are studying the plumbing scripts and/or are writing new ones.
git sh-i18n--envsubst is Git(cqs stripped-down copy of the GNU envsubst(1) program that comes with the GNU gettext package. It(cqs used internally by git-sh-i18n(1) to interpolate the variables passed to the eval_gettext function.
No promises are made about the interface, or that this program won(cqt disappear without warning in the next version of Git. Don(cqt use it.
Part of the git(1) suite


Interested in signing up for a programming bootcamp? You've come to the right place! Epicodus is a highly regarded and highly ranked bootcamp, complete with internship placement and job search assistance.
The first thing to decide after signing up is which Epicodus track you want to take. This is an important decision, as this will determine what programming language you learn.
Answer the questions below, and we'll steer you in the right direction.


d_download_ADC_packages.Rmd
Mac Users:
First install the following R packages:
install.packages("devtools")
devtools::install_github("ropensci/EML")
devtools::install_github("NCEAS/datamgmt")
library(datamgmt)
library(dataone)
PC Users:
We currently have issues installing datamgmt on PCs. Instead of installing the package, we can load the functions directly into your global environment by copy-pasting. First install the following R packages:
install.packages("devtools")
devtools::install_github("ropensci/EML")
devtools::install_github("NCEAS/arcticdatautils")
install.packages("dataone")
install.packages("magrittr")
library(dataone)
library(magrittr)
Source (copy-paste into your R console) the file https://github.com/dmullen17/work-samples/blob/master/R/wg_helpers.R
Note: This concludes the differences between Mac and PC installs.
Next, we need to specify which DataONE Member Node we want to interact with. The following code specifies the Arctic Data Center. Most of the functions that we use specify the mn
as the first argument. First, we specify the Coordinating Node and then its corresponding Member Node.
Optional arguments:
write_to_csv
- writes each data.frame to a csv in the specified download_directory
prefix_file_names
- prepends the DOI identifier to each filedownload_directory
- required if write_to_csv = TRUE
attributes <- get_eml_attributes_url(mn,
"https://arcticdata.io/catalog/#view/doi:10.18739/A22W0R",
write_to_csv = TRUE,
prefix_file_names = TRUE,
download_directory = "/home/dmullen/downloads")
This is a better option (than the first method) if you would like to prefix your data files (in addition to metadata files) with the DOI identifier.
All we need to specify is the package resource map. Copy-paste this into R.
Optional arguments:
prefix_file_names
- prepends the DOI identifier to each filedownload_column_metadata
- downloads column metadata to csv filesconvert_excel_to_csv
- attempts to convert Excel workbooks in the package to csv files. Not recommended if the csv files are already present in the packagedownload_child_packages
- downloads any “Nested” Data Packages associated with the Data Packagedownload_package(mn,
"resource_map_doi:10.18739/A22W0R",
download_directory = "/home/dmullen/downloads",
prefix_file_names = TRUE,
download_column_metadata = TRUE,
convert_excel_to_csv = FALSE,
download_child_packages = TRUE)
We can download multiple data packages by specifying multiple resource maps to the function download_packages()
. Note the ‘s’!
Tip If you want to download Data Packages that are nested under a common Data Package, you can use the common “parent” resource map rather than copying-pasting multiple resource maps into R.
download_packages(mn,
c("resource_map_doi:10.18739/A21G1P", "resource_map_doi:10.18739/A2RZ6X"),
"/home/dmullen/downloads",
prefix_file_names = TRUE,
download_column_metadata = TRUE)
Suppose we want to download this package from LTER: https://search.dataone.org/#view/https://pasta.lternet.edu/package/metadata/eml/knb-lter-ntl/276/13
We first need to tell R that we are changing Member Nodes. The fastest way of doing this is to reset your mn
with the guess_member_node()
function.
Note: This function accepts metadata and resource map PIDs or DataONE package URLs as inputs.
# The following three calls return the same member node (mn)
# Metadata pid input:
mn <- guess_member_node("https://pasta.lternet.edu/package/metadata/eml/knb-lter-ntl/276/13")
# Resource map pid input:
mn <- guess_member_node("doi:10.6073/pasta/97c6d83a5f6a0a065ef3209fcb491b6e")
# Package URL input:
mn <- guess_member_node("https://search.dataone.org/#view/https://pasta.lternet.edu/package/metadata/eml/knb-lter-ntl/276/13")
# We can now use any of the above functions:
get_eml_attributes_url(mn, "https://search.dataone.org/#view/https://pasta.lternet.edu/package/metadata/eml/knb-lter-ntl/276/13")


Documentation
If you do not understand some terms, then please see the
glossary
.
Installation
Unix
Windows
Tutorials
Writing english documentation for Yanel
Best Practices
Rapid development of components
Architecture
Overview
Realms
What is a realm?
How to add and configure a new realm (publication/site)
Import an existing website as a new realm
Realm Configuration (realm.xml)
Resource Types
What is a resource type
Registering and using a resource type
Resource Type Configuration
Resource Type Configuration Map
Development
Setup Yanel in Eclipse IDE
Setup your build environement for more than one project
Enhancing a resource type (CRUD: Create, Read, Update, Delete)
Making a resource type Readable/Viewable
Making a resource type Createable
Making a resource type Updateable/Editable/Modifiable
Making a resource type Deleteable
Access global and resource type specific data from a resource type
BasicXMLResource
ExecutableUsecaseResource
(stateless usecase framework)
Configuring a target environment
Tutorials
Create a new resource type from scratch
Security
Overview
Access Control Policies
Login Screen Customization
Pre-authentication
SSL
Custom IdentityManager, custom PolicyManager and custom WebAuthenticator
Single sign-on (SSO) using CAS
Prevent caching of protected pages
Workflow
Overview
Yarep as Data Abstraction Layer
SVN
Instantiation of a Repository
Repository Configuration
Yarep 2 JCR
Yarep Search
Yanel Configuration
conf/yanel.xml
conf/realms.xml
REALM_DIR/realm.xml
conf/resource-types.xml
conf/spring-yanel-config.xml
conf/log4j.properties
conf/CatalogManager.properties (Resolving DTDs, etc.)
WEB-INF/web.xml
Debugging
Debugging log files and client server communication
How a request is processed
Yanel Toolbar Customization
Javadoc
To generate the Javadoc run
./build.sh javadoc
resp.
build javadoc
Versioned API ...
Deployment
All In One
Serving Content Statically
Enterprise
(including Load-Balancer and Tomcat Cluster)
Deployment with a Reverse Proxy
Install Apache-Httpd with SSL support
Within FOAF environment
Using Tomcat
Yanel and i18n
JMeter
Yanel Testing Framework
Misc
Scalability
Performance
Xopus 3
Scheduler
E-Mail/SMTP Configuration
Google Web Toolkit integration
Google Analytics integration
E-Commerce integration
404 Screen Customization
Exception Handler Customization
Yanel command line (console)
Annotations, Meta and Tracking Information


App Engine Python SDK
v1.6.9 rev.445
The Python runtime is available as an experimental Preview feature.
google
appengine
api
datastore_errors
Error
google.appengine.api.datastore_errors.Error Class Reference
Inheritance diagram for google.appengine.api.datastore_errors.Error:
Detailed Description
Base datastore error type.
The documentation for this class was generated from the following file:
code/googleappengine-read-only/python/google/appengine/api/datastore_errors.py
Maintained by
tzmartin


{{experiment.Script}}
{{experiment.Status | formatStatus}}
Elapsed time: {{remainingTime.ElapsedTime}} since {{remainingTime.WorkStarted | date:'yyyy-MM-dd HH:mm:ss'}}
Average time to completion: {{remainingTime.AverageTimeToCompletion}}
Remaining experiments: {{remainingTime.RemainingExperimentCount}}
Estimated remaining time: {{remainingTime.EstimatedRemainingTime}} with {{remainingTime.ActiveWorkerCount}} active worker(s)
Estimated time of completion: {{remainingTime.EstimatedTimeOfCompletion | date:'yyyy-MM-dd HH:mm:ss'}}
The experiment has a total of number of {{experimentInstancesData.TotalExperimentInstances}} experiment instances. Each permutation is simulated {{experiment.Repetitions}} time(s).
| # | {{param.Name}} | Status | Download |
|---|---|---|---|
| {{instance.Id}} (Details) | {{instance.Configuration[param.Name]}} | {{instance.Status | formatStatus}} (Since {{instance.WorkStarted | date:'yyyy-MM-dd HH:mm:ss'}}) !!! | Download Executable |


Direct Internet Message Encapsulation (DIME) is an old Microsoft specification for sending and receiving SOAP messages along with additional attachments, like binary files, XML fragments, and even other SOAP messages, using standard transport protocols like HTTP.
Sample file: curl -LO https://github.com/kaitai-io/kaitai_struct_formats/files/5894723/scanner_withoptions.dump.gz && gunzip scanner_withoptions.dump.gz
This page hosts a formal specification of DIME (Direct Internet Message Encapsulation) Message using Kaitai Struct. This specification can be automatically translated into a variety of programming languages to get a parsing library.
meta:
id: dime_message
title: DIME (Direct Internet Message Encapsulation) Message
file-extension:
- dim
- dime
xref:
mime: application/dime
wikidata: Q1227457
license: CC0-1.0
bit-endian: be
endian: be
encoding: ASCII
doc: |
Direct Internet Message Encapsulation (DIME)
is an old Microsoft specification for sending and receiving
SOAP messages along with additional attachments,
like binary files, XML fragments, and even other
SOAP messages, using standard transport protocols like HTTP.
Sample file: `curl -LO
https://github.com/kaitai-io/kaitai_struct_formats/files/5894723/scanner_withoptions.dump.gz
&& gunzip scanner_withoptions.dump.gz`
doc-ref:
- https://datatracker.ietf.org/doc/html/draft-nielsen-dime-02
- https://learn.microsoft.com/en-us/archive/msdn-magazine/2002/december/sending-files-attachments-and-soap-messages-via-dime
- http://imrannazar.com/Parsing-the-DIME-Message-Format
seq:
- id: records
type: record
repeat: eos
types:
padding:
doc: padding to the next 4-byte boundary
seq:
- id: boundary_padding
size: (- _io.pos) % 4
option_field:
doc: the option field of the record
seq:
- id: option_elements
type: option_element
repeat: eos
option_element:
doc: one element of the option field
seq:
- id: element_format
type: u2
- id: len_element
type: u2
- id: element_data
size: len_element
record:
doc: each individual fragment of the message
seq:
- id: version
doc: DIME format version (always 1)
type: b5
- id: is_first_record
doc: Set if this is the first record in the message
type: b1
- id: is_last_record
doc: Set if this is the last record in the message
type: b1
- id: is_chunk_record
doc: Set if the file contained in this record is chunked into multiple records
type: b1
- id: type_format
doc: Indicates the structure and format of the value of the TYPE field
enum: type_formats
type: b4
- id: reserved
doc: Reserved for future use
type: b4
- id: len_options
doc: Length of the Options field
type: u2
- id: len_id
doc: Length of the ID field
type: u2
- id: len_type
doc: Length of the Type field
type: u2
- id: len_data
doc: Length of the Data field
type: u4
- id: options
size: len_options
type: option_field
- id: options_padding
type: padding
- id: id
doc: Unique identifier of the file (set in the first record of file)
type: str
size: len_id
- id: id_padding
type: padding
- id: type
doc: Specified type in the format set with type_format
type: str
size: len_type
- id: type_padding
type: padding
- id: data
doc: The file data
size: len_data
- id: data_padding
type: padding
enums:
type_formats:
0: unchanged
1: media_type
2: absolute_uri
3: unknown
4: none


XVWA is hassle-free to setup. You can set this up on windows, linux or Mac. Following are the basic steps you should be doing on your Apache-PHP-MYSQL environment to get this working. Let that be WAMP, XAMP or anything you prefer to use.
Copy the xvwa folder in your web directory. Make sure the directory name remains xvwa itself. Make necessary changes in xvwa/config.php for database connection. Example below:
$XVWA_WEBROOT = '';
$host = "localhost";
$dbname = 'xvwa';
$user = 'root';
$pass = 'root';
Make following changes in PHP configuration file.
file_uploads = on
allow_url_fopen = on
allow_url_include = on
Access the application on : http://localhost/xvwa/
Setup the database and table by accessing http://localhost/xvwa/setup/
The login details
admin:admin
xvwa:xvwa
user:vulnerable


---
layout: post
title: Building Mobius Forensic Toolkit 0.5.14 on OS X
date: '2012-08-27T20:09:00.004+09:00'
author: Joshua James
tags:
modified_time: '2012-08-27T20:09:29.495+09:00'
blogger_id: tag:blogger.com,1999:blog-2701259639305045003.post-3458967287847352938
blogger_orig_url: http://www.cybercrimetech.com/2012/08/building-mobius-forensic-toolkit-0514.html
---
http://packetstormsecurity.org/files/115723/mobiusft-0.5.14.tar.gz
Requires:
pygobject-2.0: http://ftp.gnome.org/pub/GNOME/sources/pygobject/
Note: the newest version of pygobject requires a version of gobject-introspection above what is available in macports. Because of this I went with version 2.10.1, which built without incident.
PyGTK: http://www.pygtk.org/downloads.html
For me pygtk installed from source with the standard ./configure make && make install
Download Mobius Forensic Toolkit sources
tar -xvf mobiusft-0.5.14.tar.gz
sudo python setup.py install


IdentityLink Graph Example Code
Graph view
Transfer View
Identity View
Configuration
Data Upload
API Documentation


This is done totally without JavaScript. Just HTML and CSS.
Style H1
Heading Style H3
Heading Style H4
Heading Style H5
Heading Style H6
Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem Ipsum has been the industry's standard dummy text ever since the 1500s, when an unknown printer took a galley of type and scrambled it to make a type specimen book. It has survived not only five centuries, but also the leap into electronic typesetting, remaining essentially unchanged. It was popularised in the 1960s with the release of Letraset sheets containing Lorem Ipsum passages, and more recently with desktop publishing software like Aldus PageMaker including versions of Lorem Ipsum.
Information
×
Error
×
Suxess
×
| Brand Name | Generic Name | Drug Form Type | Supplier Name | Strength in mg | Usage Information | Cost Price | Retail Price | Re-order level | Re-order quantity |
|---|---|---|---|---|---|---|---|---|---|
| TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent |
| TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent |
| TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent |
| TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent | TableContent |


Hi! I'm Naomi, I'm a 20 year old JS & C# developer.My pronouns are she/her and I'm from Mexico.View some of my profiles byselecting an option from the dropdown below:
My email:
<EMAIL_ADDRESS>Hover over it to reveal it.


Print Dialog
The Print Dialog lets you choose which view you want to print or print preview. Select the view and click OK. The selected view for the current object will be printed.
See also: Printing Objects, Print Preview


Festival Guide:
[Festival of Darkness - Requirements for Participation]
1. In order to participate in the Festival of Darkness, you must belong to either the Lords of Dawn or the Revolutionaries of Dusk.
2. You may participate at any time during the competition period of the Seven Signs, and no limit is imposed on the number of times you may participate.
3. To request participation, five or more players belonging to the same group of fighters must form a party.
4. The party members' levels must meet the criteria established by the festival. The following is the list of grades used in the Festival of Darkness:
- Less than Level 32 Grade
- Less than Level 43 Grade
- Less than Level 54 Grade
- Less than Level 65 Grade
- No Level Limit Grade
5. All party members' grade must be equal.
Go back.


{{ define "content" }}
{{ template "basicspotlight" . }}
Frequently Asked Questions How do I pay for my deliveries? New We use a redeemable code system for delivery fees. You can get a code by simply sending $5 through Venmo to @EnactusCafDelivery. When you Venmo, remember to put your gac email address in the description so we know who you are! Additionally, you can also purchase a $10 card from the Bookmark. Get one before you order! What days of the week and what hours does Enactus deliver? Which buildings are available for cafeteria delivery? We will have our first run on Friday, March 15th, from 7:00pm to 10:00pm. We will be delivering to CoEd, Complex, Uhler, Rundstrom, Pittman/Sohre, Southwest/IC, Prairie View and College View. For Spring ‘19 semester, we will also run Saturday March 16th, Friday April 12th and Saturday April 13th. Can I customize my food order? Meal customization will be limited during the trial run. Currently for each order, you can choose up to two predetermined meal combos: Deli Sandwich (Vegetarian available), Burger, Chicken Strips and Pizza. French fries and a bottled drink are included with each combo. We will be expanding our menu options once the trial run is complete and we have finished data analysis. Can I use my caf account to purchase food? What forms of payments are accepted? Yes! The meal itself will be purchased with your cafeteria meal plan, while the service fee must be paid for using the CafApp Delivery Codes. The cost of each delivery is $2.50. With a CafApp card priced at $10, you can use one card for up to four deliveries. CafApp Delivery Cards can be purchased from the Bookmark. You can also get a code through Venmo as well! How do I place an order? When the service is open, you can head over to this website to start ordering. After logging in, click “Order Now” where you will select which meal combo(s) you want. After that, you will be able to customize your order, choosing your drink and your dorm. Either while order, or prior to (on the “Redeem” page) you will need redeem your pre-purchased Delivery Card. After finalizing and confirming your order, you will be taken to the Order Tracker where you can see the status of your order in real time. How long can I expect my meal to take? This will depend on how many orders are being placed each round. However, the delivery vehicle will be departing for delivery approximately every 30 minutes . If your order is prepared just as the vehicle departs, then the soonest you can expect your meal is within 15 minutes. If your meal is placed and prepared as soon as the vehicle departs, it could take upwards of 45 minutes. But don't worry! Your food is kept warm and tasty through warmers the entire way. How do I know when my meal is delivered?  For this reason, make sure to keep the website open so you can receive the notification, and be ready at the door to make the deliveries go smoothly. Additionally, the driver will call and alert you that your food is outside of your building.  Will my food be delivered to my door? Unfortunately, not for the trial run. When you receive your notification, the delivery vehicle will be outside of your building with your food. Upon notification, you can go outside of your building and your driver will give you your order. I keep seeing trial run referenced. What is the trial run? The cafeteria delivery service is currently in a trial run phase, meaning we will be delivering for two month in order to collect data. Once the trial run is complete, the delivery service will be paused temporarily in order to analyze the data collected and improve our delivery process. During the trial run, limited food options will be available as well as longer waiting times. We thank you for your patience and support!


{% extends "pretixcontrol/event/base.html" %} {% load i18n %} {% load compress %} {% load staticfiles %} {% load escapejson %} {% block title %}{% trans "Statistics" %}{% endblock %} {% block content %}
{% blocktrans trimmed %} We will show you a variety of statistics about your sales right here, as soon as the first orders are submitted! {% endblocktrans %}


When writing the markup code for websites, classes and id's are extremely useful to identify things thta you want to syle using CSS. The problem is that, it kinda feels like they do the same thing... And they do. But, although theis doesnt seem to matter now, later versions of browsers may not recognize classes and id's as they do now, if we dont adhere to the best practice rules for them. For example: Javascript has a function called getElementById that allows you to madofy elements based on their id. It does now, however have the capaility for classes. This means that by not adhering to the best preactice, you might end up having to rebuild pages down the line.
Basically, think of the id tag as a way to identify single elements by themselves. The class tag on the other hand, identifies groups of things that you would want to change together. A good example of this is a news site; The layout tends to stay the same, but the content inside it changes almost constantly. By nesting classes within id's, we can apply things to them without effecting the boxes they are conatined in.


$FEF3/65267: Delay loop for serial bus in 1541 mode, from $E97D Jump from $E97D: FEF3: 8A TXA FEF4: A2 05 LDX #$05 Jump from $FEF7: FEF6: CA DEX ; about 40 microseconds FEF7: D0 FD BNE $FEF6 FEF9: AA TAX FEFA: 60 RTS Previous Page / Next Page


Policy Number: 36564574
Name: John Smith
Address: 70 Mark Ln, London EC3R 7NQ
Phone Number: 073 7407 2403
DOB: 06/02/1987
Age: 30
No Claim Discount: 5-years
Customer for: 3 years
Premium: £600 annually
Location: 1 St Katharine's Way, St Katharine's & Wapping, London E1W 1UN (Westbound)
Drivers Name: John Smith
Driver Insured: YES
Ambulance needed: NO
Collision: Minor accident
Details:Fusce cursus pulvinar lectus a tempor. Aliquam ut magna ac ipsum convallis rutrum ut ut sem. Mauris dictum auctor lacus, in iaculis sem vestibulum et. Donec sed est pellentesque, commodo risus eget, efficitur massa.
Make: Toyota
Model: Prius
Year of manufacture: 2013
Engine size: 1600cc
Colour: Blue 3B78
Previous owners: 1
Address: 92 Southwark Park Road London SE16 3RS
Phone: 020 7252 2215
Estimate repair time: 3 days
Comment: Repaint with genuine colors. Replace with new parts.
AcceptAddress: 398-403 The Railway Arches London E14 7TN
Phone: 020 7515 1501
Estimate repair time: 1 day
Comment: We will pick up the vehicle and delivery it within 5 mile radius. Fast repair
AcceptAddress: 28 Osborn Street London E1 6TD
Phone: 020 7426 0001
Estimate repair time: 4 days
Comment: Pick up and deliver
Accept


This rule checks that impl scope does not depend on base scope of another component part. Impl scope is only allowed to depend on the base scope of the same component.
package com.devonfw.ide.sonarqube.component1.logic.impl; import com.devonfw.ide.sonarqube.component2.logic.base.Bar; public class MyClass {}


Maplace.js helps you to embed Google Maps into your website, quickly create markers and controls menu for the locations on map.
It requires jQuery and Google Maps API v3 so you need to have both in your page.
Features
Straightforward implementation with simple options
Can run as many maps as required
Markers and custom icons, zoom level and custom controls menu
Supports for Directions, Polygons, Circles, Polylines, Fusion tables, and styled maps
Works in all major browsers
Released under the MIT license
Installation [v@VERSION]
npm
Bower
Or download and import one of these files into your project:


WITNESS LIST Teacher Health Insurance, Select Committee June 14, 2000-9:00A Teacher Health Insurance For: Britt, Mrs. Paula (Self and ATPE, Region 1 Vice-President) Brooks, Roy (Self and PSJA Federation of Teachers; Rio Grande Valley Central Labor Council) Conlon, Paul D. (Self and Waco Federation of Teachers) Galvan, Gilbert (Self and TCTA) Garza, Jose Manuel (Self and ATPE, Brownville Local Unit) Garza, Mrs. Velma (Self) Gonzalez, Adelita C. (TSTA, Region 1 President) Gonzalez, Yolanda (TSTA) Hinojosa Gonzalez, Argelia A. (Self) Hunnicutt, Kay (Self) Knowles, Stephanie A. (Self) Lara, Maria Z. (Self) Leo, Filomena (Self and La Joya ISD) Lopez, Michael J. (Self) Ortega, Yvonne (Self and La Joya ISD) Perez, Maximino (Self) Perez, Noe E. (Self and Diane Perez (spouse)) Perez, Robert (Self) Perez, Vangela D. (Self and La Joya ISD (Instructional Resources and Technology)) Pineda, Anita (Self and Mercedes Educators Association; TSTA) Prukop, Dorothy Lyssy (Self and Mission CISD; ATPE, local President) Rodriguez, Delma (Self) Saenz, Ruben (Texas Retired Teachers Association) Salinas, Juan R. (Self) Soto, Yvonne Z. (McAllen Classroom Teachers Association) Trdla, Yolanda G. (Self) Trussell, Carla (Self and Kaye Tidwell) Villalpando, Harriet (Self) Zamora, Roberto (Self and Region 1 ESC Superintendents) On: Gonzalez, Mari (Self) Registering, but not testifying: For: Fryburger, Craig (Self) Garcia, Rosa (Self)