Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Karl Hammar
    @hammar
    @mwdhont There no such standard Excel representation formally delivered by the consortium; but it might be an idea to put on the roadmap, given the frequent use of CSV-based data (e.g., tag lists) and the need to ingest such data. What do you think @erikoskarwallin, something we should put some effort into standardizing?
    skayred
    @skayred
    Hello, I am Dmitrii from Nuuka, and I have several questions regarding the ontology. We are going to implement the new API (GraphQL) for the company usage, and I would like to have it REC-compatible. We use C# as the primary language, so question 1 - is there any tool or ready-made set of classes for C# (I have managed to generate some classes from the OpenAPI YAML, but I am not sure, how actual is the YAML)? Also, we want to have some BMS-related data (import identifier, minimal and maximal values to identify the anomalies, import formula and several util fields) - Erik recommended to use hasAliasID or sameAs for an import identifier storage, but I don't see any of those attributes. As for formulas - seems like AdditionalProperties is the place for that, but minimal and maximal values are a bit different, what could be the best place for that?
    Michiel Dhont
    @mwdhont
    Hello, If you want to model a virtual capability (=measurement) which is the sum of two other capabilities (or any other formula). What's the best way to do this? I feel like some relationship is missing here.
    Karl Hammar
    @hammar

    @skayred Hi! The RealEstateCore consortium does not have a ready-made SDK with data classes and such (yet). Idun Real Estate Solutions, one vendor of RealEstateCore platforms, has a repo with some such content at https://github.com/idun-corp/Idun-Examples; but this is an Idun repo, not supported or licensed by REC.

    Re. the issue of linking out -- in a semantic web application you would use owl:sameAs or rdfs:seeAlso predicates on nodes to link out in this manner. These are not part of the REC specification itself, but rather part of the underlying modeling languages (RDF and OWL) themselves. If you are instead using the DTDL versions of the models (https://github.com/Azure/opendigitaltwins-building), the top-level classes have been augmented with linkage maps (string->string, for external system-> external id) through the property "externalIds"

    Karl Hammar
    @hammar

    @mwdhont For REC 3.3 we have the notion of "AnalysisProcess" that might be extended to support such modeling. Presently it only links to Observations, not the Capabilities themselves. Do note that due to perceived lack of usage, this class may be deprecated in REC4 (see below).

    For REC4 we are working with the Brick Schema consortium to align Capability/Points models. Essentially, we want to ingest Brick Schema straight off, and reuse their points hierarchy. In Brick Schema, you would use Point (OWL Class/SHACL NodeShape) -> aggregate (object property) -> AggregationShape (OWL Class/SHACL NodeShape), where the latter has properties for aggregation functions and intervals. See https://docs.brickschema.org/metadata/entity-properties.html for some more docs. I'm not sure exactly how one might model the sum of two different points. Maybe two aggregate links from both "real" points to the same aggregateshape would work?

    Another approach might be to handle this aggregation out-of-band, i.e., in documentation. That's how spatial points could be handled -- the room itself doesn't really have a temperature, there is a temperature sensor in the room that measures a temperature, so the temperature point on the room is to some degree "virtual"
    mikebarker100
    @mikebarker100

    What do the REC Members think about :-
    1) Building Energy Data Exchange Specification (BEDES)
    https://bedes.lbl.gov/

    2) BuildingSync
    https://buildingsync.net/mlod

    Could the BEDES naming convention be of any use in the EU ? ( Given that it using some US terminology )

    erikoskarwallin
    @erikoskarwallin
    Great compilation. We are aligned with Brick Schema and works close with 223P and BOT.
    I found an csv-file (BDES V2.3) and an xml-version of the BuildingSync. Seems like they are good representation of different domains. Do you know if any rdf-based representation exists?
    mikebarker100
    @mikebarker100

    @erikoskarwallin - apologies - i am an outsider from South Africa trying to understand more about data structures for energy data. We are looking for a common set that appeals to both sides of the Atlantic. I await your webinar ! My focus is on standards for MicroGrids and Energy Flexibility. If of interest, please consider joining this fledgling LinkedIN Group for Professionals :-- Grid-interactive Buildings - Energy Flexible Buildings - 24/7 Carbon-free Energy
    https://www.linkedin.com/groups/13513691/

    700 members, and a carefully curated spam-free resource

    mikebarker100
    @mikebarker100
    Another interesting schema is the US Green Button. " Green Button specifies a full XML schema for representing a utility customer's account, bill, and usage data " https://utilityapi.com/docs/greenbutton/xml
    erikoskarwallin
    @erikoskarwallin
    Mike,
    Just joined the LI-group :-) It is really needed to align energy ontologies with REC. @mwdhont are working with this in conjunction with REC. I’d be happy to assiste to converge standards :-)
    mikebarker100
    @mikebarker100
    Hey @mwdhont - that Open Energy Ontology looks useful ? Can we discuss please ? https://openenergy-platform.org/about/
    Michiel Dhont
    @mwdhont

    Thanks for the reference Erik.

    Hi @mikebarker100, we have internally made an evaluation of the energy modelling language out there. Our current approach is to await the merge of REC and Brick and tap our own electricity modelling into that. We are hesitant to adopt still another ontology, because it would (1) require significant alignment (2) raise the risk to be dependent on an ontology which is often not continuously supported anymore (3) require some conversion to DTDL to make it workable in our Azure architecture.

    That being said, we would be very happy to contribute our representations to REC + Brick and make them open source. We are espacially active in the domain of renewables (EV, Battery, PV ...) and both REC and Brick have some leaps there, as far as I can judge.

    mikebarker100
    @mikebarker100
    Thanks Michiel, understood. I will wait to see what happens at the webinar
    Karl Hammar
    @hammar
    New REC Assets & HVAC modelling guide just dropped: https://dev.realestatecore.io/docs/guides/assets_hvac/
    Karl Hammar
    @hammar
    And now a new Tenant & Leases modelling guide: https://dev.realestatecore.io/docs/guides/tenant/
    erikoskarwallin
    @erikoskarwallin
    mkt bra - hur blev det med TenanatUnit?
    Karl Hammar
    @hammar
    Re TenantUnit — trying to find suitable nomenclature that doesn’t make it sound 100 % residential, but it wasn’t resolves in time for Tuesday’s preview release and webinar. Technical committe has some suggestions in an email thread and hopefully we can have a pull request including that early this coming week.
    Same goes for the legal construct RealEstate used in at least Northern Europe (e.g., Fastighet in Swedish). It’s generally agreed this should be in the model just as in REC 3, but we need to find a suitable term for it that isn’t too ambiguous. Should also be resolved very shortly.
    Karl Hammar
    @hammar
    Re. the TenantUnit discussion - I misremembered that discussion, mea culpa. The MVP suggestion is to revert to the Premises nomenclature we've used in earlier versions, see https://dev.realestatecore.io/ontology/Collection/Premises for current definition.
    sarajanhall
    @sarajanhall
    Hej Karl! Vi blir hindrade av Microsoft Windows att köra pluginnen ExcelRDF - kanske funkar den inte med vår version av Excel? Eller vad kan vara fel?
    Karl Hammar
    @hammar
    Hi @sarajanhall. The ExcelRDF plugin is essentially abandonware at this point; it would need at least a couple of weeks of work to get it to a polished and finished state suitable for end users. Among other things, the code signing certificate used has most likely expired, which would cause the installer to complain about the code being potentially malicious.
    If you want to run it all the same, I'd suggest installing the VSTO workloads into Visual Studio, downloading the project source, and debug-running it from there. That should work regardless of certificates and other things.
    I might also suggest https://openrefine.org/ with the RDF plugin. It is somewhat more technically convoluted than ExcelRDF but it should be able to accomplish the same things, and is a more evolved "Swiss army knife" of data transformation.
    Karl Hammar
    @hammar
    Note: OpenRefine probably does not generate your Excel skeleton, but for the Excel -> translation it should work (again, with that mentioned RDF extension)
    PereiraUCD
    @PereiraUCD

    Hello Dr. Hammar
    We are developing a Digital Twin for one of our office buildings to showcase how we can leverage the twin tech as our main source of truth.
    My next step now is to implement a weather station twin; which will be used for ML and RL applications and display current and 30,60,120 min predictions. We have software that gives me access to live and predicted weather via API calls.

    My idea now is to build a weather station using the asset class, that would host a weather station logical device that contains a number of weather capabilities (which would be me extending the sensor capability from the REC ontology). I did some quick research and I could not find anything similar to this, so I was wondering if you could give me some feedback on the idea. I’d love to have your expert opinion on the approach I am taking to the problem. Note that I am far from being an ontology expert and I am starting my journey into software development.

    Thanks in advance

    mikebarker100
    @mikebarker100
    @PereiraUCD - Hi, i share your interest in weather data. Microgrids need nearcasting.
    PereiraUCD
    @PereiraUCD
    @mikebarker100 Thanks!! I have all the pieces to deploy my weather station over here, just waiting for the ontology experts to know if my way of thinking is in line with the standards for this novel application
    Karl Hammar
    @hammar
    Hi @PereiraUCD! At the time of writing, Brick (and by consequence REC4) is a little underdeveloped in terms of sensor assets describing the physical boxes that measure things, e.g., weather. The Point hierarchy is well and fully featured however. So I'd say there are a couple of options:
    1. Assign suitable Sensor points directly to whatever spatial representation you need for your analytics (building, site, room, region, ...)
    2. Add a generic high-level Asset, giving it an appropriate spatial placement, and add Points onto it.
    3. Subclass a suitable existing Asset, adding whatever criteria you need to be able to represent about your physical sensor hardware. Maybe push to get that into Brick as well, if there is a gap there that the Brick community agrees on
    Note the LogicalDevice and Capability classes are from REC 3.3. They absolutely work fine still if you prefer to work with that version. But if you're looking to future-proof, the upcoming REC4, built on REC + Brick, is probably a long-term safer bet, and that is what I'm referring to in my previous post
    Let me know if you want to throw ideas around about REC 3.3 implementations (either in OWL/RDF or in DTDL)
    REC 3.3 Capability = REC4 (Brick) Point
    REC 3.3 LogicalDevice = not in REC4
    REC 3.3 Asset = REC4 Asset (with the lion's share of actually defined Assets being in the subclass Brick:Equipment)
    Karl Hammar
    @hammar

    Hey all. I'd like to draw your attention to this poll about REC modelling style, specifically on the merits (or lack thereof) of open-ended links (DTDL Relationships/SHACL object properties):

    https://github.com/RealEstateCore/rec/discussions/157

    This came out of the most recent REC Technical Committee meeting. Your input will be valuable in deciding how we proceed on this for REC4 GA release.

    Michiel Dhont
    @mwdhont-auge
    Hey, with respect to the identifications of the models: I see REC does not longer uses URI's in their documentation, but DTMI.
    1. Can we assume jthe use of DTMI's will be continued in the future?
    2. What's the reasoning behind?
    3. Will Brick follow the same approach?
    Karl Hammar
    @hammar

    @mwdhont-auge Starting with REC4 we will release as both DTDL and SHACL. The documentation is autogenerated from the DTDL models, so the identifiers showing therein are DTMIs. SHACL is however still a supported formalism going forward. It might be worthwhile to generate a separate SHACL documentation but we don't have the bandwidth to do so at the moment.

    Brick is using SHACL exclusively (well, with a little OWL sprinkled in here and there) and per my understanding will continue to do so.

    DTMIs are generated from URIs using the following method, rather straight-forward: https://github.com/RealEstateCore/SHACL2DTDL/blob/93a83c431b300ca34ef2155433c73d3b070806e6/Program.cs#L653
    Michiel Dhont
    @mwdhont-auge
    Hi Karl, thanks for elaborating!
    Hannes Stockner
    @hannesstockner
    Hi, first of all thanks for all the information about creating an ontology!
    How do you create the following API Specification: https://github.com/RealEstateCore/rec/blob/main/API/REST/REC4API.yaml. Do you have a script which can create that based on the ontology in an automated way? Thanks a lot
    Karl Hammar
    @hammar
    Hi @hannesstockner! Yes, the API spec is autogenerated from the ontology using this tool: https://github.com/RealEstateCore/DTDL2OAS. Note that that tool has passed through zero QA and is entirely unsupported. E.g., the documentation on how to run it may be faulty, and it may yield unexpected results. I hope to clean it up a little in the near term and integrate into our CI actions, such that the API is autogenerated upon merge of DTDL sources to the main branch at the REC GitHub repo. Also, there's no license on it at the moment.
    1 reply
    Next step would be to build an implementation generator for the same API
    Michiel Dhont
    @mwdhont-auge
    What's the reason 'TenantUnit' is no longer in REC?
    Peter Hartlev
    @PeteHart
    @mwdhont-auge it’s there but renamed to Premises which we found were a more precise term https://dev.realestatecore.io/ontology/Collection/Premises
    Michiel Dhont
    @mwdhont-auge
    Ok, thanks.
    MarinLjuban
    @MarinLjuban
    Hey people, in the Brick -REC conference video i saw the BIM requirements version 2 mentioned as WIP. I am wondering, is it possible to find that first version from 2018 somewhere online, and also, is there an approximate timeline about the release of the version 2?
    erikoskarwallin
    @erikoskarwallin
    @MarinLjuban The old 2018 is only availble in SE (I’ll pasted a link to iut here: https://drive.google.com/file/d/1dZoQEWGJfrJNnh2-FCEUsYcRSw3uo-OY/view?usp=sharing
    (A new one with more examples etc is in the making, eta before xmas)
    MarinLjuban
    @MarinLjuban
    Great, don't understand SE but good enough to get the grasp of the document scope. Looking forward to the new one and hoping to examine it from the BIM point of view, so I'll make sure to give feedback if I have any.
    Michiel Dhont
    @mwdhont-auge
    Hi, with aug.e we would like to ramp up our engagement and make a pull request with some suggestions. However, it's still unclear to us what is the current 'source-language' of REC. On the one hand, I read on the website that DTDL is the source, on the other hand I can only find the SHACL2DTDL-translator online.

    Can you confirm

    1. What is the source: SHACL or DTDL
    2. Point me to a DTDL2SHACL-translator in case answer on 1 is 'DTDL'

    Thanks!

    2 replies
    Michiel Dhont
    @mwdhont-auge
    Additionally, is it correct that "serves"/"servedBy" and "observes"/"observedBy" are no longer present in the combined ontology REC/BRICK? What's the current best practice to link equipment with spaces? Like:
    "Room servedBy Terminal_Unit"
    "Zone observedBy Meter"
    ?
    3 replies
    Hannes Stockner
    @hannesstockner

    Hello, we are integrating a device that sends us the following content every x seconds:
    TemperatureSensorValue: 8 (double)
    TemperatureSensorWarning: false (bool)
    TemperatureSensorError: false (bool)

    In our ontology we have created a TemperatureSensor, but we are not sure how to handle the warning and error status (both can be true at the same time). Do you have a suggestion on how we should model/handle this?

    2 replies