Discussion on ontology improvement #1791
Comments
|
Using synonym is I believe a way to extend the ontology. I already tested it with rooms,
I imagine we can do it for equipments too. To be checked. That would mean the user is not limited with locations and equipments. Problem is only for properties. |
|
Unfortunately, synomym is ignored by Main UI for equipment. Unfortunately, I find no card named "Capteur" in the Equipment tab in MainUI, only "Equipment". I have no idea if this is a bug in MainUI or if simply synomyms are not allowed for an equipment ? If synonym was possible for an equipment like it is for a room, I have the feeling it will allow a user to define any equipment he would like. |
|
A couple years ago I had proposed a few additions for consideration. I'll copy here from the original issue. Locations
Properties (a number of my Z-Wave sensors produce these)
Equipment
Points
|
|
After more testing, I understand that the synonyms are just not used by the UI. In Main UI, in Locations tab, you have one card for each group tagged with a location tag. So if one room is missing in the ontology, tag your group simply with "Room" and it will appear in the Locations tab with the lable of your group. In the equipment tab, there is not one card for each group tagged with a equipment tag, but one card for each kind of equipment defined in the ontology. So, if you have several groups tagged with "Equipment", they will be all grouped in the unique "Equipment" card. I don't find how you can create new cards. The list of cards is limited to the equipments defined in the ontology. So if you don't find what you need as equipment and choose just "Equipment", this will result in a lot of things in the "Equipment" card. |
Third floor is really not something common. Second floor is just a little more. IMHO, second floor could be added.
Agreed.
Isn't it the same thing as living room ?
As you mention, this is a synonym and similar to bathroom. IMHO, not to be added to avoid a big list.
As you mention, this is a synonym and similar to corridor. IMHO, not to be added to avoid a big list.
Agreed.
What equipments do you like to put in this location ? Lights ?
As you mention, this is a synonym and similar to terrace. IMHO, not to be added to avoid a big list.
Agreed for porch.
Agreed for one of both.
Looks like ultra specific.
Agreed with these 3 ones.
Is Door not enough ?
IMHO, setpoint is sufficient.
I thing we can use Status + Presence to represent motion ? This is at least what I did. |
|
On my side, for locations, I would propose to add:
|
|
Thanks for looking over the list. I've commented only on the ones you questioned.
Agree with dropping Third Floor. Second Floor is a must IMO (otherwise what's the point of having a First Floor 😉 ).
These are typically 2 different rooms (at least in the US)
Agree
Agree
I have lights, motion sensor, and camera. Also possible are driveway sensor, gate, and intercom
Agree
There are several Z-Wave sensors that report these, so I don't see the harm in adding them for completeness. Weather Stations also report UV.
Probably. I added Back and Side because I thought there already was a Front Door.
Agree
Agree |
|
For equipments, I would propose these very common equipments for which I found no matching:
|
Agreed for a second floor.
Interesting, we don't have this distinction in France. And if you check with Google Tradcution, you will see that it leads to the same translation ;)
Ok, agreed.
Ok, why not. Agreed. |
|
For TV, maybe Screen is intented ? |
|
I see some reasons to extend the ontology: 1.) There are shortcommings. Things that are realy missing. Example: Battery Level/State Point = Status Property = ? maybe Energy Question: Is the intention to extend the Onthology or to change it where suitable? And we should find a format to document our discussion in an easy format. |
Some people put their OH monitored Car there. ;) |
|
Third Floor would be needed in my OpenHAB Setup. |
I would argue that 3rd floor is actually quite common in the US. In Europe and the UK, they use "Ground Floor" for what we would call "First Floor" in the US, and then "First Floor" for what we would call "Second Floor", and so on. So I would expect it to be less common there. |
|
Ok for driveway and third floor. I see in the current definition that television and TV are defined as synonyms of screen. |
In the US the Terrace level of a building is usually below the first floor. A Patio is an outside seating area. |
|
@mhilbush : I misunderstood your requests of new synonyms. I think they could be added as synonyms, especially if the UI would be able to expose them more directly with the main location/equipment. |
|
Ok, no problem. How do you want to handle the aggregation of all the suggestions? |
|
I can list the validated changes in my first message? But before, I would like to know if we can rely on synonyms or not in UI. This could reduce the need of new entries but a change in UI. |
That works.
Makes sense. |
|
First message updated with all proposals. |
|
The point "OpenState" be replaced by a property "Opening". For a door/window, we will then use point "Status" and property "Opening". Does it make sense ? The idea is to have a card "Opening" in UI (tab Properties) that will show the opening status of all door and windows. |
|
Looks good. Just one suggestion.
Change to: Corridor: Hallway |
Property "Level" could be added. We will then use point "Status" (or "Measurement") and property "Level". |
You mean adding "Foyer Entry" as new synonym for existing entry "Corridor" ? Or adding a new entry "Foyer Entry" ? |
|
Oh, sorry, I should've been more clear. WDYT? Add Hallway as a synonym of Corridor Add a new location Entry. Add Foyer as a synonym of Entry. |
No, I don't think it's a good solution to display all synonyms. Instead I'll push to offer the ability to customize what's displayed on the card, so it would be possible to rename the title from the suggested default, but also change the background color, eventually add a background image if desired, maybe a badge with some counter, and other additional text or controls of the user's choosing. For example the Temperatures card might be a good place to display an average - but the indoor temperatures only as including an outdoor temperature in the average wouldn't make sense -, or on a Window card the number of windows that are open, maybe with icons. On the other hand, displaying synonyms when picking the semantic class (when you're editing the items) make sense. |
Ok, changed. |
|
As a new Property we should add Time or TimeStamp As far as i undersnd the synonyms are only used within habbot. Is that right? |
|
Setting semantic tags is required to build the model and have channels dispayed in MainUI (equipment tab, properties tabs). |
|
From my point of view the problem with the model is that we need PR's to change/add new things (Points, propertyies, Equipments, ...) and i have real doubts about the usefullness at all. Based on this i deleted the whole model and work only with groups. A real benefit would be a good groups display in the ui where is no need to tick a checkmark to see my groups an get goups with metadata displayed. So strip away all tags and create a dynamic system that every use create on his own. |
|
@TBail Removing the semantic model is imho not the way to go. The model is very powerful and can be used for so much more than for plain grouping. I understand from @lolodomo though that the current UI implementation forces users to put semantic tags on everything, because they otherwise are not shown on the semantic tabs. I don't think the semantic tabs were ever meant to be the main access for everything, though. Ideally, one should design pages, which can use grouping for sorting stuff into a desired structure. |
|
@kaikreuzer Could you give some examples how to use the model. All i see since the first version of openHAB 3 is that it is complex to implement, it is not complete, it is not easy to extend for the user (PR required) and it only generates some kind of standard sitemap. Beside the automatic sitemap creation all other thing could be done with groups in a more flexible way. Only thin missing is group display, that is not ficussed on the semantic model. Maybe the right way is to add user dynamic options. Dynamically extendable by the user, Why not define own equipment, points and properties. On big problem is alway to get a common understanding. Is first floor in the US the same as in germany, is a meter value a measurement, what does light as point mean does it include color, ???? |
Designing pages is IMHO for very advanced users. Even me, I did not do it ! |
It existed long before openHAB 3 already - it brings "machine readability". It's first use was for NLP in HABot and it will be important in future for properly using rule templates as well. We definitely won't drop it.
@ghys I'd like to invite you to the discussion and see what solution there could be. I agree with @lolodomo that the semantic tabs are very prominent and in many places (including our newby tutorials), it is suggested to users to make extensive use of it. On the other hand, we agreed here on this thread that our semantic library should be cautiously maintained and must not proliferate - through this it is clear that we won't have semantic tags for any of the channels that are out there, which will always leave us with items that have no suitable tags. For the issue at hand (channels with forecasted weather data) I somehow think it is correct that they do not turn up on the semantic tabs - such information would somehow clutter it too much, especially if we'd keep adding more and more such things. What could be a solution here? |
There is a checkbox at the bottom of the model views that will show all Items whether or not they are semantically tagged. By default that check box is not tagged. The UI encourages the use of tags but it does not force the user to put tags on everything and I've personally taken it as a mission to make that clear on the forum. I tried to make that clear in the Getting Started Tutorial. In my experience only 60%-75% of Items belong in the model and to have tags at all. Stuff like the Items that feed into proxy Items, Items used in rules or to hold settings and such shouldn't be in the model.
I would not be in favor of this approach but it's not a strong preference. The problem is that these Items with a Point tag added will automatically end up represented in the Overview Pages whether you want it there or not. Rather than making a positive decision to show it, by adding semantic tags, one must edit the visibility of the Items to make the negative decision to not show the Items. But the problem of not being able to see non-tagged Items in the Model view is already solved. Check the box and you'll see all the Items. The ones that are not in the model will be slightly grayed out so it's easy to tell the difference between tagged and untagged. One nice feature this allows is you can still take advantage of grouping these Items into Equipment and Locations but you don't have to deal with making everything a part of the model and then needing to do something special to not show those Items in the UI. For example, here is one of my Chromecast Equipment groups in the Model.
Everything under "Rich's Office Home Hub Volume" have no semantic tags. I don't want those Items to be a part of the model. I don't want them rendered in the Overview Pages and I don't want them available to HABot. So they are not tagged. But notice they are still members of "Rich's Office Home Hub" which is tagged with an Equipment tag. Overall my understanding is that the tags that we had initially came from an established ontology so that would explain why we had the set of tags that we originally had. But we will be moving pretty far from that original set based on the discussion here. So maybe it's worth considering something that might work better in an OH context. Personally I really like how the Point/Properties work. It provides a really powerful way to define both what the Point does/represents and what it does it to. For example, Alarm/Smoke for a smoke alarm. Alarm/Water for a leak alarm. Alarm/Sound for a loud sound alarm. And so on. Maybe that can be expanded to Equipment and Locations too? Maybe have just on Door tag and then have a "Equipment Property" to distinguish between "Front Door" and "Back Door" and so on. Why do we need six separate tags to represent doors? Semantically is there really a difference between a Front Door and Back Door beyond it's name? Maybe we only need three tags with the ability to enhance it with a second tag: Exterior Door/Front, Interior Door/Bathroom, Garage Door. Way back in OH 2.5 there was the ability to define synonyms for the model used by HABot using metadata if I recall correctly. So, for example, one can use a Bedroom Location tag with a synonym "Rich's Bedroom". Perhaps something like that could be incorporated to allow users the flexibility define the model in ways that provide more meaning to them while also preserving the set meanings required by the HLP in HABot. To go back to the doors example: Exterior Door is the tag and "Front door" is the synonyms. Just some thoughts... |
|
Thanks @rkoshak, your input is highly appreciated.
This is correct, but afaik that's only the case for the model view. The discussion above was mainly about the "Locations" and "Equipment" tabs, which I dubbed "Semantic tabs" above. Those tabs only show semantically tagged items and nothing else (see #1791 (comment)). Therefore @lolodomo created PRs like openhab/openhab-addons#10973 and openhab/openhab-addons#10972 (and there would be 298 PRs to come to also cover other bindings) to make sure that channels of Things turn up on those tabs without the user having to manually add semantic tags to them. See this post for the questions I was trying to find a solution for right now (and please allow me to "park" your comments on the granularity of tags and the concept of synonyms, which are both worthwhile, but imho not directly contributing to the questions at hand). I think @ghys did great suggestions in openhab/openhab-webui#155 a long time ago - the "problem" is probably, that the "Overview" page never became the "one-stop shop" for the user so far and he rather opens the "Locations" and "Equipment" tabs to find all he needs. If we had a powerful "Overview" page that is automatically grouping/sorting all there is in the home and that can be customized to the liking of the user, nobody would actually complain about the fact that "Locations" and "Equipment" does not show everything. I wonder if we hence shouldn't focus on improving the "Overview" instead of adding semantics for all channels that exist. Maybe we could also think about a checkbox for non-tagged items for the "Locations" and "Equipment" tabs for the time being. |
|
Two additions: 1.) It would be nice if the checkmark for non semantic items could be made permanent 2.) As far as i remeber there is a bug that group items with meta data are not shown in the tree of non semanic data |
|
My mistake. I was confusing this issue with the other issue about adding new tags and I misunderstood which screen we were talking about. |
|
@rkoshak While waiting for @ghys to chime in here (yeah, it's holiday season, so let's be patient), I'd also be interested in your view on how to best deal with the different "tabs" in the UI - what to show where, how much customisability there should be and what implications this should have on the tags that we add on channels by default. |
|
That's a pretty big topic and I don't really have a coherent set of ideas yet. But I do have some disjoint ideas and things that have been requested on the forum:
In general I think we already have most of the customization options we really need. But some of them are too deep and too hidden to be obvious to many users who don't read the tutorials too closely. And if you don't get this from the tutorials they are not approaches and techniques that could be discovered casually making them unavailable. If we can make them more discoverable it doesn't matter what we do with the tags I think. One thing that might become a game changer overall though is the marketplace. If the marketplace becomes successful, custom Pages and widgets won't be just for very advanced users any more. Users will be able to download and configure very complex unified widgets (e.g. weather forecast, thermostat, media control, etc.) without ever needing to look at or understand the code. When that happens I think users will start building custom pages much more because all they have to do is install the widget, add it to a page and fill out the configuration form. They won't be just for very advanced users as @lolodomo stated. Sorry for the wall of text. I've been thinking on this all weekend. |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/starting-using-oh3/124840/10 |
I would very much like to see this. No matter how extensive or restrictive the semantic model is, there's always something that doesn't quite fit into the predefined model or fits awkwardly. It would be great if OpenHAB allows a custom list of Locations/Equipment/Points/Properties, loaded in a text file structure (yaml?) and/or GUI. I have just started adding semantic tags to my items, with the intention of using them to aid my rules in inferring "related items". Currently within my rule, I am using item name pattern and using string substitution from the current items's name to get a related item. Example pseudocode: I am hoping to use semantic tags to do something like; Currently due to the very limited set of properties, I cannot do this because, there's no "EventData" property. Yes, I understand that nobody else might ever need such a property, which highlights the point for the ability to define it dynamically. Just a typical scenario of a smart light with the following items: Power (on/off), Brightness, ColorTemperature, Color(HSB), I cannot figure out unique properties for these 4 items that belong to the lightbulb, let alone if I want to add ColorScheme, Mode, PulseTime, and a gazillion other custom items that could belong to this light. Currently only ColorTemperature is available as a property. |
|
I just closed my PR #2021 and would like to keep the discussion here for the extention of the semantic model by these two properties:
It's important for e.g. these bindings that I use
|
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/missing-equipments-in-the-semantic-model/134078/2 |
|
Not sure if applicable here but a forum post pointed me at this one, |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/is-it-possible-to-add-new-properties-to-the-semantic-model/135785/3 |
|
This issue has been mentioned on openHAB Community. There might be relevant details there: https://community.openhab.org/t/extend-semantic-model-icons/144239/3 |
|
I made a PoC code in jruby that can dynamically add (but not remove) additional semantic tags. An openHAB restart would reset it back to "factory default". Example: Semantics.add(SecretRoom: Semantics::Room) # Adds Location_Indoor_Room_SecretRoom
Semantics.add(Color: Semantics::Property, label: "Light Color", synonyms: "Colour") # Adds Property_Color
Semantics.add(Staircase: Semantics::Indoor, synonyms: "Stairway") # Adds Location_Indoor_Staircase
So to add the above: Semantics.add(Distance: Semantics::Property, synonyms: "Length")
Semantics.add(Angle: Semantics::Property, synonyms: "Gradient")It works by creating the bytecode of java interface and adding it into the JVM runtime. It also adds the corresponding entries in SemanticTags.TAGS and Locations/Properties/etc. list of members (Locations.LOCATIONS, Properties.PROPERTIES, etc), so that SemanticTags methods will work with the added tags. The only downside is that the list of tags is hardcoded in MainUI, so while it can display it, it doesn't allow selecting the added tags to an item. It works fine for me using textual rules / items definitions.
If openHAB would like to support dynamically adding semantic tags in this manner:
|
|
I've just submitted PR #3519 to allow dynamically add custom semantic tags. |
|
I have now implemented a semantic tag registry. It is now possible to add any semantic tag you like by yourself. |
Related to openhab#1791 Also-by: Christoph Weitkamp <[email protected]> Also-by: Mark <[email protected]> Signed-off-by: Laurent Garnier <[email protected]> GitOrigin-RevId: f6d3f1d
Related to openhab#1791 Signed-off-by: Laurent Garnier <[email protected]> GitOrigin-RevId: 5ae3c67
and others
I open this topic to help improving the current ontology.
Of course, the ontology cannot cover all cases but at least it should cover what most of users will need.
Here are the changes proposed in the next messages.
New location entries:
New location synonyms:
New equiipment entries:
New property entries:
Properties removed:
The text was updated successfully, but these errors were encountered: