Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

rec:substance #151

Open
ektrah opened this issue Sep 15, 2022 · 8 comments
Open

rec:substance #151

ektrah opened this issue Sep 15, 2022 · 8 comments
Assignees
Milestone

Comments

@ektrah
Copy link
Contributor

ektrah commented Sep 15, 2022

(Re-opening this issue here so it doesn't get lost.)

rec.ttl currently defines the rec:substance property like this:

rec:substance
a owl:AnnotationProperty ;
rdfs:domain rec:feeds ;
rdfs:domain rec:isFedBy ;
rdfs:label "substance" ;
rdfs:range [
a rdfs:Datatype ;
owl:oneOf (
"ACElec"
"Air"

This turns the rec:feeds and rec:isFedBy properties implicitly into classes and makes every subject in a rec:substance statement an instance of both the rec:feeds and rec:isFedBy class, which seems rather odd.

I'd propose to model this in one of the ways shown here (e.g., N-ary Relations):

What RDF star Improves
(source)

/cc @gtfierro

@hammar
Copy link
Contributor

hammar commented Sep 20, 2022

Thanks for keeping this issue alive! I'll set aside some time this week to look into options either in REC or possibly in collaboration with Brick.

@hammar
Copy link
Contributor

hammar commented Sep 23, 2022

Hi again,

After sync w/ Brick, their approach is likely to be to fall back to ASHRAE 223P for representing details of connections between equipments, such as substances being fed. That leaves RealEstateCore with two options:

  1. Removing substances from the ontology as out-of-scope, also referring to the Brick/223P solution for those use cases where such modelling is needed.
  2. In REC implementing a custom SHACL/RDF-compliant representation of substances fed by/to Brick equipment. In that case, the simplest solution with the least impact on the current model is likely to add substance-specific subproperties to feeds, e.g., "feedsAir", "feedsWater", etc.

Any thoughts on the above, @ektrah? Also pinging @PeteHart for visibility, I know you've worked with this type of thing.

Karl

@ektrah
Copy link
Contributor Author

ektrah commented Sep 23, 2022

I think both options are valid. My preference would be to align with Brick and ASHRAE 223P as much as possible and not invent the wheel in multiple places.

@PeteHart
Copy link
Contributor

Not familiar with ASHRAE 223P so uncertain what it implies. Can say that in the implementations I've been part of it's been important to understand media (air vs water) which can be done with the different classes of Brick loops. Also important to understand how different equipments are connected, which is done by the Loop. And finally to be able to express that a Loop serves a Space, which I belive is the Brick feeds relationship. The substances you mention seem to be on a more granular level and I at least havent seen the need for them. Also agree generally that its better to align with Brick on these issues. Best Peter.

@hammar
Copy link
Contributor

hammar commented Sep 23, 2022

Thanks for the feedback on this @ektrah, @PeteHart ! We have one more stakeholder who is probably interested in this thread, @rszcodronski. Rick, I'll send you an email detailing this issue early next week, but am pinging you here for visibility/reference, in case you want to think on it before then. See also RealEstateCore/REC4#15.

@hammar
Copy link
Contributor

hammar commented Sep 28, 2022

After syncing with @rszcodronski it is evident that Willow makes use of substance modelling on feeds/isFedBy already today, and that removing it would be a blocker for REC4 adoption for them. Consequently we will have to look into how to support that use case in the DTDL models while also remaining compliant w/ Brick on the SHACL side. I'll look into this and bring something to the table here and/or at REC TC meeting next week.

@hammar
Copy link
Contributor

hammar commented Oct 24, 2022

Haven't had time to resolve this matter but it is still high on our agenda and will be resolved before REC4 GA (hopefully within a week or two).

@hammar hammar self-assigned this Nov 7, 2022
@hammar hammar added this to the Version 4.0 milestone Nov 7, 2022
@hammar
Copy link
Contributor

hammar commented Nov 30, 2022

Having hacked on this for a bit, it has become clear that implementing alignment between DTDL and SHACL on this will be too invasive in the translation tooling for us to get it done by 4.0 GA. Given the relatively minor impact, I'm marking this for 4.1 instead. By that time we should have flipped the translation around such that we can go DTDL->SHACL when needed, and thus simply filter out superfluous property graph:isms when there is no suitable SHACL representation available.

@hammar hammar modified the milestones: Version 4.0, Version 4.1+ Nov 30, 2022
@PeteHart PeteHart modified the milestones: Version 4.1, Version 4.x Dec 7, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants