The FAST OSLO-STEPS project resulted in an RDF-based vocabulary,
which structure is illustrated in Figure 1, and which use is demonstrated in Listings 1-5.
Increase interoperability by reusing existing concepts, is one aim of initiatives like OSLO or
ISA². We achieved that by mostly reusing existing concepts of the CPSV-AP and CCCEV
vocabulary. Thus our model extends the existing models of public services and
criterion/evidence-based communication, with a user perspective expressed as a “step”
We will work through an example where OSLO-STEPS is used as a representation for waste collection in
the municipality of Westerlo (see Figure 2). This form consists of several fields of different kinds which needs to be filled in by the citizen.
Providing information for each of the input fields can be seen as the most fine granular steps. The kind of form and its complexity
serves as a representative example of steps for the FAST project.
In the following, we describe some challenges the form poses, and how that might influence
the OSLO-STEPS model. The form consists of different kind of inputs. Free text fields (Figure
2, (1)) are used to provide information regarding the applicant. From the perspective of
OSLO-STEPS, these kind of input fields don’t pose any particular challenge. In fact, existing
OSLO models already offer the possibility to express addresses or names.
Structured input (Figure 2, (2)) is used to provide e.g. the national number of the citizen. Data
described using OSLO, is by definition structured. In case this structured input is provided
directly by the user via an user interface (UI), it needs to be checked whether the input
conforms to the stated constraints, e.g. a pattern of digits. However, state-of-the-art user
interfaces usually offer means to implement such constraint checking. Furthermore, existing
RDF-based languages, such as the W3C recommendation SHACL, can be used to
describe constraints on an RDF-based model like OSLO.
Fixed set of choices (Figure 2, (3)) pose similar challenges such as the discussed structured
One of the biggest challenges are possible alternatives (Figure 2, (4)). Existing vocabularies
like CCCEV offer the possibility to express alternative options.
However, from the form itself it is not clear which combination of input fields is valid. It seems invalid, that biological
waste containers are requested, but at the same time it is indicated at (5) that no biological
waste container should be collected anymore. Yet this constraint is stated nowhere. Only
with human-reasoning someone could infer that option (5) should only be used together with
the alternative (4). Strictly speaking, that no biological waste container should be picked up,
because the applicant composts the waste by himself. Since such a constraint is stated
nowhere, subjectively inferring such knowledge remains uncertain.