The Semantic Sensor Network Ontology (commonly known as "SSN" or sometimes "SSNO") is an OWL-2 DL ontology for describing sensors and the observations they make of the physical world. SSN is published in a modular architecture that supports the judicious use of "just enough" ontology for diverse applications, including satellite imagery, large scale scientific monitoring, industrial and household infrastructure, citizen observers, and Web of Things. SSN is described and examples of its use are given.
The namespace for SSN terms is http://www.w3.org/ns/ssn/
The suggested prefix for the SSN namespace is ssn
The SSN ontology itself is available here.
This is the first published version of the SSN since its original publication by the SSN-XG, the Semantic Sensor Network Incubator Group of the W3C. This is a very incomplete draft to indicate the scope and style of changes proposed to be made to the original SSN. This document is both incomplete and inconsistent, but is being published at this stage to solicit comment from the community of SSN users and would-be users.
For OGC This is a Public Draft of a document prepared by the Spatial Data on the Web Working Group (SDWWG) — a joint W3C-OGC project (see charter). The document is prepared following W3C conventions. The document is released at this time to solicit public comment.
Sensor observations are a major source of data published on the Web. Yet, publishing, searching, reusing, and integrating this data requires more than just the observation values. Of equal importance is information about the studied feature of interest, such as a river, the observed property, such as flow velocity,and the sampling strategy. The sampling location, instrumentation, and information about the deployment of the instruments on a sensor platform may also be required for proper interpretation. OGC's Sensor Web Enablement standards provide a means to annotate sensors and their observations. However, these standards are not yet integrated and aligned with paradigms such as Linked Data and W3C Semantic Web technologies more generally, that are believed to be a key driver for creating and maintaining a global and densely interconnected graph of data. The W3C Semantic Sensor Network Incubator Group (SSN) addressed these issues by developing an ontology that spans over multiple OGC standards and other specifications to support the semantic lifting of observations together with data about the sensors and their capabilities, deployment information, and so forth. Based on this initial work, the following document specifies a revised, modularized, and extended version of the SSN.
Justify why we are changing SSN at all
Specifically,The The DOLCE ultralite ontology (DUL) was previously imported into SSN and many SSN terms inherited from DUL terms. This has been redesigned into two separate ontology modules so that SSN can be used quite independently of DUL if desired. Those parts of SSN that use DUL terms have been separated into the SSN Alignment with DUL ontology.
This DUL alignment does not yet reflect the recent change to the namespace of DUL itself.
Please see section for more information.
The movement of Sensor to become a direct subclass of dul:Object has been discussed but postponed by the Working Group
A thorough check on annotation properties is yet to be made.
One of the major issues practitioners raised with the Semantic Sensor Network Ontology as defined in the XG is its complexity, partly due to the layering underneath the DOLCE UltraLite Upperlevel ontology. This section explains the rationale and method for modularisation of the SSN.
Ontology modularisation is a common method investigated in ontology engineering to segment an ontology into smaller parts. In general, ontology modularization aims at providing users of ontologies with the knowledge they require, reducing the scope as much as possible to what is strictly necessary in a given use case. Two main categories of ontology modularization can be distinguished.
The first category comprises of approaches that focus on the
composition of existing ontologies by means of integrating and mapping
ontologies, most commonly through owl:import
statements.
OWL import has a direction from a source ontology to a target ontology,
and although it is transitive, it only supports knowledge propagation in
one direction, i.e. the importing ontology captures all the meaning of
the imported terms used, i.e., it includes all axioms relevant to the
meaning of these terms, however, the imported ontology may not capture
any of the semantics of the importing ontology.
The second category comprises of mapping approaches that aim to partition and extract parts of ontologies as modules. These mapping approaches are not necessarily directional, but most approaches of ontology extraction rely on directionality of the imported modules. In fact in [Cuenca Grau et al 2009] it has been proven that in OWL DL, which is a syntactical variant of the Description Logic SHOIN, checking whether an ontology is in fact a module of an ontology given a vocabulary is an undecidable problem. However, the main feature of an ontology module under the second category is that it is self-contained, i.e., the module captures the meaning of the imported terms used by including all axioms relevant to the meaning of these terms. This means, that the result of certain reasoning tasks such as subsumption or query answering within a single module should be possible and result in the same answers without the need to access other modules of the ontology.
In order to ensure this property, a solution has to be found for concepts in the ontology module that inherit object properties from concepts that are not in the module. One solution proposed by [Cuenca Grau et al] is to include the bottom concept for all such missing concepts. Another solution is to change the domain and range of an object property. Our modularisation approach uses two different methods depending on the directionality of the segmentation.
Figure 1 gives an overview of the modules of the SSN ontology. The
layering of the rings represents two methods of segmentation we
distinguish, horizontal and vertical segmentation, as follows:
Vertical modules are build upon each other, i.e. they directionally owl:import
lower level modules. If a higher level module is used without importing
its lower levels it may lead to inconsistencies or at least it will lead
to different answers when reasoning over the module compared to
reasoning over its complete stack of vertical ontology modules. However,
lower level modules are independent of their higher level modules and
logically consistent.
For example, the Dolce-UltraLite Alignment ontology imports the Sensor and Sensing Device Core and the Sensor Network Module. However, in reverse, neither the Sensor and Sensing Device Core nor the Sensor Network Module imports the Dolce-UltraLite Alignment ontology. This makes the Sensor and Sensing Device Core, with its lightweight RDF(s) semantics, truly independent of vertical modules that add more expressivity and further ontological commitments.
Note that higher level here is not to be confused with upper level ontologies. Upper level ontologies are general knowledge ontologies that can be directionally imported in many domains, whereas our definition of higher level ontologies here refers to an ontology that extends one or several ontology modules to capture a larger part of a knowledge domain and/or combine knowledge domains.
Modules that are horizontally layered do not depend on each other, i.e.
they do not rely on the owl:import
of another horizontal
module to lead to the same answers when reasoning over the module itself
as opposed to reasoning over an imported horizontal module. If a concept
in a module is connected to a concept in another horizontally layered
module through a directional property such as a subClassOf relation or
any asymmetric property, the range concept of such a relation has to be
included in the module using the URI of the concept as it is defined in
the other module.
For example, if the Sensor Network Ontology module introduces or
semantically refines an madeObservation
property that
links a Sensor
to an Observation
, but the Observation
class is further refined in the O&M module, the Observation
class needs to be introduced in the Sensor Network Ontology using the
URI of the Observation
class defined in the O&M
module, e.g. http://www.w3.org/ns/ssn/oml/Observation.
The modularisation as defined below does not reflect the modularisation that is presented here. For example, it is intended that the Sensor and Sensing Device core is an RDF(s)-only vocabulary with modular extensions supporting both expanded terms and expanded expressiveness in the ontology language.
Documentation in this section has been adapted from that generated by LODE from the current version of SSN ontology. The document will likely be changed to reflect the developments outlined in the work plan the SSN working group.
http://www.w3.org/ns/ssn/Accuracy
The closeness of agreement between the value of an observation and the true value of the observed quality.
http://www.w3.org/ns/ssn/BatteryLifetime
Total useful life of a battery.
http://www.w3.org/ns/ssn/Condition
Used to specify ranges for qualities that act as conditions on a system/sensor's operation. For example, wind speed of 10-60m/s is expressed as a condition linking a quality, wind speed, a unit of measurement, metres per second, and a set of values, 10-60, and may be used as the condition on a MeasurementProperty, for example, to state that a sensor has a particular accuracy in that condition.
http://www.w3.org/ns/ssn/Deployment
The ongoing Process of Entities (for the purposes of this ontology, mainly sensors) deployed for a particular purpose. For example, a particular Sensor deployed on a Platform, or a whole network of Sensors deployed for an observation campaign. The deployment may have sub processes, such as installation, maintenance, addition, and decomissioning and removal.
http://www.w3.org/ns/ssn/DeploymentRelatedProcess
Place to group all the various Processes related to Deployment. For example, as well as Deplyment, installation, maintenance, deployment of further sensors and the like would all be classified under DeploymentRelatedProcess.
http://www.w3.org/ns/ssn/DetectionLimit
An observed value for which the probability of falsely claiming the absence of a component in a material is Î², given a probability Î± of falsely claiming its presence.
http://www.w3.org/ns/ssn/Device
A device is a physical piece of technology - a system in a box. Devices may of course be built of smaller devices and software components (i.e. systems have components).
http://www.w3.org/ns/ssn/Drift
A, continuous or incremental, change in the reported values of observations over time for an unchanging quality.
http://www.w3.org/ns/ssn/FeatureOfInterest
A feature is an abstraction of real world phenomena (thing, person, event, etc).
http://www.w3.org/ns/ssn/MaintenanceSchedule
Schedule of maintenance for a system/sensor in the specified conditions.
http://www.w3.org/ns/ssn/MeasurementCapability
Collects together measurement properties (accuracy, range, precision, etc) and the environmental conditions in which those properties hold, representing a specification of a sensor's capability in those conditions. The conditions specified here are those that affect the measurement properties, while those in OperatingRange represent the sensor's standard operating conditions, including conditions that don't affect the observations.
http://www.w3.org/ns/ssn/MeasurementProperty
An identifiable and observable characteristic of a sensor's observations or ability to make observations.
http://www.w3.org/ns/ssn/MeasurementRange
The set of values that the sensor can return as the result of an observation under the defined conditions with the defined measurement properties. (If no conditions are specified or the conditions do not specify a range for the observed qualities, the measurement range is to be taken as the condition for the observed qualities.)
http://www.w3.org/ns/ssn/MeasurementFrequency
The smallest possible time between one observation and the next.
http://www.w3.org/ns/ssn/MeasurementLatency
The time between a request for an observation and the sensor producing a result (not including network latency to retrieve the result, just time from request to measurement.).
http://www.w3.org/ns/ssn/Observation
An Observation is a Situation in which a Sensing method has been used to estimate or calculate a value of a Property of a FeatureOfInterest. Links to Sensing and Sensor describe what made the Observation and how; links to Property and Feature detail what was sensed; the result is the output of a Sensor; other metadata details times etc.
http://www.w3.org/ns/ssn/ObservationValue
The value of the result of an Observation. An Observation has a result which is the output of some sensor, the result is an information object that encodes some value for a Feature.
http://www.w3.org/ns/ssn/OperatingPowerRange
Power range in which system/sensor is expected to operate.
http://www.w3.org/ns/ssn/OperatingProperty
An identifiable characteristic of the environmental and other conditions in which the sensor is intended to operate. May include power ranges, power sources, standard configurations, attachments and the like.
http://www.w3.org/ns/ssn/OperatingRange
The environmental conditions and characteristics of a system/sensor's normal operating environment. Can be used to specify for example the standard environmental conditions in which the sensor is expected to operate (a Condition with no OperatingProperty), or how the environmental and other operating properties relate: i.e., that the maintenance schedule or power requirements differ according to the conditions.
http://www.w3.org/ns/ssn/Platform
An Entity to which other Entities can be attached - particuarly Sensors and other Platforms. For example, a post might act as the Platform, a bouy might act as a Platform, or a fish might act as a Platform for an attached sensor.
http://www.w3.org/ns/ssn/Precision
The closeness of agreement between replicate observations on an unchanged or similar quality value: i.e., a measure of a sensor's ability to consitently reproduce an observation.
http://www.w3.org/ns/ssn/Property
An observable Quality of an Event or Object. That is, not a quality of an abstract entity as is also allowed by DUL's Quality, but rather an aspect of an entity that is intrinsic to and cannot exist without the entity and is observable by a sensor.
http://www.w3.org/ns/ssn/Resolution
The smallest difference in the value of a quality being observed that would result in perceptably different values of observation results.
http://www.w3.org/ns/ssn/ResponseTime
The time between a (step) change inthe value of an observed quality and a sensor (possibly with specified error) 'settling' on an observed value.
http://www.w3.org/ns/ssn/Selectivity
Selectivity is a property of a sensor whereby it provides observed values for one or more qualities such that the values of each quality are independent of other qualities in the phenomenon, body, or substance being investigated.
http://www.w3.org/ns/ssn/Sensing
The description of a process (i.e. describes the temporal and dataflow dependencies and relationships amongst its parts) that results in the estimation, or calculation, of the value of a phenomenon.
http://www.w3.org/ns/ssn/SensingDevice
A sensing device is a device that implements sensing.
http://www.w3.org/ns/ssn/Sensitivity
Sensitivity is the quotient of the change in a result of sensor and the corresponding change in a value of a quality being observed.
http://www.w3.org/ns/ssn/Sensor
A sensor can do (implements) sensing: that is, a sensor is any entity that can follow a sensing method and thus observe some Property of a FeatureOfInterest. Sensors may be physical devices, computational methods, a laboratory setup with a person following a method, or any other thing that can follow a Sensing Method to observe a Property.
http://www.w3.org/ns/ssn/SensorDataSheet
A data sheet records properties of a sensor. A data sheet might describe for example the accuracy in various conditions, the power use, the types of connectors that the sensor has, etc. Generally a sensor's properties are recorded directly (with hasMeasurementCapability, for example), but the data sheet can be used for example to record the manufacturers specifications verses observed capabilites, or if more is known than the manufacturer specifies, etc. The data sheet is an information object about the sensor's properties, rather than a direct link to the actual properties themselves.
http://www.w3.org/ns/ssn/SensorOutput
A sensor outputs a piece of information (an observed value), the value itself being represented by an ObservationValue.
http://www.w3.org/ns/ssn/Stimulus
An Event in the real world that 'triggers' the sensor. The properties associated to the stimulus may be different to eventual observed property. It is the event, not the object that triggers the sensor.
http://www.w3.org/ns/ssn/SurvivalProperty
An identifiable characteristic that represents the extent of the sensors useful life. Might include for example total battery life or number of recharges, or, for sensors that are used only a fixed number of times, the number of observations that can be made before the sensing capability is depleted.
http://www.w3.org/ns/ssn/SurvivalRange
The conditions a sensor can be exposed to without damage: i.e., the sensor continues to operate as defined using MeasurementCapability. If, however, the SurvivalRange is exceeded, the sensor is 'damaged' and MeasurementCapability specifications may no longer hold.
http://www.w3.org/ns/ssn/System
System is a unit of abstraction for pieces of infrastructure (and we largely care that they are) for sensing. A system has components, its subsystems, which are other systems.
http://www.w3.org/ns/ssn/SystemLifetime
Total useful life of a sensor/system (expressed as total life since manufacture, time in use, number of operations, etc.).
http://www.w3.org/ns/ssn/attachedSystem
Relation between a Platform and any Systems (e.g., Sensors) that are attached to the Platform.
http://www.w3.org/ns/ssn/deployedOnPlatform
Relation between a deployment and the platform on which the system was deployed.
http://www.w3.org/ns/ssn/deployedSystem
Relation between a deployment and the deployed system.
http://www.w3.org/ns/ssn/deploymentProcessPart
Has part relation between a deployment process and its constituent processes.
http://www.w3.org/ns/ssn/detects
A relation from a sensor to the Stimulus that the sensor can detect. The Stimulus itself will be serving as a proxy for (see isProxyOf) some observable property.
http://www.w3.org/ns/ssn/featureInObservation
http://www.w3.org/ns/ssn/featureOfInterest
A relation between an observation and the entity whose quality was observed. For example, in an observation of the weight of a person, the feature of interest is the person and the quality is weight.
http://www.w3.org/ns/ssn/forProperty
A relation between some aspect of a sensing entity and a property. For example, from a sensor to the properties it can observe, or from a deployment to the properties it was installed to observe. Also from a measurement capability to the property the capability is described for. (Used in conjunction with ofFeature).
http://www.w3.org/ns/ssn/hasDeployment
Relation between a System and a Deployment, recording that the System/Sensor was deployed in that Deployment.
http://www.w3.org/ns/ssn/hasMeasurementCapability
Relation from a Sensor to a MeasurementCapability describing the measurement properties of the sensor.
http://www.w3.org/ns/ssn/hasMeasurementProperty
Relation from a MeasurementCapability to a MeasurementProperty. For example, to an accuracy (see notes at MeasurementCapability).
http://www.w3.org/ns/ssn/hasOperatingProperty
Relation from an OperatingRange to a Property. For example, to a battery lifetime.
http://www.w3.org/ns/ssn/hasOperatingRange
Relation from a System to an OperatingRange describing the normal operating environment of the System.
http://www.w3.org/ns/ssn/hasProperty
The chain here ensures that the observed property of an observation is a property of the feature of interest. This restriction is written in O&M; here we can enforce it formally. The more obvious formulation: featureOfInterest o hasProperty SubPropertyOf observedProperty can't be used, because (by the OWL2 decidability restrictions) that would mean cardinality restrictions couldn't be applied to observedProperty (see definition of Observation).
http://www.w3.org/ns/ssn/hasSubSystem
Haspart relation between a system and its parts.
http://www.w3.org/ns/ssn/hasSurvivalProperty
Relation from a SurvivalRange to a Property describing the survial range of a system. For example, to the temperature extreme that a system can withstand before being considered damaged.
http://www.w3.org/ns/ssn/hasSurvivalRange
A Relation from a System to a SurvivalRange.
http://www.w3.org/ns/ssn/hasValue
http://www.w3.org/ns/ssn/implementedBy
A relation between the description of an algorithm, procedure or method and an entity that implements that method in some executable way. For example, between a scientific measuring method and a sensor the senses via that method.
http://www.w3.org/ns/ssn/implements
A relation between an entity that implements a method in some executable way and the description of an algorithm, procedure or method. For example, between a Sensor and the scientific measuring method that the Sensor uses to observe a Property.
http://www.w3.org/ns/ssn/inCondition
Describes the prevailing environmental conditions for MeasurementCapabilites, OperatingConditions and SurvivalRanges. Used for example to say that a sensor has a particular accuracy in particular conditions. (see also MeasurementCapability)
http://www.w3.org/ns/ssn/inDeployment
Relation between a Platform and a Deployment, recording that the object was used as a platform for a system/sensor for a particular deployment: as in this PhysicalObject is acting as a Platform inDeployment Deployment.
http://www.w3.org/ns/ssn/isProducedBy
Relation between a producer and a produced entity: for example, between a sensor and the produced output.
http://www.w3.org/ns/ssn/isPropertyOf
Relation between a FeatureOfInterest and a Property (a Quality observable by a sensor) of that feature.
http://www.w3.org/ns/ssn/isValueOf
http://www.w3.org/ns/ssn/isProxyFor
A relation from a Stimulus to the Property that the Stimulus is serving as a proxy for. For example, the expansion of the quicksilver is a stimulus that serves as a proxy for temperature, or an increase or decrease in the spinning of cups on a wind sensor is serving as a proxy for wind speed.
http://www.w3.org/ns/ssn/madeObservation
Relation between a Sensor and Observations it has made.
http://www.w3.org/ns/ssn/observationResult
Relation linking an Observation (i.e. a description of the context, the Situation, in which the observatioin was made) and a Result, which contains a value representing the value associated with the observed Property.
http://www.w3.org/ns/ssn/observationResultTime
The result time shall describe the time when the result became available, typically when the procedure associated with the observation was completed For some observations this is identical to the phenomenonTime. However, there are important cases where they differ.[O&M]
http://www.w3.org/ns/ssn/observationSamplingTime
Rebadged as phenomenon time in [O&M]. The phenomenon time shall describe the time that the result applies to the property of the feature-of-interest. This is often the time of interaction by a sampling procedure or observation procedure with a real-world feature.
http://www.w3.org/ns/ssn/observedProperty
Relation linking an Observation to the Property that was observed. The observedProperty should be a Property (hasProperty) of the FeatureOfInterest (linked by featureOfInterest) of this observation.
http://www.w3.org/ns/ssn/observes
http://www.w3.org/ns/ssn/ofFeature
A relation between some aspect of a sensing entity and a feature. For example, from a sensor to the features it can observe properties of, or from a deployment to the features it was installed to observe. Also from a measurement capability to the feature the capability is described for. (Used in conjunction with forProperty).
http://www.w3.org/ns/ssn/onPlatform
Relation between a System (e.g., a Sensor) and a Platform. The relation locates the sensor relative to other described entities entities: i.e., the Sensor s1's location is Platform p1. More precise locations for sensors in space (relative to other entities, where attached to another entity, or in 3D space) are made using DOLCE's Regions (SpaceRegion).
http://www.w3.org/ns/ssn/produces
The chain here means that if a sensor made an observation and that observation has a result, then the result is the one produced by the sensor. Just ensures that the sensor and the resulting observation agree on the result.
http://www.w3.org/ns/ssn/qualityOfObservation
Relation linking an Observation to the adjudged quality of the result. This is of course complimentary to the MeasurementCapability information recorded for the Sensor that made the Observation.
http://www.w3.org/ns/ssn/sensingMethodUsed
A (measurement) procedure is a detailed description of a measurement according to one or more measurement principles and to a given measurement method, based on a measurement model and including any calculation to obtain a measurement result [VIM 2.6]
http://www.w3.org/2000/01/rdf-schema#comment
http://purl.org/dc/terms/created
http://purl.org/dc/elements/1.1/creator
http://purl.org/dc/elements/1.1/date
http://purl.org/dc/elements/1.1/identifier
http://www.w3.org/2000/01/rdf-schema#isDefinedBy
http://www.w3.org/2000/01/rdf-schema#label
http://creativecommons.org/ns#license
http://purl.org/dc/terms/modified
http://purl.org/dc/elements/1.1/rights
http://www.w3.org/2000/01/rdf-schema#seeAlso
http://purl.org/dc/elements/1.1/source
http://purl.org/dc/elements/1.1/title
This section identifies work that is planned to be done in the next iteration of the document. Comment on these topics and their priority is invited.
Check and reconsider or redesign modularisation of SSN. See proposal in charter: noting the work to split the ontology into smaller sections to offer simplified access
Modularisation of SSN might work like some of the following suggestions under discussion
How do we replace those components of dul that seem to be core to ssn if dul is not being used?
What goes in SSN and what should be just a recommended profile/extract/extension? These could include e.g. WoT? Iot-lite? satellite sensors? samples? human sensors? Or do we just advise how to do this in general?
Given the distinction between records and events, ssn:Observation is not the same concept as om:Observation. This arises also in alignment with PROV-O
Align SSN with PROV-O
Two such alignments have already been published in the literature. One proposal functions mostly rather like the alignment to DUL as described above in form, but some rather useful SWRL is also used.
Is it ok to use SWRL, too, for this? Or would it be better to make some bigger changes to SSN to align with PROV-O?
Is the provenance requirement in scope?
Align SSN with RDF datacube
This alignment is necessary, at least, for the common use case of sensored time-series. There are a few examples in the literature, but it is suggested that some structural change to core SSN is needed to make this work. This needs to be considered in the context of the DUL disentanglement above because the encoding of measured values is important here. Observed properties also need to be checked.SSN for IoT devices
This could be achieved by defining a small SSN module that is suitable for small devices; by adopting IoT-lite or some other IoT ontology with a well-defined relationship to SSN (ie a formalised alignment). There are suggestions to reduce memory by short uris and labels (and annotations?), too.In this context actuation is a clear need and should be considered.
The user should be able to understand the network resource cost of proposed instructions (for example, power required per measurement, current battery life, latency before instructions can be executed). These qualities could be interpreted by the scientist user directly, or by an automated agent aiming to optimize network efficiency through resource scheduling and optimisation algorithms.
Align SSN with the ontology developed for the coverage deliverable
We would like to show that the sensors that observe coverage (commonly satellite, but could be in-situ ground-based sensors) can be described using SSN while their observations can be described via the SDW coverage deliverable.Extend SSN to cover requirements identified in our UCR
These should be done by optional extensions to SSN, in the style of the optional DUL alignment above, so as to minimally impact existing users and to avoid overcrowding of the core. The requirements are recorded in the UCR documentAlign SSN to implement Best Practices as defined in our BP deliverable.
In particular, the modelling of time and space should concur. SSN should tighten its modelling of location. There are relevant UCR requirements for this.Extend SSN to to cover requirements identified in our wish List. These requirements have not been discussed in the group and are subject to prioritisation and resources.
See the Wish list on the Group's wiki. Of those, what is not covered elsewhere in this document is reproduced briefly here. Refer to the wish list for more detail, rationale and possible implementations.Review annotation properties, including multilingual. Fix typos and spelling.
Extend SSN to cover these things https://www.w3.org/2015/spatial/wiki/Working_Use_Cases#Various_Sensor_Use_Cases_.28SSN.29 (Action-25)
This is a note of some proposed documentation, resources permitting.


public interface Matches
| Modifier and Type | Method and Description |
|---|---|
default String |
checkSelectedOption(String expectedPattern,
double waitFor,
double timeTook)
Checks that the element's selected option matches the regular expression pattern
provided.
|
default String |
checkSelectedValue(String expectedPattern,
double waitFor,
double timeTook)
Checks that the element's selected value matches the regular expression pattern
provided.
|
default String |
checkText(int row,
int col,
String pattern,
double waitFor,
double timeTook)
Checks that the element's pattern in a particular cell matches the regular expression
pattern provided.
|
default String |
checkText(String expectedPattern,
double waitFor,
double timeTook)
Checks that the element's text matches the regular expression pattern provided.
|
default String |
checkValue(String expectedPattern,
double waitFor,
double timeTook)
Checks that the element's value matches the regular expression pattern
provided.
|
default double |
elementPresent(double seconds)
Performs a simple check for the element to be present.
|
default String[] |
getAttributes(String attribute,
String expected,
double waitFor)
Retrieves all attributes of an element, and writes out the action and expected
result of checking for one particular attribute.
|
Element |
getElement()
Retrieves the element that is used for all selenium actions and checks
|
OutputFile |
getOutputFile()
Retrieves the output file that we write all details out to
|
default String |
getValue(String value,
String expected,
double waitFor)
Retrieves the value from the element, and writes out the action and value that is
being expected.
|
default boolean |
isInput(double waitFor)
Determines if the element is an input element, and if it is not writes a failure out to the detailed log
|
default boolean |
isPresent(double waitFor)
Determines if the element is present, and if it is not writes a failure out to the detailed log
|
default boolean |
isPresentInput(String expected,
double waitFor)
Determines if the element is a present, and if it is, it is an input.
|
default boolean |
isPresentSelect(String expected,
double waitFor)
Determines if the element is a present, and if it is, it is a select.
|
default boolean |
isPresentTable(String expected,
double waitFor)
Determines if the element is a present, and if it is, it is a table.
|
default boolean |
isSelect(double waitFor)
Determines if the element is a select element, and if it is not writes a failure out to the detailed log
|
default boolean |
isTable(double waitFor)
Determines if the element is a table element, and if it is not writes a failure out to the detailed log
|
void |
selectedOption(String expectedPattern)
Checks that the element's selected option matches the regular expression pattern
provided.
|
void |
selectedValue(String expectedPattern)
Checks that the element's selected value matches the regular expression pattern
provided.
|
void |
text(int row,
int col,
String pattern)
Checks that the element's pattern in a particular cell matches the regular expression
pattern provided.
|
void |
text(String expectedPattern)
Checks that the element's text matches the regular expression pattern provided.
|
void |
value(String expectedPattern)
Checks that the element's value matches the regular expression pattern
provided.
|
void text(String expectedPattern)
expectedPattern
- - the expected pattern of the text of the elementdefault String checkText(String expectedPattern, double waitFor, double timeTook)
expectedPattern
- - the expected pattern of the text of the elementwaitFor
- - if waiting, how long to wait for (set to 0 if no wait is desired)timeTook
- - the amount of time it took for wait for something (assuming we had to wait)void text(int row, int col, String pattern)
row
- - the number of the row in the table - note, row numbering
starts at 1, NOT 0col
- - the number of the column in the table - note, column
numbering starts at 1, NOT 0pattern
- - what pattern do we expect to be in the table celldefault String checkText(int row, int col, String pattern, double waitFor, double timeTook)
row
- - the number of the row in the table - note, row numbering
starts at 1, NOT 0col
- - the number of the column in the table - note, column
numbering starts at 1, NOT 0pattern
- - what pattern do we expect to be in the table cellwaitFor
- - if waiting, how long to wait for (set to 0 if no wait is desired)timeTook
- - the amount of time it took for wait for something (assuming we had to wait)void value(String expectedPattern)
expectedPattern
- the expected input value of the elementdefault String checkValue(String expectedPattern, double waitFor, double timeTook)
expectedPattern
- the expected input value of the elementwaitFor
- - if waiting, how long to wait for (set to 0 if no wait is desired)timeTook
- - the amount of time it took for wait for something (assuming we had to wait)void selectedOption(String expectedPattern)
expectedPattern
- the expected input text of the elementdefault String checkSelectedOption(String expectedPattern, double waitFor, double timeTook)
expectedPattern
- the expected input text of the elementwaitFor
- - if waiting, how long to wait for (set to 0 if no wait is desired)timeTook
- - the amount of time it took for wait for something (assuming we had to wait)void selectedValue(String expectedPattern)
expectedPattern
- the expected input value of the elementdefault String checkSelectedValue(String expectedPattern, double waitFor, double timeTook)
expectedPattern
- the expected input value of the elementwaitFor
- - if waiting, how long to wait for (set to 0 if no wait is desired)timeTook
- - the amount of time it took for wait for something (assuming we had to wait)OutputFile getOutputFile()
Element getElement()
default boolean isPresent(double waitFor)
default boolean isInput(double waitFor)
default boolean isSelect(double waitFor)
default boolean isTable(double waitFor)
default boolean isPresentInput(String expected, double waitFor)
expected
- - the expected outcomedefault boolean isPresentSelect(String expected, double waitFor)
expected
- - the expected outcomedefault boolean isPresentTable(String expected, double waitFor)
expected
- - the expected outcomedefault String[] getAttributes(String attribute, String expected, double waitFor)
attribute
- - the attribute to check forexpected
- - is the attribute expected to be present, or not presentdefault String getValue(String value, String expected, double waitFor)
value
- the expected value of the elementexpected
- - is the attribute expected to be present, or not presentdefault double elementPresent(double seconds)
seconds
- - how many seconds to wait forCopyright © 2019. All rights reserved.


It's usually good to offer 3 options for pricing. It's also a good practice to provide visual clarification for the best deal.
Free $0/month
One account
Up to 1G text storage
No image storage
$59/mo $300/quarter
Up to 5 accounts
Up to 2G text storage
Up to 10G image storage
BEST VALUE
$199/mo $999/quarter
Unlimited accounts
Up to 5TB text storage
Up to 25TB image storage


This file defines an abstract base class, CiceroRestABC, and an inheriting class, CiceroRestConnection. The methods in CiceroRestConnection correspond to all the endpoints in the Cicero API. These methods use the API request methods in CiceroRestABC to wrap the API and get data back.
import urllib
import urllib2
try:
import json
except ImportError:
import simplejson as json
from cicero_endpoint_constants import *
from cicero_response_classes import *
from cicero_errors import *
This is an Abstract Base Class for the CiceroRestConnection class. Methods in CiceroRestConnection for the various API endpoints use the _compose_request_url() and _submit_request() methods defined here to perform the mechanics of composing a Cicero API url, requesting it, and receiving a JSON response.
class CiceroRestABC(object):
Given a Cicero API endpoint (defined in cicero_endpoint_constants.py) and zero or any number of keyword arguments (ie, API search parameters, enumerated in the Cicero documentation), this method encodes those arguments/parameters and composes an API request url with endpoint, user id, token, and parameters.
def _compose_request_url(self, ENDPOINT, kwargs):
save id if present and add to the base URL, it is treated differently
if 'id' in kwargs:
object_id = kwargs.pop('id')
request_url = (ENDPOINT + '/' + str(object_id) + '?user=' +
str(self.user_id) + '&token=' + str(self.token) +
'&f=json&')
else:
request_url = (ENDPOINT + '?user=' + str(self.user_id) + '&token=' +
str(self.token) + '&f=json&')
query_params = urllib.urlencode(kwargs, True)
request_url += query_params
return request_url
Given a request_url composed with the _compose_request_url() method, this method requests the URL from the Cicero API and returns the JSON response as a RootCiceroObject (defined in cicero_response_classes.py) if successful.
If the Cicero API raises an error (a urllib2.HTTPError), the resulting JSON (with error message from the API) and the HTTP status code are returned and raised as a CiceroError (defined in cicero_errors.py).
If python-cicero cannot communicate with the Cicero API (a urllib2.URLError), a NetworkError (defined in cicero_errors.py) with a urllib2.URLError.reason is raised.
def _submit_request(self, request_url):
request = urllib2.Request(request_url)
request.add_header('User-Agent', 'Cicero_Python_Wrapper')
try:
response = urllib2.urlopen(request)
blob = response.read()
json_dict = json.loads(blob)
return RootCiceroObject(json_dict)
except urllib2.HTTPError, e:
error_blob = e.read()
error_dict = json.loads(error_blob)
error_dict['status_code'] = e.code
raise CiceroError(error_dict)
except urllib2.URLError, e:
raise NetworkError("Unable to communicate with the Cicero API.\n"
" Please check you are connected to the network. \n"
" More info is below: \n"
" Reason: ", e.reason)
This class authenticates with the Cicero API and has methods to support various Cicero ReST endpoints.
User authentication and calls to Cicero's /token/new.json endpoint is handled in the init method of this class. If you get an error that your token has expired, simply recreate/create a new class instance with your username and password again, or re-execute your object's init method, and the token will be "refreshed".
If you need to, you can access your username, password, numerical Cicero User ID, or current token with this class's attributes:
Most methods can take any number of optional keyword arguments (**kwargs). These are the same as discussed in the Cicero documentation and the "Arguments allowed in query" listed on each Cicero API endpoint's docs page. This class will "urlencode" these optional arguments from what they are in Python to standard URL query string parameters. So, you don't need to worry about doing that.
Just make sure that they're valid Python arguments, like so:
Most arguments you use should be strings or integers.
Location based queries require location information. At a minimum, either a street address, latitude and longitude (x/y) point, OR a fully-qualified US, Canadian, or UK zip code and country code. See [the Cicero API docs] (http://cicero.azavea.com/docs/query_by_location.html#querying-by-address) for more info.
Additionally, the Cicero API allows wildcard, OR, and boolean queries. (see https://cicero.azavea.com/docs/query.html for more info) Python does not allow repeated keyword arguments to functions. To query Cicero with an OR condition (which requires repeated arguments), use one keyword but place your values in a sequence (a tuple or list), like so:
To query Cicero with a boolean, use a string as you would in a URL, rather than an actual Python boolean True/False value. Like so:
Wildcards can be done with an asterisk(s) in the string, like this:
class CiceroRestConnection(CiceroRestABC):
We initialize the CiceroRestConnection class with a username and password. These are then encoded as POST data, and POSTED to the TOKEN_ENDPOINT. The response contains a numerical User ID and a token, (stored in self.user_id and self.token) which we use for subsequent calls to the API.
def __init__(self, username, password):
self.username = username
self.password = password
login_params = urllib.urlencode({
'username': self.username,
'password': self.password
})#TODO: add functionality for API keys in addition to tokens
try:
getting a token is the only POST request in Cicero, so we will POST the login_params rather than concatenating them to the TOKEN_ENDPOINT
token_request = urllib2.Request(TOKEN_ENDPOINT, login_params)
token_response = urllib2.urlopen(token_request).read()
token_json = json.loads(token_response)
self.user_id = token_json['user']
self.token = token_json['token']
except urllib2.HTTPError, e:
token_error_blob = e.read()
token_error_dict = json.loads(token_error_blob)
token_error_dict['status_code'] = e.code
raise CiceroError(token_error_dict)
except urllib2.URLError, e:
raise NetworkError("Unable to communicate with the Cicero API.\n"
" Please check you are connected to the network. \n"
" More info is below: \n"
" Reason: ", e.reason)
Queries the Cicero API's election_event endpoint for information on global election events. See the Cicero API documentation for more info and all valid query arguments.
Currently, calls made to the /election_event endpoint do not consume credits. Consider it a "beta" feature with all the caveats that implies.
def get_election_event(self, **kwargs):
election_event_request_url = self._compose_request_url(ELECTION_EVENT_ENDPOINT, kwargs)
election_event_response = self._submit_request(election_event_request_url)
return election_event_response
Queries the Cicero API's Official endpoint based on a search location, Cicero unique id, or a last name. Queries by id and/or last_name are the only supported queries that do not require a location. See the Cicero API docs for more info and all valid query arguments.
The default sorting order for Officials is alphabetical by last_name.
def get_official(self, **kwargs):
official_request_url = self._compose_request_url(OFFICIAL_ENDPOINT, kwargs)
official_response = self._submit_request(official_request_url)
return official_response
Queries the Cicero API's /legislative_district endpoint for legislative district info based on location, unique id, etc.
See the Cicero API docs for more info and all valid query arguments.
def get_legislative_district(self, **kwargs):
leg_district_request_url = self._compose_request_url(LEGISLATIVE_DISTRICT_ENDPOINT, kwargs)
leg_district_response = self._submit_request(leg_district_request_url)
return leg_district_response
Queries the Cicero API's /nonlegislative_district endpoint for nonlegislative district info based on location, unique id, etc.
See the Cicero API docs for all valid query parameters.
def get_nonlegislative_district(self, **kwargs):
nonleg_request_url = self._compose_request_url(NONLEGISLATIVE_DISTRICT_ENDPOINT, kwargs)
nonleg_request_response = self._submit_request(nonleg_request_url)
return nonleg_request_response
Queries the Cicero API's /map endpoint for an image map of a particular district.
A semi-temporary URL to a hosted map image is always returned, but will be deleted off Azavea's servers every several days. To return base64-encoded text image data also (which you can cache indefinitely), you can use the "include_image_data" query parameter. In Cicero API URLs, this parameter needs no accompanying value (ie: /map/2664?include_image_data or /map/STATE_EXEC/US/PA?fill_color=green&include_image_data ).
However, due to how Python's urllib.urlencode() function handles query parameters, to use the include_image_data parameter with this Python wrapper, you must add an arbitrary value with include_image_data as a key in the keyword arguments you pass to get_map().
We recommend: get_map(include_image_data=1, ...other arguments here...) which will produce: /map?include_image_data=1&other_arguments_here... and happens to work just fine with the Cicero API :-)
For more information on the /map call and other styling parameters, see the Cicero documentation
def get_map(self, **kwargs):
map_request_url = self._compose_request_url(MAP_ENDPOINT, kwargs)
map_request_response = self._submit_request(map_request_url)
return map_request_response
Queries the Cicero API's /district_type endpoint for more information on what possible district types are available in the API and their descriptions. Note not all district types may be available in all geographic areas.
This API call consumes no credits and uses no arguments.
See the Cicero API docs for more info.
def get_district_type(self):
district_type_request_url = (DISTRICT_TYPE_ENDPOINT + '?user=' +
str(self.user_id) + '&token=' +
str(self.token) + '&f=json')
district_type_response = self._submit_request(district_type_request_url)
return district_type_response
Queries the Cicero API's /account/credits_remaining endpoint for information about how many credits a user account has left, when they expire, and an user's overdraft limit.
This API call consumes no credits and uses no arguments.
See the Cicero API docs for more info.
def get_account_credits_remaining(self):
credits_remaining_request_url = (ACCOUNT_CREDITS_REMAINING_ENDPOINT +
'?user=' + str(self.user_id) +
'&token=' + str(self.token) + '&f=json')
credits_remaining_response = self._submit_request(credits_remaining_request_url)
return credits_remaining_response
Queries the Cicero API's /account/usage endpoint for information about how many credits a user account has used by month and API call type for a given period of time.
This API call consumes no credits.
The first_time argument is required, but the second_time argument (for querying usage history over a range of years/months) is optional. You may pass straight strings or use the keywords. If both time arguments are used without keywords, the earlier time must come before the later time. IE, Pythonic rules about arguments apply.
1. get_account_usage(first_time="YYYY") or get_account_usage("YYYY"):
will return all available usage history in the given year.
2. get_account_usage(first_time="YYYY-MM") or get_account_usage("YYYY-MM"):
will return all available usage history in the given month.
3. get_account_usage(first_time="YYYY-MM", second_time="YYYY-MM")
get_account_usage(first_time="YYYY-MM", second_time="YYYY")
get_account_usage(first_time="YYYY", second_time="YYYY-MM")
get_account_usage(first_time="YYYY", second_time="YYYY")
get_account_usage("2013-01", "2013-05")
get_account_usage("2012-11", "2013")
get_account_usage("2012", "2013-05")
get_account_usage("2012", "2013")
any of these will return usage history within the given timeframe.
See the Cicero API docs for more info.
def get_account_usage(self, first_time, second_time=""):
if not second_time:
account_usage_request_url = (ACCOUNT_USAGE_ENDPOINT + '/' +
first_time +
'?user=' + str(self.user_id) +
'&token=' + str(self.token) +
'&f=json')
else: # second_time != ""
account_usage_request_url = (ACCOUNT_USAGE_ENDPOINT + '/' +
first_time + '/to/' + second_time +
'?user=' + str(self.user_id) +
'&token=' + str(self.token) +
'&f=json')
account_usage_response = self._submit_request(account_usage_request_url)
return account_usage_response
Queries Cicero to determine the current API version being used. Note, the version that all of the ENDPOINT constants use is hardcoded into their URLs in the cicero_endpoint_constants.py file.
This API call consumes no credits and uses no arguments.
See the Cicero docs for more info.
def get_version(self):
version_request_url = VERSION_ENDPOINT + '?f=json'
version_response = self._submit_request(version_request_url)
return version_response


Integration Test Summary
Total
@test.cnt@
Skipped
@skipped.test.cnt@ | @skipped.test.pct@%
Failed
@failed.test.cnt@ | @failed.test.pct@%
Successful
@success.test.cnt@ | @success.test.pct@%
Tests results (@test.cnt@ Tests)
@test.results@


Thread 25 "komodo-miner" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fffbdffb700 (LWP 15664)]
0x00007ffff745007a in std::_Rb_tree_insert_and_rebalance(bool, std::_Rb_tree_node_base*, std::_Rb_tree_node_base*, std::_Rb_tree_node_base&) ()
from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
that help at all?
(edited)


DO NOT PLAY THIS GAME WITH EPILEPSY!
DO NOT PLAY THIS GAME ON A FULL STOMACH.
DO NOT PLAY THIS GAME FOR A PROLONGED TIME.
Select your starting speed:
Fetching resources, please wait...
Controls
| Action | Keyboard |
|---|---|
| shapeshift | 1 - circle, 2 - square, 3 - triangle |
| movement | Press and hold WASD or cursors |
Last Game: 0
Highscore: 0
Credits:
Music by Eric Matyas
www.soundimage.org
www.soundimage.org


Before Change
// Exit recognition if any of the transcribed phrases could be
// one of our keywords.
if any(re.search(r"\b(exit|quit)\b", alt.transcript, re.I)
for result in resp.results
for alt in result.alternatives):
print("Exiting..")
break
After Change
if resp.error.code != code_pb2.OK:
raise RuntimeError("Server error: " + resp.error.message)
if not resp.results:
continue
// Display the top transcription
result = resp.results[0]
transcript = result.alternatives[0].transcript
// Display interim results, but with a carriage return at the end of the
// line, so subsequent lines will overwrite them.
if not result.is_final:
// If the previous result was longer than this one, we need to print
// some extra spaces to overwrite the previous result
overwrite_chars = " " * max(0, num_chars_printed - len(transcript))
sys.stdout.write(transcript + overwrite_chars + "\r")
sys.stdout.flush()
num_chars_printed = len(transcript)
else:
print(transcript)
// Exit recognition if any of the transcribed phrases could be
// one of our keywords.
if re.search(r"\b(exit|quit)\b", transcript, re.I):


I am an enthusiastic and highly motivated recent masters graduate pursuing a career in IT. Although my degree is in engineering, a career in IT is a more attractive prospect as the information technology sector is forever changing as well as it also overlapping in to many different industries, giving you the chance to work in a variety of job fields which really intrigues me.
During the Python course I learnt the syntax, logic and data structure of python. The week-long course of Python was the first time I used any programming software. I covered various aspects of Python such as variables and methods, as well as conditional statements like if, else, for and while. I incorporated these conditional statements with logical operators to code problems we were assigned.
The knowledge obtained from the week we spent on Python was a great introduction to Java, in better understanding the logic of programming. Java focused more on object orientated programming. The main four principles we focused on object orientated programming where abstraction, encapsulation, inheritance and polymorphism. We also covered J unit testing and test driven development(TDD). All the knowledge we acquired was put in to use through various different exercises, one of them being creating a simple treasure hunt game, where we used a 2-dimensional array to create our map.
For the database aspect of our training we completed a number of tasks using MySQL, one of them being creating tables for QA directors, consultants and trainers, to book rooms, courses and to have an updated record of which trainer is teaching which course and which consultant is taking which course. The various tables where connected using primary and foreign keys using entity relationship diagrams(ERD). We also learnt MongoDB commands to create databases as well as commands to return specific documents in a particular collection based on certain fields. Continuous integration training started off with creating a Linux virtual machine and becoming familiar with the terminal commands and scripts. We also used the building tool Maven and the continuous integration tool Jenkins to test a java application.
To be completed...
One of my biggest interests is football; I often play five a side games with my friends every other weekend, which I really enjoy mainly because of the teamwork aspect. I am also a massive boxing fan, my favourite fighter at the moment is Anthony Joshua, I watched him win gold at the Olympics to then three years later become the IBF heavy weight champion of the world. I also used to volunteer at a youth club I attended in my early teens, it gave me great satisfaction and pride to give back to the place that gave me so much. It also helped develop my leadership and management skills.


account_circle
Profile
verified_user
Account
security
Security
Public Profile
Account Details
Security


|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
JK is a replacement to the elderly mod_jserv. It was a completely new Tomcat-Apache plug-in that handles the communication between Tomcat and Apache. The newest JK2 is a refactoring of JK . The native part has been completly restructured and the configuration has been simplified a lot. JK is more than just an apache module, since it could be used with majors WebServer :
JK was develop to overcome many limitations of its ancestor, mod_jserv . mod_jserv was too complex and because it was ported from Apache/JServ, it brought with it lots of JServ specific bits that aren't needed by Apache. Where mod_jserv supported only Apache webservers on Unix OS, JK supports much more web servers and operating systems through via a compatibility layer named the JK library . The layered approach provided by the JK library makes it easier to support many different webservers and OS. JK offer better support for SSL, that's was a problem with mod_jserv which couldn't reliably identify whether a request was made via HTTP or HTTPS. JK can, using the newer Ajpv13 protocol which relay many SSL informations required by servlet 2.2 and 2.3 specs. JK offers a lot of different and flexible communications between a Web Server and the Tomcat Servlet Engine and could be used today with all of the ASF Tomcat Engines, 3.2.x , 3.3.x , 4.0.x , 4.1.x and 5.x
JK2 is a refactoring of JK and is much more powerfull. Even if it works with Apache 1.3, JK2 has been developed with Apache 2.0 in mind, and is better suited for multi-threaded servers like IIS, NES/iPlanet. It can also be embeded in other applications and used from java. JK2 improves the modularity and has a better separation between protocol and physical layer. As such JK2 support fast unix-socket, and could be extended to support others communications channels. It is better suited for JNI and may use (in a future version) JDK 1.4 NIO. There is additional support for monitoring, similar with JMX in java. A module similar with mod_status is provided, and additional adapters can be used to interface and provide status and runtime configuration. . The configuration has been changed to follow the component models. Multiple configuration sources can be supported ( in additon to file ) providing better integration with the embeding application. The config layer uses the management layer APIs and it can support persistence for changes done via runtime configuration. Another feature is the JNI mode. Jk2 can be used as a JNI library and provide access to native features to java. For example it provides access to shared memory ( used for config and monitoring in a multiprocess environment ), unix domain sockets. It can also provide access to signals, chuid, win registry. All using the same communication mechansim, and supporting both in-process and out-of process modes.
The alternative ways are better described in mod_webapp documentation. Check webapp site for it and then decide if you want to go on reading. The big advantage of mod_webapp is that is very easy to configure, has a well defined protocol named WARP , does not care about the old crappy protocols used in Tomcat-3.x and so. But it would be possible to implement the WARP protocol in JK2 ;-)) The disadvantage is that it requires the Apache Portable Runtime which is still only easily available via Apache 2.0 and that it didn't support webservers like IIS, NES/iPlanet or Domino. |


Bootstrap
Home
About Me
Contact Me
More
My First Website!
Website Links!
Google!
Facebook!
w3schools!
Code Academy!
Contact me
If you ever have any questions, my E-mail is sophierosenberg99@gmail.com.


{{ errorMessage }}
* Email must be valid email address. i.e<EMAIL_ADDRESS>If you change new email address, then the email must be confirmed.
* Password must be more than 6 characters.