Naming principles Resources and their Identification

SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 76 of 233 - authority denotes organisations e.g. standardisation organisations such as ISO or OGC, but also projects such as SANY that define the resource identifiers. It is a controlled list defined as follows: authority := EDCS | EPSG | OGC | SI | UCUM | SANY Note: This list is an extension of table 1 of OGC 06-023r1 by adding the authority “SANY”. - version denotes the version of the resource identifier definition as defined by the authority. Note 1: For the authority OGC the version is optional as stated in section 7.2 of OGC 06-023r1: ―The ―version‖ part of these URNs can be omitted when the referenced definition does not have a version, and the referenced definition is not specific to an authority version. When included, the ―version‖ shall be recorded in the format specified by the authority. The version format is sometimes ―N.N.N‖ or ―N.N‖, where each ―N‖ stands for an integer. If no other version identification is provided by the authority, a year or other date can be used. No v or other version prefix shall be included.‖ Note 2: For the authority SANY the version is mandatory when defining a URN and it shall be provided in the format “N.N”, where each “N” stands for an integer. When referring to a URN and the version number is missing, the resource that is associated with the highest version number shall be taken by default. - code denotes a human-readable name that identifies the resource. Note: URN namespaces for OGC and for SANY must not be confused with XML namespaces used in schema documents of the eXtensible Markup Language XML. According to the W3C Recommendation “Namespaces in XML 1.0” http:www.w3.orgTRxml-names , “XML namespaces provide a simple method for qualifying element and attribute names used in XML documents by associating them with namespaces identified by URI references”.

6.5.3 Naming principles

Section 6.5.2 described how resources are identified in a global scope in form of an URN. To guarantee globally unique identifiers it is necessary to set up policies to generate and administer such identifiers. Such a naming policy must take into account that resources in particular sensor nodes in sensor networks have been manufactured by different vendors andor are operated by independent authorities, all with their own, possibly proprietary, resource identification scheme. Thus, global uniqueness of resource identifiers cannot be assumed to have already been achieved in the sensor domain see section 6.2. The only solution is to restrict the scope of such resource identifiers to the sensor network in which they have been uniquely defined. It is then the task of the acquisition domain e.g. an instance of a sensor observation service to guarantee global uniqueness with respect to other services in the acquisition or other domains. The following situation highlights the need for this approach: If more than one service instance provides access to the same set of resource instances and if it is necessary for an SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 77 of 233 application to treat them as one instance e.g. one instance of a sensor, the identifiers of the resource instances shall be globally unique in order to enable the correlation of the resource instances at a higher level. This is illustrated in Figure 6-9 where one resource instance may be accessed through two resource providers A and B. Here, the resource providers are abstractions of the service instances that provide access to the resources. Figure 6-9: Naming requirements for resources A resource may be defined as composite resource, i.e. its identity relies on the identity of other resources. In this case the identifier of a composite resource is defined by a composition of the identifiers of its defining characteristics attributes. Its global uniqueness is then dependent on the global uniqueness of the identifier of its composing identifiers. An important example is the resource observation. According to the Observation and Measurement model see section 7.2 the identifier of an observation is defined as a tuple consisting of the identifier of the feature of interest, the observed property, the procedure see the definition of these terms in section 7.2 and the time of occurrence. Section 4.5 distinguishes between several topologies of sensor service networks. Looking at them from the perspective of how to identify the resources involved, the topologies differ in the relationship between the resource providers and the resources themselves as well as in the cardinalities of this relationship. This has consequences for the requirements about local or global resource identifiers. As an illustrating example let‟s consider a service instance acting as a resource provider to access a sensor e.g. an instance of the Sensor Observation Service SOS, see section 8.2.2. The sensor is specified as a procedure which provides observations according to the SOS information model described in section 7.3. Note: The method by which a resource here: a sensor registers itself to its resource provider here: the SOS instance is outside the scope of the SensorSA because it is specific to a given sensor network solution. Two particular relationships are distinguished: SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 78 of 233 1. The relationship between a procedure and SOS instances There is a single SOS instance that acts as a resource provider to a given procedure. In this case the scope of the procedure is the SOS instance, i.e. there is a 1:1 relationship between a procedure and an SOS instance. Thus, the identifier of the procedure needs only to be unique within that SOS instance. However, depending on the sensor network topology, the procedure may also be connected to other service instances SOS instances or instances of other service types at the same or at different times. Examples are mobile sensors that connect to different stationary SOS instances from time to time. In this case more than one service instance acts as a resource provider for this procedure, i.e. there is a 1:n relationship between a procedure and a service instance. Table 6-3 shows the minimum requirements for the scope of the identifiers that result from the different cardinalities between a resource provider here: SOS instance and a proc edure as a function of the sensor network topologies. A “local” scope of the procedure identifier means that the uniqueness of the identifier is only guaranteed in the context of the SOS instance that acts as a resource provider to access the procedures. Sensor Network Topologies Cardinality SOS Instance : Procedure Scope of Procedure Identifier Sensors and data logger with fixed locations 1:n local Mobile sensors and fixed or mobile data logger n:n global Mobile sensors moving in different sub networks n:n global Mobile sensor cluster on vehicles e.g. on ships - block data transfer on demand 1:n local Mobile earth observation sensors satellite, airborne 1:n local Mobile sensors with their own IP address n:n global Table 6-3: Procedure Identifiers in different Sensor Network Topologies 2. The relationship between an SOS instance and the observations. More than one SOS instance may provide access to the same set of observations. Each SOS instance may access different but possibly overlapping subsets of observations. Thus, basically, there may be a either a 1:n or an m:n relationship between SOS instances and observations. Note that for this relationship the cardinality of this relationship is not a function of the sensor network topologies. As a consequence, the demand for a local or a global scope for the observation identifier is as follows: In case of a 1:n relationship, the scope of an observation identifier may be local i.e. only unique in the scope of the SOS instance. In case of an m:n relationship, the scope of an observation identifier shall be global. SANY D2.3.4 Specification of the Sensor Service Architecture V3 Doc.V3.1 Copyright © 2007-2009 SANY Consortium Page 79 of 233

6.6. Management