BRICK Relationship Support
Last updated
Last updated
DCH has mixed coverage of the use of BRICK relationships in models. There are two aspects to the use of relationships in both BRICK and DCH models:
1) , and
2)
The following relationships are supported by DCH and can be used (subject to the correct usage as outlined in ).
'feeds'
'hasLocation'
'hasPart'
'hasPoint'
'isFedBy'
'isLocationOf'
'isPartOf'
'isPointOf'
The following relationships are designed to be used BRICK models but are currently not supported, or only partially supported in DCH. Upload of models that directly use any of these relationships will not flag an error but those declarations will be silently dropped and those relationships will not exist in the model in DCH.
Whilst BRICK 1.2.1 declares the feedsAir relationship, it does not define the inverse relationship 'isFedAirBy'. DCH does not support the use of FeedsAir.
Suggested Workaround:
Use the feeds relationship instead.
These relationships are intended to be used in BRICK models to represent the link between a Point and the timeseries database and reference to the Point's data. Whilst BRICK declares these it does not specify fully how they should be used.
Required Alternative:
As DCH currently has a specific timeseries database backing it (Senaps), an alternate DCH extension to BRICK relationship is used within DCH to link Points to timeseries data. Models in DCH need to:
1) Reference the Senaps uri using @prefix senaps: <http://senaps.io/schema/1.0/senaps#> .
2) Use the relationship senaps:stream_id in the models to link a timeseries to a point declaration. e.g. :my_point a brick:Point ; senaps:stream_id "stream_name_in_Senaps" . Further details are in the creating models section.
In DCH Sites and buildings consist of both information about the site or building as well as the semantic model. The latitude and longitude and information is contained in the building information rather than the semantic models. This removes the need for that information to be stored in the semantic model.
However, DCH does support the use of the brick:coordinates entity property, which does contain latitude and longitude components. I.e. latitude and longitude can be represented semantically in model, not as direct relationships but through adding a coordinates entity property if desired. See Entity properties support for further details.
Required workaround:
(Preferred) Add latitude and longitude information to the site or building information in the DCH platform (outside of the model), or
(Alternate) Add latitude and longitude information into the model by adding a coordinates entity property to the Site or Building.
As with latitude and longitude the address information for sites and buildings is stored in DCH in the information component of the sites and buildings rather than in the semantic models. DCH does not support keeping address information inside the semantic models.
Required Workaround:
Add the address information to the site or building information in the DCH platform, rather than in the semantic model.
The DCH team is working with the BRICK community to improve support for Units of Measure and Quantity Kinds. Support is currently in development.
brick:hasUnit is supported in/with entity properties where they are relevant. I.e. :room A brick:Room; brick:area [brick:value 12.3 ; brick:hasUnit unit:M2 ] .
However, hasUnit is not supported for points I.e. the following is not supported :point A brick:Point ; brick:hasUnit unit:degC . Upload of models that assign units to Points will not flag an error but those declarations will be silently dropped and those relationship will not exist in the model in DCH. Currently no workaround for this exists.
It is worth noting that many of the relationships declared in the BRICK Ontology are designed for use in the ontology itself, but not intended to be used within models based on the ontology. All relationships in that category are not supported by DCH. Upload of models that use any of these relationships will not flag an error, but those declarations will be silently dropped and those relationships will not exist in the model in DCH.
'hasAssociatedTag'
'hasInputSubstance'
'hasOutputSubstance'
'hasQUDTReference'
'hasTag'
'isAssociatedWith'
'isMeasuredBy'
'isRegulatedBy'
'isTagOf'
'measures'
'regulates'
'timeseries'
'value'
'vcard:hasAddress'
BRICK has constraints both explicitly and implicitly on how relationships should be used in models. For example location classes such as rooms can have an "isPartOf" relationship to a floor, but do not have (can not have) a "hasLocation" relationship to a floor.
To improve consistency between models, DCH imposes further restrictions on what relationships are valid. An example is that BRICK allows a Building to be part of Room, DCH does not.
The compete set of what relationships are allowed or disallowed between which classes is a complex matrix of the types of relationships ( e.g. feeds, hasPart etc) with the two the types of things (e.g. types of Locations, Equipment, or Points) to be related.
This is best represented diagrammatically, see Figure 1
In many circumstances DCH also imposes limits on the number of relationships that things can have in models. These are not all represented in Figure 1.
As a general rule of thumb things can have many child relationships (e.g hasPart, or isLocationOf) but only a single parent relationship (e.g. isPartOf, or hasLocation). Zones are an exception.
A Location can only be a part of (isPartOf) one parent Location (except Zones - see 2.) e.g a Room can only be part of one Floor.
A Location can also be a part of (isPartOf) many Zones.
A Location can have many other Locations as parts of it. e.g a Floor can have many Rooms.
Zones can have parts other Locations (but not Zones)
A Location cannot have a part which is a Zone
A piece of Equipment can only be a part of (isPartOf) one parent piece of Equipment.
A piece of Equipment can have many other Equipment as parts (hasPart).
A piece of Equipment can only be located in one Location.
A piece of Equipment cannot be located in a Zone.
'
Recall that DCH handles and . Hence any relationship rules about Equipment classes also apply to Collection classes, and any relationship rules about Rooms also apply to all other Space classes.
