ns

Namespace

This namespace is where common terminology and ontology across all of the Urban Observatories resides.

Please submit a pull request and allow time for comments if you wish to add a term.

Terminology that is unique to your institution of a specific sensor network may also be defined in a local vocabulary.

Term definitions

New terms MUST be added to the defines array within the relevant index.json document.

Each term MUST contain the following properties:

Key	Description
@id	A unique identifier for the term you are identifying, that will be used by documents authored against the vocabulary. It MUST begin with the vocabulary file's given prefix. Naming convention is that an rdfs:Class SHOULD begin with an uppercase letter and be specified in PascalCase, for example uo:Collection, and an rdf:Property SHOULD begin with a lowercase letter and be specified in camelCase, for example uo:nextPage.
@type	The type of term defined. The @type SHOULD be one of the following: rdfs:Class is used to describe an object or resource, and would be referenced in the @type key by its instances. This also determines the properties that object is expected to have. Examples of classes include sosa:Sensor and uo:Collection. rdfs:Datatype for types of data that are not adequately described elsewhere. Examples of data types include xsd:boolean and hydra:Rfc6570Template. rdf:Property for properties that are associated with an rdfs:Class and could appear as keys on the object. Examples include sosa:madeBySensor for observations and dc:description for a description of a resource.
term_status	A text description that indicates whether the term is suitable for use in production systems or likely to change. It MUST be one of: unstable when the meaning, deployment practices, documentation (or important associated software/services) associated with this term are liable to change arbitrarily at some point in the future. They may not, but stability is not guaranteed. Use with caution. testing when the meaning, deployment practices, documentation and general understanding of this term are approaching some stability, but changes are still possible due to implementation experience or other unanticipated factors. stable when the term is relatively stable, and its documentation and meaning are not expected to change substantially. archaic when term is marked as old-fashioned; although used, it is not considered typical of current best practice and alternative expressions may be preferable.

In addition, each term SHOULD contain the following properties:

Key	Description
label	The label MAY be used to provide a human-readable version of the term. This is often likely to be the same as the @id for the term, but without any special casing. It SHOULD be specified all lowercase except for proper nouns. A good label might be "made by sensor" for the property "madeBySensor".
comment	The comment MAY be used to provide a more verbose description of the term. It should be human-readable. A good comment might be "A collection of resources that may be viewed through pages or filtered" for uo:Collection.

In addition, a term definition for an rdf:Property MUST include:

Key	Description
domain	A reference to an rdfs:Class that this property is associated with, and might be expected to be used as a key for. For example, a uo:member property could have the domain of uo:Collection, stating that collections would be expected to contain members. Where multiple domains are specified, this indicates that all of the given classes are applicable. Use schema:domainIncludes for one of relations.

In addition, a term definition MAY include:

Key	Description
range	A reference to one or more rdfs:Classes that an rdf:Property might reference. For example, a collection of sensors could have the range sosa:Sensor. Where multiple ranges are specified, this indicates that all of the given classes are applicable. Use schema:rangeIncludes for one of relations.
subClassOf	All instances of this class are also instances of another class.
subPropertyOf	All instances of this property are also instances of another property.
seeAlso	A reference that provides additional information. This does not have to be machine readable, and could for example be a Wikipedia entry or similar.
sameAs	An indication that a resource is referring to exactly the same thing. This is most appropriate for physical things (e.g. a room in a building that exists in two different APIs may be linked this way) rather than conceptual relationships, which may be better described as a sub-class or sub-property.

Naming conventions

@id's

The following table describes which case MUST be used for the @id of new definitions. Note the use of compact IRIs, e.g. using the prefix uo:.

Definition Type	Case	Examples
Class	PascalCase	uo:Discipline, uo:ObservableProperty, uo:Collection
Property	camelCase	uo:recommendedUnit, uo:hasMember
Instances	kebab-case	uo:atmospheric-chemistry, uo:air-temperature, uo:millimetre, uo:earth-atmosphere

label's

The label property of instances should be short, but meaningful. The description can always be used to provide more detail. In most cases the first word in the label should be capitalised, e.g.: Air temperature or Atmospheric chemistry. However labels are allowed to break this rule if it results in the label having more meaning. Take the following examples:

• The unit Degree Celsius - Because Celsius is a surname it is appropriate to capitalise it too.
• The observed property PM₁₀ mass concentration - The common approach to writing particulate matter is to abbreviate it to PM and therefore writting it as Pm would cause confusion, thus we use the common convention.
• The observed property RSSI - received signal strength indicator is far more commonly written as RSSI and therefore this is more appropriate for use as a label.

The benefit of this approach to capitalisation is that end-users can choose to use the capitalised form, or they can easily convert the whole string to the lowercase if they wish. It would be much harder to go in the other direction, i.e. we define it in all lowercase and force the end-user to correctly capitalise it.