Home - UICrail/SemanticRSM GitHub Wiki

Welcome to the SemanticRSM wiki!

Please note that this Wiki is NOT an introduction to RSM for beginners: it only supports the current developments. Some previous knowledge about network representation and RTM or RSM is expected.

Quick start: Topology (1.0rc1)

Modelling rules and conventions

See Modelling guidelines and conventions.

A transversal feature is "property set". Such property sets are sometimes used (see for instance IFC) and can be defined cleanly using basic RDFS. See Property sets.

Packages

"Packages", a UML notion, are understood in the RDF context as possible linked vocabularies.

Available

Not yet there

  • Network: describes the network, referring to its backbone (topology) and entities (material or not: track, signals...) attached to it.
  • Linear referencing: equivalent to the former RSM "Positioning" package but limited to linear referencing (ISO 19148), as geo referencing is done via geosparql and its extensions. This might change in the distant future, as GeoSPARQL seems to be heading towards a (X,Y,Z,M) coordinate representation, and beyond. We consider using some available ontology transposing ISO 19148, despite losses or distortion, such as Datex (several variants are available) of IfcOwl (RDF/OWL version of IFC).

Linked vocabularies

  • quantities and units: to be decided... or not, by providing multiple options, including QUDT. See Quantities and units.
  • SOSA/SSN (see: adapters, above)
  • GeoSPARQL (see: adapters, above)

To be developed

  • time dependency, validity dates
  • time axis package (W3C recommendations are evolving... RSM 1.x is based on 2020 update). See W3C page

Room for simplification?

Rationale... and caveats

In the context of Infrastructure Managers, we may quote here INFRABEL: "any of our attempts to simplify RSM resulted in going back to the original".

In the narrower context of RINF, there may be room for simplification. The package documentation provides some hints, and also justifies the design choices leading to apparent complexity.

Understanding "simplification"

Simplification has two quantitative aspects:

  • limiting the size of terminology files (number of classes, properties, individuals)
  • limiting the size of assertion files (number of assertions)

However, quantitative reductions should be balanced with the loss of expressiveness.

More importantly, simplicity is a quality:

  • clear concepts and concept hierarchy
  • proper use of existing vocabularies (geosparql, ...)
  • proper "packaging"

all of which is not expressed in "numbers of".

Examples

[coming...]

Toolsets

Most used toolsets are open source or shareware.

See About the toolsets for details.

package