Rearranging ontology's hierarchy

Setup, Configuration and Use Beginners
1
  • Platform information:
    • Hardware: AMD64/8GB/2x256GB SATA flash units
    • OS: macOS 10.14
    • Java Runtime Environment: Unsure, according to java -version: "17.0.10" 2024-01-16 LTS
    • openHAB version: 4.1.1
  • Issue of the topic:

I’m trying to build the structure of the infrastructure but the items of the semantic thing have different child policies. If structure in a way that makes sense to me, I’m cut off pretty much right at near the top. It goes:

From: https://www.openhab.org/assets/img/ontology_relationships.d50b5cd6.jpeg:

  • Location - which I think as an area as in geographic region i.e; to distinguish multiple properties
    • Indoor/outdoor - self-explanatory but I think, not in the correct level of the hierarchy
      • Building
        • Room
      • Corridor (transit area?)
      • Floor/level ← metagroup/level?
        • Attic - room or floor level?
        • Basement - room or floor level?
        • Room
        • Floor/level
      • Room ← metagroup/level?
        • Room
    • Outdoor
      • Garden
      • Terrace

Room and floor levels appear to be groups of groups but not real stops, that’s depending on what attic and basement mean, i.e, if they considered rooms or levels since each can-, and usually is both. Honestly, I haven’t thought that through because I’m held off way above and resorting to making my own thing and keeping track of it. But, that’s another story.

But what has driven me to insanity is the indoor/outdoor situation, maybe it’s a language barrier, y’know how the sun and the moon have the opposite genders in German vs Latin languages (French, Italian, Spanish, etc)? And has this thing called dative which sounds like “to give” which kind of has direction and that relates to space, maybe there a different notion of outside… I don’t know! My head is a very busy place.

Then again, as I understand, in most European countries people speak better English than native speakers and I’m always presented an English website on openhab.org, even when I’m visiting through an address from a region where another language is spoken.

openhab-semantics-dynamic-background-optimized
( ↑ …very, very busy)

Exterior can’t happen without something it’s the exterior of. It can’t be location either because then “exterior” wouldn’t be exterior but rather something contained by location which would make it the interior or location, make sense?

I thought about this in many ways, perhaps I’m missing something. I thought maybe if I see it from the viewpoint of somebody living in an apartment, but it wouldn’t change anything because apartments don’t just float in the floor they exist, the floor, building and location of the building must still ideally be at least acknowledged loosely even if there nothing we have control of in those areas.

Therefore, I think, location may have one or more buildings, such as the main building and a toolshed for example, and each of those has an interior with at least the main level, and an exterior, which could be the exterior lighting that used to be switched on/off from inside their respective buildings. In other words, exterior is the surrounding area of a building, most of the time parallel with the main level, but can have a second and underground level as well. Like alternate dimensions as in scifi.

So, I’d like to rearrange it like:

  • Location, e.g; city, neighboorhood
    • Building, e.g; “Home”, “Beach House”, “Central”
      • Indoor
        • Basement room (basement level implicit)
        • Main level
          • Kitchen
          • Entrance, etc
        • First level/Second floor/…
          • Bedroom
            • Walk-in closet
              • Bathroom
            • Bathroom
          • Bathroom
        • Attic (level implicit)
      • Outdoor
        - independent multi-level -
        • Main level
          • Frontyard
          • Frontyard
          • Backyard
          • Pool area
            • Poolbar
            • Showerhead/bathroom
        • Level 1-below
          • Garage ramp
        • Roof
          - consolidated multi-level -
        • All levels
          • Frontyard
          • Frontyard
          • Backyard
          • Pool area
            • Poolbar
            • Showerhead/bathroom
          • Roof

Anyway, I could, like I have so far, create my own structure with its own nomenclature and maintain it, which will do while I’m working with it. Once the system is autonomous enough, I won’t touch it [in hopefully] ever, and when the time comes to change something, I’ll probably screw it up massively. I could use what it’s there already, but it makes no sense specially when you have type, category and semantic class to worry about, it’s not just the one field. I still don’t fully get it. It’d be the same end.

From the ease of Debian repos, I moved to macOS because its TTS is very good, but the deployment is very makeshift, and I had to modify one of the launching scripts to correct the Java version, so I figured; I already messed with the code, I won’t be able to upgrade, might as well dive in to find where I can switch the names of those groups.

If it’s possible, where can I find these values stored?

BTW, by “code” I’m referring to scripts, I don’t know any proper programming language. I know a little bash and identifying command strings in scripting languages. Not C. Not programming.

Just as good would be the reasoning behind the hierarchy, then it stops being a problem, I don’t need to modify code, and there’s better chances for updating the installation. :slight_smile: Please?

Thanks.

2

The ontology is really there to represent a single building, and it’s less important than one might think because you can create your own UI views.

If you nonetheless want to mess with it, check out this

3

I agree with Marcus. You are probably putting too much thought into this. All that really matters with the semantic model is that it reflects the physical layout of your home automation from the perspective of the users if the home.

But there is one thing I think you are missing in the hierarchy.

The hierarchy is an inheritance hierarchy. The hierarchy is an "is a’ relationship. A Bedroom is a Room which is a Location. Location is at the top of the hierarchy, meaning everything below Location is also a Location. Indoors, Outdoors, Room, Kitchen et al are all Locations. They are just a more specific type of location.

So the main purpose of Location is to be the root of the hierarchy and to distinguish between a Location and an Equipment and a Point (which are the roots of their own respective hierarchies of is a relationships, though those hierarchies are pretty flat).

Location doesn’t really carry any other special meaning in the semantic model than that. You’d usually only use the Location tag as the what you inherit from when defining a new tag. You wouldn’t actually use it in your model. You would use something lower down in the model.

Once you realize that, you should realize that the hierarchy of the tags had little bearing on the hierarchy you build in your semantic model. You can put exterior under the building or aside your building in your semantic model. The model doesn’t care. You can make the Kitchen be the root of your model and all other rooms and locations fall under that if you want. It works be odd but the semantic model doesn’t care.

So create your model how ever makes the most sense to you and the users of your home. Don’t worry about the hierarchy of the existing tags. That really only matters when creating your own tags. And when creating your own tags, just realize your new tag inherits from that hierarchy and Location is at the root of the hierarchy. That’s all.

Given this, if you do want to create a “neighborhood” tag for some reason, create a new tag that inherits from Location. You can make that the root of your semantic model if you want. I don’t see it adds anything unless you are managing multiple neighborhoods from the same OH insurance, but if it works for you go for it.

4

First of all, thank you both for answering,

I started reading the linked page and it seems that might be it.

I agree that any place is a location, but I’m a newbie y’know? And who am I to argue with the docs which explicitly instruct to choose group for the… um, group rather than location; an option just about everywhere you look. If I’m not mistaken, the only time it mentions to select location, is at the very first button that says Add Location and there are no alternatives to the same thing.

But as you guys correctly asserted, I do overthink things (check out the original for the drawing, it’s got alpha but it’s still visible in light/dark background bc “what if the forum is responsive?”), so when I get these many locations, and then I’m told just to disregard them and go with the group option, it might’ve had set one or two disorders into high gear. :laughing:

It’s really confusing. But, anyway… I’m thankful for your help and advice, “just f**k it” (I’m paraphrasing) is exactly what I needed to hear, so to speak. After just skimming that post though, I hadn’t realized there was so much changed. My last install was version 3-something. I’ve got homework to do.

5

openHAB has a number of terms of art. Unfortunately they are commonly used words. When I write a post here on the forum I usually capitalize the word when referring to the technical OH word rather than the common meaning. So you might see “The Thing is the thing!”.

Unfortunately there are a few terms even within OH that have multiple meanings depending on the concept. Location is one of them and one of the worst offenders.

Context What it means
Item types a lat/lon/alt coordinate
Building your Semantic Model a Group Item with one of the Location tags (e.g. Indoors, Room, Kitchen, Basement, etc.)
Semantic Model Tags the top level type for all the Location tags is called “Location”, all other location tags inherit from the “Location” tag
Regional Settings the lat/lon coordinate for your home used by come bindings (e.g. Astro)

The term “Script” is almost as bad.

So in the context of building your Semantic Model, all the Locations in your model will be a Group Item with one of the Location semantic tags applied. The tag indicates what type of Location the Group Item represents. Group membership represents what is physically located in that space.

Consider my Semantic Model:

image
image930×2432 192 KB

Things of note:

  • everything with a map pin icon is a Location, everything with a box icon is an Equipment, everything with a bolt icon is a Point
  • the hierarchy is built through Group membership; The Basement Long Term Radon Point Item is a member of the Group Basement Airthings Wave Plus which in term is a member of the Den Group which in term is a member of the Basement Group which in term is a member of Wuthering Heights.
  • you can see the tags under the Item label
  • I have two houses which form the root of two separate hierarchies
  • I have an Outdoors location under Wuthering Heights but don’t use Indoors at all, it doesn’t add anything to my model so I don’t use it
  • There are some “global” Equipment which are directly under Wuthering Heights instead of being placed on a floor or in a room. This is because I want to see the weather (for example) as part of the root Wuthering Heights Location, not buried under Outdoors. That’s where I expect to see it and more importantly, that’s where my family expects to see it, so that’s where I put it. Usability trumps “correctness”.
  • You can’t see this, but only about 60% of my Items are members of the Semantic Model. And even then a number of Items that are in the model have visibility set to false because I represent multiple Items in one widget.

The Semantic Model is there for you to model your home how you want, not to impose a structure on you.