Extending semantic tagging

Hello everyone.

Currently I play a little bit with habot and semantic tagging in openhab and I like the main idea very much, but I can’t really use it because of its limitations.

My current setup (simplified) looks like:

Group gFF                               "Erdgeschoss"             ["GroundFloor"]
Group FF_Livingroom                     "Wohnzimmer"     (gFF)    ["LivingRoom"]
Group:Switch:OR(ON, OFF) Lights  "Lampen"                         ["Light"] { synonyms="Lampe,Lampen" }                                 

Dimmer Light_FF_Livingroom_Diningtable   "Wohnzimmer Esstisch" (Lights,FF_Livingroom) ["Setpoint"]

If I ask for the synonym “Lampen” I get all items assigned to the group “Lights”.
If I ask for “im Wohnzimmer” I get everything assigned to the group “FF_Livingroom”.

But If I ask for “Lampen im Wohnzimmer” I get nothing. Also If I ask for “im Erdgeschoss” I get nothing. The same happens for other groups like a group “Temperatures” too.

Also If I ask for just “Wohnzimmer” I get only items where “Wohnzimmer” is part of there name and not where “FF_Livingroom” is assigned.

I know that I should assign “Light” to the items directly and define the synonym every time again. But this means I have to do it for 40 items. This is just one example. If I follow this practice for my complete home configuration I have to duplicate really a lot.

I also saw the argumentation that we use the semantic tagging concept from eclipse which is so strict. (Allows assigning points or equipments only to items and not groups)

But on the other side, I don’t see that the eclipse project is interested to handle scenarios like that and find solutions to make it easier.

So my question is, why not extending it on our side.

I explored the code already a bit and found the 2 classes/functions

SemanticsServiceImpl.getItemsInLocation and SemanticsItemResolver.getMatchingItems

in the first one, we identify location groups but following only to their direct members and in the second one, we identify equipment, point and property items by checking assigned tags on items directly.

My recommendation is, to always resolve group items recursive in both cases. Means for location items we fetch all recursive item members and for equipment, point and property items we check the group itself plus all recursive item members.

This would fix all above mentioned use cases except the last use case where I ask only for “Wohnzimmer”, but this could be discussed later.

Now, before I change the code on my branch I want to hear arguments against it. Why was it not implemented in this way.

I don’t want to hear “the specification from eclipse described it in this way”. I want to hear more the explanation why it is important to follow the specification so strict and why we are not extending the specification to be more useful for us. Currently I have the feeling that this is blocking us from creating a better solution.