Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    erikoskarwallin
    @erikoskarwallin
    I wonder if we could use the newly approach of Collection @hammar ? But it might miss the point a bit. Wemight need to add to REC a “building-complex” class
    Karl Hammar
    @hammar
    That's interesting @haris-zynka. As @erikoskarwallin points out, the RealEstate concept could perhaps be used in simple cases, but that does indeed imply that the entire campus/complex is a single legal entity ("fastighet"). If that is not valid, then we don't in the current version of REC have a good representation of this concept. I think @erikoskarwallin is right in suggesting we define a new subclass of Collection, e.g., "Complex" or "Campus". The question would then be what entites that would be members of such a collection: whether it would be real estates or buildings. My guess is the first is the most flexible: i.e., a campus consists of one or more real estates, which in turn contains zero or more buildings. But I'm not at all a domain expert and we would need to validate this design.
    Do either of you have the in-depth knowledge, or know someone who does who we could run this by?
    Peter Hartlev
    @PeteHart
    I was also immidiately thinking about the Collection as the way to go. Assume that our collegues at Akademiska who actually own Campus (at least I suppsoe they do) have had thought on how to model this domain
    haris-zynka
    @haris-zynka
    So basically we go something like "fastighet" is real estate but they do have a field which can be named "placedIn" / "belongsTo" / "partOf" (my preference would be "partOf") which points to Campus / Complex
    This should be however it's own entity and not collection, in case Akademiska Hus they have maybe more than 1 Chalmers campus and not all of the buildings in side of it is owned by them (or campus in that case). This would be it's own entity as energy consumption is different than summary of all buildings in that area. Reason is as I mentioned that sometimes you could pay for street light, parking spaces etc which are directly linked to campus and not building / real estate
    So it would be separate entity in many cases, it could also have it's own geometries which cannot be represented by only collecting all realestates/buildings
    erikoskarwallin
    @erikoskarwallin
    ifcSite i would guess would be used to aggregate several buildings into 1 entity (without implicating that it should be synonymous with a legal real estate). I would go for Collection - then it will be very clear that it is just “an arbitrary collection of buildings” . @mads (mhra@niras.dk): What do you suggest?
    Mads Holten Rasmussen
    @MadsHolten
    A bot:Site is typically used for a campus or something. In our terminology it is a physically defined zone but is typically used as an aggregation mechanism.
    erikoskarwallin
    @erikoskarwallin
    @MadsHolten Thanks. See here for BOT https://w3c-lbd-cg.github.io/bot/
    haris-zynka
    @haris-zynka
    I would like to note again that campus is not a simple collection of buildings, it can have more information rather than the aggregation of buildings. So collection with extra properties like name, littera, or such would be useful to start with. I guess with current approach anything can have a geometry including campuses/complexes but I'm not sure about the other fields
    1 reply
    erikoskarwallin
    @erikoskarwallin

    RealEstateCore version 3.2 has arrived

    We are happy to announce that RealEstateCore version 3.2 is released.

    Some highlights:
    -Extensive support for analytics and machine learning.
    -A new SensorInterface class, mirroring the design of the ActuatorInterface class from REC 3.1. This allows you to represent shared aspects of a set of identical sensors (e.g., their data schemas) in a single place, reducing duplication across the knowledge graph. It also simplifies translation of RealEstateCore graphs into, e.g., Microsoft DTDL or Web of Things TD.
    -A new Lantmäteriet module, representing the Swedish Real Property Register (Fastighetsregister). This module, intended for the Swedish market, is optional and thus not loaded in REC Full by default.
    -A new Collections class, intended to represent generic administrative collections of things (e.g. packaging of service into new products)
    -Additional Quantity Kind and Measurement Unit individuals supporting waste management and more presence detection use cases.
    -An official alignment to BOT (Building Topology Ontology).

    For details and download, please see the release notes:
    https://github.com/RealEstateCore/rec/blob/develop/ReleaseNotes.md

    Karl Hammar
    @hammar
    Hey all! I've spent the last hour or so going through my backlog of notes from a variety of meetings with REC community partners, and posted issues on our issue tracker for following up on these meetings. See https://github.com/RealEstateCore/rec/issues. The REC Tech Committee will hold its next meeting on August 24. At that point we'll probably sketch out the roadmap for the next 1-2 versions of REC, based on these issues and others that are brought up before then. If you have something that you would like/need to see done, please do not hesistate to add issues or to comment on those issues we have in the tracker.
    erikoskarwallin
    @erikoskarwallin
    Great - I will add later an issue for the work I’m doing togheter with VK, Tmpl, et al. for the need of extended expressivity for the biz-admin domain.
    Karl Hammar
    @hammar
    Hey all. Related to the "Campus" requirement, I took a first stab at https://github.com/RealEstateCore/rec/tree/feature-campus. This is a representation of campus as a collection of real estates (fastigheter). Since that collection has its own identity, it can be assigned geometry. It's membership is defined using the "hasMember" property, and the inverse is "isMemberOf". That's pretty much it.
    Karl Hammar
    @hammar
    Also: some new room types in upcoming REC 3.3: cable room, mail room, mothers' room, etc. If you need more room types that are not covered in REC already, ping me here or ask on issue RealEstateCore/rec#83
    Also, in REC 3.3 we will probably include the notion of building types -- e.g., hospitals, schools, shopping malls, etc. Do you have input on what types should be included? Let us know at RealEstateCore/rec#82
    Karl Hammar
    @hammar

    Hey all. As you may have seen in the issues list and in the "develop" branch, I have, based on the expressed needs of some strategic partners, been working on an "Equipment" class and hierarchy. This largely mirrors Brick, and will primarily deal with things that are mounted in the building, e.g., HVAC systems, plumbing, elevators, etc.

    Initially I have myself thought of these Equipment things as being disjoint from Devices. We have Devices that we communicate with (Sensors/Actuators), and these may act on, serve, or sense data from some legacy Equipment system. The divided is something along the line of "Equipment is dumb, Devices are smart", or "Equipment contains machinery, Devices contain microcontrollers". So in modeling a Smart HVAC-system for instance, I guess I'd think of it as an HVAC system being equipment, and it's controller being a Device, and the Device being mounted physically inside of the Equipment.

    But of course, in light of the increasing smarts being built into all sorts of systems these days, this could be quite a backwards attitude, to differentiate in this way. I'm interested in hearing how you think of these things and how to express these relations in your use cases.

    Jarno Pelkonen
    @jarno-nuuka
    Hejsan! My name is Jarno Pelkonen and I am product director at Nuuka. Nuuka is a cloud-based solution for analyzing and optimizing building health and performance over large portfolios. Our customers include Helsinki City, ICA, H&M. We have just applied to join RealEstateCore Consortium. We are still getting our heads around the topic, but we understand the value of shared semantics/ontologies in inter-system operations. In addition to Nuuka analytics and AI applications, we also offer our platform (and intelligent gateway) as a service to connect buildings into the cloud (we have over 100 building automation system integrations implemented). This integration between different systems can be quite laborsome sometimes costing us time and effort. We are looking into shared, standards-based ontologies to smoothen the integration work, enable new value adding functionalities and better interoperate with other solutions. Our intent is to align our product with REC/Azure Smart Buildings. At this point we are still learning and studying, but hopefully will be later able contribute back to the community.
    Cheers & Terveisin, Jarno
    Karl Hammar
    @hammar
    Welcome @jarno-nuuka, it's a pleasure to have you here, and I look forward to talking more with you and your colleagues!
    erikoskarwallin
    @erikoskarwallin
    Hello @jarno-nuuka - Welcome to REC :-)
    Kaushik Roy
    @kaushikCanada
    hi all
    i am working on a lot of properties that we maintain and the data regarding them. how can i host this on my own instance?
    erikoskarwallin
    @erikoskarwallin
    Hi @kaushikCanada
    You need to get some IoT/Smartbuilding/Digital Twin platform. I don't know how good Fiware (open source) is at suporting a selectable OWL-ontology (e.g. RealEstateCore), however the Microsoft Azure Digital Twin is “pre-loaded” with RealEstateCore (https://github.com/Azure/opendigitaltwins-building)
    Prafull Kotecha
    @prafullkotecha
    @erikoskarwallin - Any links or pointers to connect RealEstateCore with Baja Object Graph (used by tridium's niagara platform)?
    poocog
    @poocog
    Looking at Azure Digital Twin with RealEstateCore ontology. Does anyone have an example twins collection that I can use so I don't need to create just for testing? I work with Digital Twins in Cognite AS, and I have previous BIM /IFC experience and recently Oil and Gas ontology information modeling experience with OWL2.
    Karl Hammar
    @hammar
    @poocog I don't have any data -yet-, but I am implementing a small-scale REC-based Smart Lab at Jönköping University, Sweden, where I believe we'll be able to open-source a lot of the data and configuration details as we proceed. But for larger and more complex installations, so far, we don't have any publicly available data (though there are substantial deployments within partner companies, these tend to be private). @erikoskarwallin do you know of any public REC datasets?
    erikoskarwallin
    @erikoskarwallin
    @poocog It is coming from Fastighetsdatalab (“Realestatedatalab”), an open project where a property owner has opened up all the data and will share access to REC encoded data. Data owner is rickard.dahlstrand@electricitystockholm.se
    Karl Hammar
    @hammar
    @prafullkotecha My apologies for the very delayed response; we don't at the moment have any REC-BAJA graph interlinkage or recommendations; if you have any pointers to public resources/models, we could certainly investigate the feasibility of aligning. My only results when searching this space is PDF files referring to a long-dead JSR 60 process; so my initial impression is that this is an internal/proprietary spec (or at least not widely published online)? But again, certainly open to looking into it!
    poocog
    @poocog
    @erikoskarwallin @hammar Thanks for the response. I'll keep watching and contact Rickard.
    Tomas Hesse
    @saegen
    Hi! New to the group. I would like some guidance in REC, since I'm new to most of this. I'm trying to model against REC but I have a hard time understanding it. I've just installed Protege and loaded from Url. For instance there is a rec/core and rec/full (3.2)
    I thought core was a subset of full but for instance Premises type i deprecated in full but not in core.
    erikoskarwallin
    @erikoskarwallin
    Hi @saegen. The full loads core + all modules (e.g. building, device) See the “Active ontology” tab in Protege and there se the “Ontology imports”. Its a lazy way of getting all modules loaded at once :-)
    Welcome :-)
    Premises, try the /3.3/ - there its depricated in both (might be a bug in /3.2/
    Tomas Hesse
    @saegen
    @erikoskarwallin Thank you, I'll have a look at 3.3.Thougth 3.2 was the latest
    Tomas Hesse
    @saegen
    Thank @erikoskarwallin, 3.3 was better. However I'm still facing difficulties. In short: I'm trying to model this: https://raw.githubusercontent.com/Azure/opendigitaltwins-building/master/images/OntologyDiagram.JPG in .net (core) implementing this https://github.com/Azure/opendigitaltwins-building/blob/master/images/UsingModels.JPG
    Tomas Hesse
    @saegen
    I get the feeling I'm missing something fundamental here.. In .net, I can not map OO to the things I'm seeing in Protege. Somethings are Classes and sub-classes that I feel should be enums for instance. Example Unit: SubClass DerivedUnit
    Another is Collection with subclasses Asset Collection and Portofolio. "Portfolio SubClassOf includes some owl:Thing" this sentence does not make sense to me really..
    Tomas Hesse
    @saegen
    I generated java classes from Protege, I'll have a look at those
    Karl Hammar
    @hammar
    Hi @saegen! The OWL language that REC is based on allows a great deal of modeling flexibility, more so than most traditional OO programming languages. It includes things like property subsumption (i.e., in OO parlance inheritance not only for classes but also fields), narrowing of property restrictions on subclasses (in OO parlance overloading fields, not only methods, on subclasses), type inference based on restrictions (e.g., duck typing), etc. A mapping of OO language features to OWL language constructs will probably never be 100 % accurate and complete. The same applies to Java code generated using generators such as provided in Protégé; they are at best reasonable interpretations.
    Also, OWL is an open-world logic modeling language, not an OOP schema description. Open world implies that we sometimes deal with statements that we only have partial knowledge of. E.g., in the Portfolio example you provide, there is a property "core:includes" which has as its domain (i.e., it applies to) "core:Collection". This does NOT imply that every instance of a "core:Collection" must have that property populated with one or more values. By defining that "Portfolio" is a subclass of "Collection", and that the restriction "includes SOME Thing" applies to it, we are in fact adding such a requirement for the property to exist at least once for any instance of Portfolio
    Karl Hammar
    @hammar
    Another way of saying that is that "Portfolio" has the restriction "includes min 1 Thing". That would logically be equivalent.
    For the Unit/DerivedUnit, it sometimes makes sense to give units identity. That way, one could reason about which units which are scales of one another, for instance ("Millimeter is derrived from Meter"), which we could not do if these units were simple enums.
    However, we can not take credit for these design choices specifically; we are reusing the QUDT ontologies and datasets (http://qudt.org), which are reasonably well-established
    Karl Hammar
    @hammar
    As an aside, this conceptual gap between traditional constraint or schema languages on the one hand, and the open world and logic-derived languages on the other hand, is a known barrier-to-entry to using semantic web technologies outside of niche communities. There are approaches trying to bridge that gap by making semantic technologies more "web-friendly", e.g., JSON-LD, SHACL, etc. I'd love to see those take off. Perhaps a SHACL variant of REC could be something to consider for the future.
    Tomas Hesse
    @saegen
    @hammar Thank you, it's been a challenge to map OWL <-> OO so your help is much appreciated. Ifyou would be interested in helping out with more concrete issues in the future I would be much obliged :)
    Karl Hammar
    @hammar
    @saegen Sure thing! Just beware that I am rather slow in responding lately due to sharp increase in tasks to manage; but with that caveat, if there's anything I can help with, just ping me here or via email.
    Jarno Pelkonen
    @jarno-nuuka
    Hello, is there documentation describing REC's design choices and reasons behind?
    erikoskarwallin
    @erikoskarwallin