VS: Context Sensitive Property Concepts

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

Oh yes, I meant it as a drawback for my intended use rather than as a general drawback. I want to model more detailed information about the HVAC process and control, which in my understanding Project Haystack nor Brick were really intended for.

Thank you for the detailed description of the approach, and the references!

FSO and its documentation are still a work in progress. If you have any questions about that, I'm happy to answer the best I can. Any thoughts and ideas are also more than welcome!

Best,
Ville

-----Alkuperäinen viesti-----
Lähettäjä: Joel J. Bender <jjb5@cornell.edu> 
Lähetetty: lauantai 25. tammikuuta 2020 0.11
Vastaanottaja: public-lbd@w3.org
Kopio: Mads Holten Rasmussen <mhoras@byg.dtu.dk>
Aihe: 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://hes32-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fproject%2dhaystack.org&umid=8ca6e2b9-efd4-4f96-8ad5-40e8bb886765&auth=b047f5bb2cbde123e3abcd6416946061e2733587-175a28efb84cbc89f9a939a2d74e0cad203c7333
[2] https://hes32-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fproject%2dhaystack.dev%2fdoc%2findex%2dphenomenon&umid=8ca6e2b9-efd4-4f96-8ad5-40e8bb886765&auth=b047f5bb2cbde123e3abcd6416946061e2733587-a6b9ecc786ceb72be32d2cfb4c3ad932f05d2c9a
[3] https://hes32-ctp.trendmicro.com:443/wis/clicktime/v1/query?url=https%3a%2f%2fproject%2dhaystack.dev%2fdoc%2flib%2dphScience%2fhumidity&umid=8ca6e2b9-efd4-4f96-8ad5-40e8bb886765&auth=b047f5bb2cbde123e3abcd6416946061e2733587-9857275d4c33e16876ae08e9e1e79b40297affa1

Received on Saturday, 25 January 2020 09:14:08 UTC