Comments (17)
Read through the section on Substances in the README: https://github.com/BrickSchema/Brick#substances we are punning substances by treating them as singletons. I think this makes the data model more intuitive. The plan is not to instantiate substances beyond the punned instances
from brick.
I understand that's for Substances but my observation is for Quantities.
from brick.
Sorry! I got mixed up. Its the same principle though
from brick.
I see, but I found that punning isn't applied to Substances. Can you verify that? The same query does not work for Substances.
And could you point out which part of the code enables the punning? I just want to understand how it's implemented.
from brick.
It's a little weird because we don't actually instantiate them anywhere, but I think I understand what's going on.
Punning is applied to both Quantities and Substances; the "pun" part is where we say that the value of a certain property is a single instance which is has the same name as the class. Loosely, this is lines https://github.com/BrickSchema/Brick/blob/master/generate_brick.py#L83-L84 instantiated by lines like https://github.com/BrickSchema/Brick/blob/master/sensor.py#L14. When this is serialized into the turtle file, it looks like https://github.com/BrickSchema/Brick/blob/master/Brick.ttl#L252-L254:
When we use a Quantity or Substance in this way as part of a definition, it becomes implicitly "instantiated" . So when you are doing your query above, because you are using a
/rdf:type
you are only getting the quantities and substances that have been used in an owl:Restriction
clause with owl:hasValue
. Eventually, when all of the substances and quantities are used in class restrictions, then they should all show up in your query.
However I would expect some of the substance classes to show up when doing that query. I'm not 100% sure why that's happening, but it smells like there's a bug somewhere. I'll investigate tomorrow
from brick.
I assume this reaction from owlready2 when loading the Brick ontology is related:
`
- Owlready2 * Warning: ignoring cyclic subclass of/subproperty of, involving:
https://brickschema.org/schema/1.1.0/Brick#Quantity
`
from brick.
Good point! That probably has something to do with it. Wish it told us what was cyclic though.
We've uncovered that owlready2 doesn't provide all of the reasoning we require. owlrl does, but it can take a few hours to actually perform the reasoning. I'm running some tests + experiments to track down what's going on with this particular issue with instantiating Quantities and hope to have news to report soon.
@jbkoh how do you feel about quantities being instances? Temperature
is a quantity and Operative_Temperature
is a quantity, and Operative_Temperature
is a type of Temperature
. This approach to modelling involves both instantiation ("is a") and subclassing ("is a type of"). I think punning Quantities and Substances together is a decent solution to the modelling problem, in which case I'd like to close this issue once I figure out:
- what (if any) is cyclic about the quantity or substance hierarchies
- why substances and quantities are not consistently instantiated (this is linked to the reasoner)
from brick.
I've been trying to reconcile this discussion with the SOSA/SSN model. I was expecting that brick:Sensor
would be a subclass of sosa:Sensor
, that a brick:Torque_Sensor
is something that sosa:observes
torque, an instance of a bacnet:AnalogInputOutput
(something that might have an IRI like bacnet://234/analog-input.21
) could also be an instance of a brick:Static_Pressure_Sensor
.
from brick.
I think that's the right way of looking at it. Our brick:measures
would be analogous to sosa:observes
in this case, and I like the term "observes" better than "measures".
A related question, @JoelBender: is it more common to use rdfs:subClassOf
or brick:equivalentClass
in these scenarios where one is describing the relationship between two "equivalent" concepts?
from brick.
(assuming brick:equivalentClass
is a typo for owl:equivalentClass
) It is more common to use subclass because you can't necessarily guarantee that the two classes have exactly the same individuals. So sosa:observes
probably can be used to observe things that brick can't measure, but I would expect that everything that Brick can measure be something that is a subclass of an observable property.
from brick.
I'm trying to implement some of these fixes in #76
I like that we differentiate between Substances and Quantities, but it would be useful to group both of these under an abstract "Measureable" class, which could be a subclass of sosa:ObservableProperty
.
from brick.
@gtfierro I am not sure what we can get from Quantities and Substances being instances. If we at some point want to instantiate Substances (e.g., ex:air1 a brick:Air.
), the query and modeling pattern would be overly complicated and inconsistent with querying for other Classes like Points. Can you elaborate what it tries to solve? I read through this thread, but still don't get it.
from brick.
No worries! It's a bit of a subtle issue. The owl2 wiki has a nice discussion of it that I will adapt here.
Punning is a feature in OWL 2 that allows for a more flexible modeling strategy when it comes to classes and individuals (what OWL calls "instances" of a class). The OWL2 wiki has an example for eagles, but I'll adapt it for brick:Air
.
In Brick 1.1.0, the term brick:Air
can be used for:
- a class: in the sense that
brick:Air
is the superclass ofbrick:Supply_Air
; the organization of information - the class of all
brick:Air
: using it as a class lets us instantiate it (e.g.:room410_air a brick:Air
). We're not currently using this - an individual:
brick:Air
as an individual represents the mixture of gases known colloquially as "air" belonging to the metaclass of all gasses (and transitively, all physical substances).
Punning our substances and quantities means that we can use the same terms (e.g. brick:Air
and brick:Temperature
) to assemble both:
-
the hierarchy of all substances and quantities
brick:Substance a owl:Class . brick:Gas rdfs:subClassOf brick:Substance . brick:Air rdfs:subClassOf brick:Gas . brick:Supply_Air rdfs:subClassOf brick:Air .
-
canonical instances of those substances and quantities that can be inferred during reasoning
# explicit :ts1 a brick:Air_Temperature_Sensor . # inferred :ts1 brick:measures brick:Air . :ts1 brick:measures brick:Temperature .
Without punning, the OWL restriction that instances of Air_Temperature_Sensor
measure air and temperature cannot be fulfilled. OWL can't create a new instance of Air
out of thin air (so to speak), so its useful to have a canonical instance to refer to. This is what the OWL restrictions below express, and is how we model it in Brick 1.1.0.
brick:Air_Temperature_Sensor a owl:Class ;
owl:equivalentClass [ owl:intersectionOf (
[ a owl:Restriction ;
owl:hasValue brick:Temperature ;
owl:onProperty brick:measures ]
[ a owl:Restriction ;
owl:hasValue brick:Air ;
owl:onProperty brick:measures ]
) ],
Hope that helps; it took me a while to figure this out myself.
from brick.
I am fine with punning itself as we already discussed. I was curious if we need to do anything inside the model for punning. As far as I understood, we don't need anything but just Restrictions, which is already included in Brick.ttl. That's why I am confused about what you are trying to modify.
I interpreted, when you said, "Operative_Temperature is a type of Temperature" as rdf:type
relationship. If you meant rdfs:subClassOf
, I am with you.
from brick.
The key is its both rdf:type
and rdfs:subClassOf
. I'm making that explicit inside the Brick definition; before, you only got both statements if an entity in a Brick model actually instantiated a Sensor class
from brick.
Are you saying that we need this?
brick:Operative_Temperature a brick:Temperature
Maybe this part wasn't clear to me in the docs you provided. I thought we just needed to define classes while we allow associating them with instances. What is the problem with the below example?
brick:Operative_Temperature rdfs:subClassOf brick:Temperature.
ex:sensor1 brick:measures brick:Operative_Temperature.
from brick.
Nothing is wrong with the second one: that's specifically what we are allowing. The question I'm trying to investigate is whether or not making puns explicit helps us in any way.
The following in a Brick model is a "correct" pun
brick:Operative_Temperature rdfs:subClassOf brick:Temperature.
ex:sensor1 brick:measures brick:Operative_Temperature.
This means, however, that Substances + Quantities are only ever realized as individuals if there is another individual (e.g. :sensor1
) of a class that has a brick:measures
restriction or if brick:measures
is invoked explicitly.
By explicitly including in Brick statements like
brick:Operative_Temperature a brick:Substance, owl:Class .
brick:Operative_Temperature rdfs:subClassOf brick:Temperature .
we might be able to make reasoning about quantity/substance instances easier. It might only be worth doing that for the tests, though, so I might drop it
Is your only objection to the current model the fact that I'm explicitly instantiating the substances and quantities as members of the parent class?
from brick.
Related Issues (20)
- Unify Heat Pump, Chiller PRs
- Import .ttl file to large language model HOT 3
- Equipment Interrelationships using the System class
- Porting the REC ICT Equipment to BRICK
- Missing equipment for physical sensors in water and air systems HOT 1
- Question Refrigerant systems and loops HOT 1
- Optimal Representation of Water Heaters
- Redefining Setpoint Classifications: Target and Threshold HOT 4
- Tests fails on master branch HOT 2
- Right way to model Setpoints HOT 1
- Mapping to other ontologies HOT 3
- Modeling of heating substations HOT 1
- Modeling loops and connections HOT 1
- Questions about the bacnet ontology HOT 3
- Adjacent rooms HOT 2
- Reintroducing the Concepts of Supply/Return Temperature Sensors and Setpoint for the Water Systems HOT 1
- How to model the heatflow of a radiator? HOT 2
- Possible syntax error when using Prefix Declaration for SPARQL Queries HOT 4
- In v1.4 lots of Points as direct subclasses of Thing HOT 4
- Address Brick/REC Collection
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from brick.