Re: Context Sensitive Property Concepts

(Thank you Mads.)

> Brick indeed appears to encode the context of a data point in the class, which in my
> opinion is the greatest drawback of the schema.

This is overstating it but...  Brick is a way of bringing structure and focus to a separate but related effort called Project Haystack [1].

Haystack is essentially a "bucket of tags" that can be mixed in together to create concepts, the tag names themselves organized into a taxonomy.  There is quite a bit of effort in version 4 to describe what specific tags should be mixed in together, for example [air] and [steam] are both kinds of [gas] that is a kind of [fluid] that is a kind of [substance], see [2].  All of the "tags" are part of the same flat namespace, and what tags are used in different contexts is sensitive to the experience of the person doing the tagging, although there are name-to-tags conventions that have been established so it is at least consistent within a particular installation.  Not unlike Twitter, where a person adds the hashtags that are generally going to be helpful when it comes time to find the tweet.

So [humidity], is a [quantity] of [air], see [3], so you mix that with other tags like [outside] and [air], or [room] and [space] and [air] to build an object of a particular type.  You then add "value tags" to the same object like [curVal] and [unit] to package everything together.  There is nothing that specifically prevents someone from adding nonsensical combinations of tags like [mau] and [rtu] which are both a kind of [ahu], software that flags these kinds of problems is being developed.

Brick uses OWL to codify many if not all of these concepts through strings of equivalent class restrictions, for example, a brick:Return_Air_CO2_Sensor has [ a owl:Restriction ; owl:onProperty brick:hasTag ; owl:hasValue tag:Sensor ].  Now a sensor of this type might have a rdf:value of 50 somethings (percent? parts per million?).  This is mixing sensors and observations all in together and not conducive to aligning with SSN/SOSA.

> The problem is further accentuated by the fact that names or concepts
> like “exhaust air” are not exactly unambiguously defined for all contexts.

Correct, and that's part of a much larger effort that I'm taking on.

> My planned approach to this is building on our work in FSO [1]...

Thank you for the reference!  I'll dig more into your work and I'm looking forward to continue collaborating.


Joel
[1] https://project-haystack.org/
[2] https://project-haystack.dev/doc/index-phenomenon
[3] https://project-haystack.dev/doc/lib-phScience/humidity

Received on Friday, 24 January 2020 22:11:33 UTC