Figure 1: Parts of the house
| Reference data on the Web | DEPUIS |
The objective is to perform a lifecycle assessment (LCA) of an individual house, House_1234, which is built at "Somewherestad" in Norway.
NOTE 1 To perform an LCA of an individual house is unrealistic. It is much more realistic to perform LCA of a class of house. Then, on the basis of the results of the LCA, a decision can be made whether or not to build a member of the class.
However, the definition of classes is more complicated than the definition of individuals, so we start with an individual.
The following RDF/OWL, serialised as N3, records that the thing with ID "House_1234" is a house at "Somewherestad" in Norway.
:House_1234 a iso15926-2:physical_object ;
a construction:House ;
SpatialRelations:locatedAt :Somewherestad .
:Somewherestad a AdministrativeGeography:AdministrativeUnit ;
AdministrativeGeography:isContainedIn
urn:iso:std:iso:3166:tech:NO .
This initial statement uses the following reference data:
physical_object: something you can kick, is defined in ISO 15926-2.
Each of:
are defined by the UK Ordnance Survey in the ontologies AdministrativeGeography and SpatialRelations.
urn:iso:std:iso:3166:tech:NO is a URI for Norway
which could be assigned by ISO.
House is a dwelling which is not part of a larger building. This should be defined in a construction industry ontology.
NOTE It has been very difficult to find the ontologies to record this basic information. In particular:
The geographic ontology from the UK Ordnance Survey is only appropriate to the UK, and there seems to be no widely accepted international equivalent.
ISO has not defined a URI for the country Norway, and
the proposal urn:iso:std:iso:3166:tech:NO is what could
be assigned by the ISO Technical Committee if it chose to do so.
The
BARBI ontology assigns to the class "house" the URI
http://www.barbi.no/barbibrowser/search.do?action=details&objectGuid=7CFC03697EDF4BEEBE9DB80BEDD4406.
This URI is not particularly convenient or memorable.
The difficulty of making this first step illustrates why the existing standards work is almost completely useless for SMEs.
A partitioning of the house into parts is shown in Figure 1.
The parts considered in detail in this document are shown in pink.
The partitioning of the house into parts is recorded as follows:
:House_1234 lca:hasPartition [ owl:oneOf ( :House_1234-Wall_1
:House_1234-Wall_2
:House_1234-Wall_3
:House_1234-Wall_4
:House_1234-Foundations
:House_1234-Roof
:House_1234-Internal_partitioning
:House_1234-Services
)
] .
Each part of the house, can itself be divided into parts. For House_1234-Wall_1, we have:
:House_1234-Wall_1
a iso15926-2:physical_object ;
lca:hasPartition [ owl:oneOf ( :House_1234-Wall_1-bricks
:House_1234-Wall_1-mortar
)
] .
This process of dividing into parts is terminated when either:
In the example above, the bricks are supplied to the site and assembled unaltered, whilst the mortar is probably manufactured on site from sand, cement and water inputs.
House_1234-Wall_1-bricks is the instance of
iso15926-2:physical_object
that is all the bricks in House_1234-Wall_1.
Bricks are sold by number, so that we need to say:
House_1234-Wall_1-bricks is, or consists of, 2000 bricks.
The relationship is, or consists of, between House_1234-Wall_1-bricks, the class Brick and the number 2000 is difficult.
NOTE The individual House_1234-Wall_1-bricks is not a member of the class Brick, but the mereological sum of a number of bricks. In the discussion below this is called an "aggregate item", because it is the aggregate of many bricks.
There are two possible approaches:
divide the aggregate item into individuals
For this approach, the aggregate individual House_1234-Wall_1-bricks is partitioned into a set of parts. Each of the parts is a brick, and there are 2000 members of the set. This is recorded as follows:
:House_1234-Wall_1-bricks
a iso15926-2:physical_object ;
lca:hasPartition :House_1234-Wall_1-set_of_bricks .
:House_1234-Wall_1-set_of_bricks
rdfs:subClassOf lca:Brick ;
lca:numberOfMembers
[ lca:decimal "2000" ] .
specify properties of the aggregate item directly
For this approach, a class it is necessary to have a class BricksInAggregate which is derived from Brick as follows:
lca:BricksInAggregate
rdfs:subClassOf iso15926-2:physical_object ;
rdfs:comment "A lot of one or more members of lca:Brick" ;
= [ owl:onProperty lca:hasPartition :
owl:someValuesFrom
[ owl:onProperty rdfs:subClassOf ;
owl:hasValue lca:Brick
]
] .
If bricks were sold by the tonne, then the amount in the wall could be recorded as follows:
:House_1234-Wall_1-bricks
a lca:BricksInAggregate ;
lca:hasMass [ lca:tonneScale [ lca:decimal "1.0" ] ] .
The approach can be used even if brick are sold by number, by defining the
property numberOfItemsInAggregate, as follows:
:House_1234-Wall_1-bricks
a lca:BricksInAggregate ;
lca:numberOfItemsInAggregate
[ lca:decimal "2000" ] .
The LCA of House_1234 considers all the activities in which the house is involved throughout its life. A partitioning of these activities into parts is shown in Figure 2.
The partitioning of the lifecycle into parts is recorded as follows:
:Lifecycle_of_House_1234
a iso15926-2:activity ;
lca:lifecycleFor :House_1234 ;
lca:hasPartition [ owl:oneOf ( :Building_of_House_1234
:Use_of_House_1234
:Disposal_of_House_1234
)
].
The activity Building_of_House_1234 has parts as follows:
:Building_of_House_1234
a iso15926-2:activity ;
lca:hasPartition [ owl:oneOf
( :Supply_of_inputs_for_House_1234
:Processing_of_inputs_for_House_1234_on_site
)
].
The parts of the activity Supply_of_inputs_for_House_1234 can be derived from the parts of the house as follows:
:Supply_of_inputs_for_House_1234
a iso15926-2:activity ;
lca:hasPartition [ owl:oneOf ( :Supply_of_House_1234-Wall_1-bricks
.....
)
].
The locations and amounts of material involved in the supply activities can also be derived from the parts of the house has follows:
:Supply_of_House_1234-Wall_1-bricks
a lca:SupplyOfMaterialWithLcaBatteryLimits ;
lca:materialSupplied
:House_1234-Wall_1-bricks ;
lca;receivingActivity
[ lca:at :Somewherestad ] .
This supply activity can be separated into supply at the brickworks and transport, as follows:
:Supply_of_House_1234-Wall_1-bricks
lca:hasPartition
[ owl:oneOf
( :Supply_of_House_1234-Wall_1-bricks_at_brickworks
:Transport_of_House_1234-Wall_1-bricks_to_site
)
].
:Supply_of_House_1234-Wall_1-bricks_at_brickworks
a lca:SupplyOfMaterialWithLcaBatteryLimits ;
lca:materialSupplied
:House_1234-Wall_1-bricks ;
lca;receivingActivity
lcaInfo:CollectionFromGate .
:Transport_of_House_1234-Wall_1-bricks_to_site
a lca:TransportOfMaterialWithLcaBatteryLimits ;
lca:materialSupplied
:House_1234-Wall_1-bricks ;
lca;receivingActivity
[ lca:at :Somewherestad ] ;
lca;sourceOfMaterial
[ lca:at :Oslo ] .
From the published LCA data, it is desired to calculate that:
:Supply_of_House_1234-Wall_1-bricks_at_brickworks
lca;hasAggregateOutput
[ lca:aggregationClassOfMaterial lcaInfo:CarbonDioxide ;
lca:aggregationReceivingActivity lcaInfo:Atmosphere ;
lca:hasMass [ lca:kilogramScale [ lca:decimal "1300.0" ] ]
] .
LCA data may be published for the classes of activity:
urn:lca:lcainfohub:process:brick, where the criteria
for membership are:
urn:lca:lcainfohub:process:transport_by_road, which is
the transport of material by road.
The class urn:lca:lcainfohub:process:brick can be defined
as follows:
urn:lca:lcainfohub:process:brick
= [ owl:intersectionOf
( lca:SupplyOfMaterialWithLcaBatteryLimits ;
[ owl:onProperty lca:materialSupplied ;
owl:allValuesFrom lca:BricksInAggregate
]
)
] .
NOTE In this definition the class lca:BricksInAggregate
is required because a member supplies a lot of any number of bricks.
The first stage in calculating the environmental impact of the supply for the house, is to classify the supply activities as follows:
:Supply_of_House_1234-Wall_1-bricks_at_brickworks
a urn:lca:lcainfohub:process:brick .
:Transport_of_House_1234-Wall_1-bricks_to_site
a urn:lca:lcainfohub:process:transport_by_road .
The amounts of CO2 emission for the supply for the house is then calculated from:
The emissions are specified for all members of
urn:lca:lcainfohub:process:brick which have a reference
amount. The emissions of 100 kg of CO2 into the atmosphere for a supply of
the reference amount can be recorded as follows:
urn:lca:lcainfohub:process:brick:reference
rdfs:subClassOf urn:lca:lcainfohub:process:brick ;
rdfs:subClassOf
[ owl:onProperty lca:hasAggregateOutput ;
owl:someValuesFrom
[ owl:intersectionOf
( [ owl:onProperty lca:aggregationClassOfMaterial ;
owl:hasValue lcaInfo:CarbonDioxide
]
[ owl:onProperty lca:aggregationReceivingActivity ;
owl:hasValue lcaInfo:Atmosphere
]
[ owl:onProperty lca:materialSupplied ;
owl:allValuesFrom
[ owl:onProperty lca:hasMass ;
owl:hasValue
[ lca:kilogramScale
[ lca:decimal "100.0" ]
]
]
)
]
] .
The reference amount is the supply of a lot of 1000 bricks. As discussed in Quantities of discrete items, there are different ways of specifying the reference amount, as follows:
divide the aggregate item into individuals
:urn:lca:lcainfohub:process:brick:reference
= [ owl:intersectionOf
( urn:lca:lcainfohub:process:brick
[ owl:onProperty lca:materialSupplied ;
owl:allValuesFrom
[ owl:onProperty lca:hasPartition ;
owl:someValuesFrom
[ owl:intersectionOf
( [ owl:onProperty rdfs:subClassOf ;
owl:hasValue lca:Brick
]
[ owl:onProperty lca:numberOfMembers
owl:hasValue [ lca:decimal "1000" ]
]
)
]
]
]
)
] .
.
NOTE This approach is complicated, so the next may be best.
specify properties of the aggregate item directly
urn:lca:lcainfohub:process:brick:reference
= [ owl:intersectionOf
( urn:lca:lcainfohub:process:brick
[ owl:onProperty lca:materialSupplied ;
owl:allValuesFrom
[ owl:onProperty lca:numberOfItemsInAggregate ;
owl:hasValue [ lca:decimal "1000" ]
]
]
)
] .
.
© CAESAR Systems Limited — Public deliverable of the DEPUIS project