OSLO-STEPS Domain Model
Introduction
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” class.
Domain Model
Example use
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 input.
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.
Listing 1
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix westerlo: <https://example.org/ns/westerlo#> .
@prefix p-plan: <http://purl.org/net/p-plan#> .
@prefix oslo-steps: <https://example.org/ns/oslo-steps#> .
# Definition of data (each variable could be produced by multiple steps)
westerlo:variableGreenWasteContainer40LiterAmount a p-plan:Variable .
westerlo:variableGreenWasteContainer120LiterAmount a p-plan:Variable .
westerlo:variableGreenWasteContainerLockInfo a p-plan:Variable .
westerlo:variableGreenWasteContainerOwnCompostInfo a p-plan:Variable .
westerlo:variableGreenWasteContainerCollectionStopInfo a p-plan:Variable .
# Definition of steps which provide data
westerlo:provideGreenWasteContainer40LiterAmount a oslo-steps:Step ;
rdfs:label "Aantal 40 liter container(s)"@nl ;
rdfs:label "Amount 40 liter container(s)"@en .
p-plan:hasOutputVar westerlo:variableGreenWasteContainer40LiterAmount .
westerlo:provideGreenWasteContainer120LiterAmount a oslo-steps:Step ;
rdfs:label "Aantal 120 liter container(s)"@nl ;
rdfs:label "Amount 120 liter container(s)"@en .
p-plan:hasOutputVar westerlo:variableGreenWasteContainer120LiterAmount .
westerlo:provideGreenWasteContainerLockInfo a oslo-steps:Step ;
rdfs:label "Ik vraag een slot aan voor 35 euro per stuk bij plaatsing"@nl ;
rdfs:label "I request a lock for 35 euro per piece on placement"@en ;
p-plan:hasOutputVar westerlo:variableGreenWasteContainerLockInfo .
westerlo:provideGreenWasteContainerOwnCompostInfo a oslo-steps:Step ;
rdfs:label "Geen, want ik composteer mijn GFT zelf"@nl ;
rdfs:label "None, because I compost my GFT on my own"@en ;
p-plan:hasOutputVar westerlo:variableGreenWasteContainerOwnCompostInfo .
westerlo:provideGreenWasteContainerCollectionStopInfo a oslo-steps:Step ;
rdfs:label "Ophaling GFT-container door stopzetting"@nl ;
rdfs:label "Stop collecting GFT-container"@en ;
p-plan:hasOutputVar westerlo:variableGreenWasteContainerCollectionStopInfo .
Listing 2
We demonstrate in listing 2 the definition of one of the steps from the form shown in figure 2, to illustrate the use of OSLO-STEPS. The shown step provides certain information, but also needs input data. This input data can be provided by steps which are shown in listing 1. This also implies a hierarchy of steps, expressed in the dependency of input data. Listing 4 presents an alternative approach to represent needed input data for a step using the CCCEV vocabulary.
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix westerlo: <https://example.org/ns/westerlo#> .
@prefix p-plan: <http://purl.org/net/p-plan#> .
@prefix oslo-steps: <https://example.org/ns/oslo-steps#> .
# Green GFT group 2: own compost
westerlo:provideGreenWasteContainerInfo a oslo-steps:Step ;
rdfs:label "Groene GFT container(s)"@nl ;
rdfs:label "Green GFT waste container(s)"@en ;
rdfs:comment "Information regarding green waste container(s)"@en ;
p-plan:hasInputVar
westerlo:greenWasteContainer40LiterAmount ,
westerlo:greenWasteContainer120LiterAmount ,
westerlo:greenWasteContainerLockInfo ,
westerlo:greenWasteContainerOwnCompostInfo ,
westerlo:greenWasteContainerStopCollectionInfo ;
p-plan:hasOutputVar westerlo:greenWasteContainerInfo .
As discussed in a previous section, not all values respectively combination of values might be valid. One way to express valid combinations is illustrated using the CCCEV vocabulary as shown in listing 4. Valid values can be described using shapes, which can be used to automatically validate input data provided by the user. Additionally such shapes have the potential to communicate valid values to a UI component, which can render UI elements accordingly, and also provide a state-of-the-art user experience by highlighting invalid values while using the UI. Shapes may define target nodes to which they apply, which is used for automated validation. In our case shapes may target defined variables, which allows the shapes to validate each value provided by the user, which due to the model corresponds to these variables, see listing 5.
Listing 3
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix westerlo: <https://example.org/ns/westerlo#> .
@prefix p-plan: <http://purl.org/net/p-plan#> .
@prefix oslo-steps: <https://example.org/ns/oslo-steps#> .
@prefix app: <https://example.org/ns/app#> .
@prefix sh: <http://www.w3.org/ns/shacl#> .
# A shape defining valid values for a provided value, produced by a step
westerlo:greenWasteContainer40LiterConstraints a sh:NodeShape ;
sh:targetNode westerlo:variableGreenWasteContainer40LiterAmount ;
sh:property [
sh:path (
[ sh:inversePath p-plan:correspondsToVariable ]
cccev:value
);
sh:in (0 1 2 3 ) ;
] .
Listing 4
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix westerlo: <https://example.org/ns/westerlo#> .
@prefix app: <https://example.org/ns/app#> .
@prefix cccev: <http://data.europa.eu/m8g/> .
@prefix oslo-steps: <https://example.org/ns/oslo-steps#> .
# CRITERION: Green GFT (biological) waste container info
westerlo:criterionGreenWasteContainerInfo a cccev:Criterion ;
rdfs:label "Groene GFT container(s)"@nl ;
rdfs:label "Green GFT waste container(s)"@en ;
rdfs:comment "Information regarding green waste container(s)"@en ;
cccev:fulfilledBy
westerlo:greenWasteContainerGroup,
westerlo:greenWasteOwnGroup .
# Green GFT group 1: request container(s)
westerlo:greenWasteContainerGroup a cccev:RequirementGroup ;
cccev:hasCriterionRequirement
westerlo:greenWasteContainer40Amount,
westerlo:greenWasteContainer120Amount,
westerlo:greenWasteContainerDelivery,
westerlo:greenWasteContainerLock,
westerlo:greenWasteOwnStopCollecting .
westerlo:greenWasteContainer40Amount a cccev:CriterionRequirement ;
rdfs:label "Aantal 40 liter container(s)"@nl ;
rdfs:label "Amount 40 liter container(s)"@en ;
cccev:expecteddatatype xsd:integer .
westerlo:greenWasteContainer120Amount a cccev:CriterionRequirement ;
rdfs:label "Aantal 120 liter container(s)"@nl ;
rdfs:label "Amount 120 liter container(s)"@en ;
cccev:expecteddatatype xsd:integer .
westerlo:greenWasteContainerDelivery a cccev:CriterionRequirement ;
rdfs:label "Container(s) leveren"@nl ;
rdfs:label "Deliver container(s)"@en ;
cccev:expecteddatatype xsd:boolean .
westerlo:greenWasteContainerLock a cccev:CriterionRequirement ;
rdfs:label "Ik vraag een slot aan voor 35 euro per stuk bij plaatsing"@nl ;
rdfs:label "I request a lock for 35 euro per piece on placement"@en ;
cccev:expecteddatatype xsd:boolean .
Listing 5
@prefix rdfs: <http://www.w3.org/2000/01/rdf-schema#> .
@prefix xsd: <http://www.w3.org/2001/XMLSchema#> .
@prefix westerlo: <https://example.org/ns/westerlo#> .
@prefix app: <https://example.org/ns/app#> .
@prefix cccev: <http://data.europa.eu/m8g/> .
@prefix oslo-steps: <https://example.org/ns/oslo-steps#> .
@prefix p-plan: <http://purl.org/net/p-plan#> .
@prefix frbr: <http://purl.org/vocab/frbr/core#> .
@prefix prov: <http://www.w3.org/ns/prov#> .
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
# The description of a user
app:me a foaf:Agent .
# The representation of an executed step (One 40 liter container)
app:responseGreenContainer40 a oslo-steps:ExecutedStep ;
p-plan:correspondsToStep
westerlo:provideGreenWasteContainer40LiterAmount ;
prov:generated app:dataGreenWasteContainer40 ;
prov:wasAssociatedWith app:me ;
prov:startedAtTime "2019-03-03T13:37:00Z"^^xsd:dateTime ;
prov:endedAtTime “2019-03-03T13:38:14Z”^^xsd:dateTime .
# The value the user provided (which is targeted by the shape from figure 3)
app:dataGreenWasteContainer40 a prov:Entity, cccev:RequirementResponse ;
p-plan:correspondsToVariable
westerlo:variableGreenWasteContainer40LiterAmount ;
cccev:value 3 .