use of equivalentClass in Brick models
danie...@csiro.au
I have some questions about the use of Brick classes that have owl:equivalentClass statements... Brick has 12 pairs of classes have symmetrical owl:equivalentClass statements (eg Storey <--equivalentClass--> Floor), and 73 classes have a non-blanknode asymmetrical owl:equivalentClass statement (eg Fan_Coil_Unit --equivalentClass--> FCU). 59 of these are about the apparent synonymity of 'supply' and 'discharge' tags. AHUs are actually defined three times, using both symmetrical and asymmetrical statements: Air_Handling_Unit <--equivalentClass--> Air_Handler_Unit --equivalentClass--> AHU.
This means that:
- Modellers can define AHUs in any of these ways
- Without OWL inferencing, queries that are naive to class synonymity may ask for just one, neglecting the other possiblities
The questions are then...
1) What is the intended use of these multiple synonymous classes to modellers and query writers?
2) If we are not using OWL inferencing (eg because we're using named graphs and our DB doesn't support automatic OWL inferencing), how should we treat models that use these classes? Eg should we perform OWL equivalent pre-inferencing prior to querying, and query on the basis that instances will have multiple synonymous types?
3) Are any of the synonymous classes 'preferred'? For example, when presenting classs names to users via applications or UIs, which of a set of mutually synonymous names should we display?
Cheers!
Dan.
Gabe Fierro
Hi Dan:
The intended use of the multiple synonymous classes is to deal with aliases and common alternative names/abbreviations for the same concept. Similar to the use of inverse properties (feeds/isFedBy), the use of inferencing will create triples that provide additional flexibility when querying the model --- I don’t need to be aware of which direction (feeds vs isFedBy) was populated in the model because both appear in the eventual reasoned graph.
You can actually get away with only SHACL inferencing in Brick 1.3.0; the necessary elements of equivalency, inverse, etc are all encoded as SHACL rules. I believe there are SHACL processors (SHACL2SPARQL) which just use SPARQL processing to conduct inference/validation as well. You may want to consider incorporating some sort of “compilation” step into your data hosting solution. A key decision is whether or not to store the pre-reasoned or post-reasoned models; it can also be important to manage keeping the ontology triples separate from your building model triples to allow easier upgrading of the ontology later.
To your last question, we could introduce a notion of preference between synonymous classes. However, this would require changing from owl:equivalentClass to another property. I also think this is a kind of hack that sidesteps dealing with inferred data above. The real answer is to deal with an inference process in your data management solution. Should still be possible in a named graph setting as I’ve done some of that before, and we can speak about some strategies for handling that.
Hope that helps!
Best,
Gabe
--
You received this message because you are subscribed to the Google Groups "Brick User Forum (Unified Building Metadata Schema)" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
brickschema...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/brickschema/cc676e92-3c2d-442c-afd5-24a5a359da0an%40googlegroups.com.