Hi All, We are working with a few University's and there is a need to model a portfolio or campus record as a collection of sites. We’d like to propose a new “portfolio” entity with a "campus" subclass. See below for details:
def: ^portfolio
is: ^entity
doc: "Collection of sites"
----
def: ^campus
is: ^portfolio
doc: "Group of institutional buildings in the same geographical area"
----
def: ^portfolioRef
is: ^ref
of: ^portfolio
tagOn: [^site, ^space, ^equip, ^point]
containedBy: ^portfolio
Interesting proposal Jon. How would you account for a University (as an example) that has multiple campuses?
Would a campusRef tag be useful?
So you have:
a site is contained by a campus and has a campusRef tag
a site is also contained by a portfolio and has a portfolioRef tag
a campus is only contained by a portfolio and has the portfolioRef tag if there are multiple campuses
As in your example the campus could also be the container of the portfolio and as illustrated you would have an entity that has the campus and the portfolio tag and it obviously wouldn't require the portfolioRef tag as it would just refer to itself!
Brian FrankMon 21 Jun 2021
Would a campusRef tag be useful?
The idea is that it works just like equipRef and nested equipment. There is one top level class portfolio and one reference tag called portfolioRef. So campus would just be a standard subtype of portfolio (we should get suggestions for other subtypes too). But in the end you would nest portfolios to whatever level of detail you needed, but applications would only care about portfolio and portfolioRef (there is no campusRef).
Its also the basic design for space and spaceRef as the generic terms for floors, rooms, wings, zones, etc and how they nest thru containment. Although there are use cases for this that aren't true containment (such as a zone that spans two rooms), and we need to evaluate if we should model that using spaceRef as a list of Refs which is currently what people are doing.
The other issue to consider is de-normalization. Currently we flatten the siteRef into all the child spaces, equip, and points. I would say that portfolioRef should be flattened into all its children (site, space, equip, and point). It makes for very easy and efficient queries. But its also kind of inelegant, so maybe its time to consider how inference with the ontology could let us move away from this brute force design.
Stephen FrankMon 21 Jun 2021
For what it's worth, within the current system we use campus + site together to create a campus entity, and building + site + campusRef to put buildings under it. It has worked moderately well. I think we could easily adapt to the structure proposed above.
annie dehghaniMon 21 Jun 2021
For nesting relationships, is there currently a 1:1 limit on the ref structure or is 1 to many possible?
Using Richard's example:
a site is contained by a campus and has a portfolioRef tag to a campus
a site is also contained by a portfolio and has a portfolioRef tag
a campus is only contained by a portfolio and has the portfolioRef tag if there are multiple campuses
Is it allowable for the site to have a portfolioRef to both the campus and the portfolio as in line 2? Or can an entity only be contained by one higher level entity?
Separately, while it is pretty useful that siteRef has been flattened to space/equip/point. I don't see the need for portfolioRef to follow that same paradigm. tagOn: ^site seems sufficient for modelling portfolios so I would propose:
tagOn: [^site, ^portfolio (optional)]
Brian FrankMon 21 Jun 2021
I think it should be based on strict containment unless there is a concrete use case otherwise (just like nested equip).
For example here in Richmond, VCU has two campuses:
In the example above, the site snead-hall is contained by the vcu-monroe campus entity, which in turn is contained by the vcu portfolio entity. Campus is just a specific subclass of portfolio.
Sade OdumuyeFri 25 Jun 2021
We also have a need for modeling portfolios and foresee the strict containment, single reference tag setup as explained by Brian generally working for our use cases. Beyond "campus", some examples of where portfolio subtypes might be helpful would be office parks, strip malls/shopping centers, or multi-family housing complexes.
Jon Schoenfeld Thu 17 Jun 2021
Hi All, We are working with a few University's and there is a need to model a portfolio or campus record as a collection of sites. We’d like to propose a new “portfolio” entity with a "campus" subclass. See below for details:
Examples:
What do you think?
Richard McElhinney Sun 20 Jun 2021
Interesting proposal Jon. How would you account for a University (as an example) that has multiple campuses?
Would a
campusReftag be useful?So you have:
campusReftagportfolioReftagportfolioand has theportfolioReftag if there are multiple campusesAs in your example the campus could also be the container of the portfolio and as illustrated you would have an entity that has the
campusand theportfoliotag and it obviously wouldn't require theportfolioReftag as it would just refer to itself!Brian Frank Mon 21 Jun 2021
The idea is that it works just like equipRef and nested equipment. There is one top level class
portfolioand one reference tag calledportfolioRef. Socampuswould just be a standard subtype ofportfolio(we should get suggestions for other subtypes too). But in the end you would nest portfolios to whatever level of detail you needed, but applications would only care aboutportfolioandportfolioRef(there is nocampusRef).Its also the basic design for
spaceandspaceRefas the generic terms for floors, rooms, wings, zones, etc and how they nest thru containment. Although there are use cases for this that aren't true containment (such as a zone that spans two rooms), and we need to evaluate if we should model that using spaceRef as a list of Refs which is currently what people are doing.The other issue to consider is de-normalization. Currently we flatten the
siteRefinto all the child spaces, equip, and points. I would say thatportfolioRefshould be flattened into all its children (site, space, equip, and point). It makes for very easy and efficient queries. But its also kind of inelegant, so maybe its time to consider how inference with the ontology could let us move away from this brute force design.Stephen Frank Mon 21 Jun 2021
For what it's worth, within the current system we use
campus+sitetogether to create a campus entity, andbuilding+site+campusRefto put buildings under it. It has worked moderately well. I think we could easily adapt to the structure proposed above.annie dehghani Mon 21 Jun 2021
For nesting relationships, is there currently a 1:1 limit on the ref structure or is 1 to many possible?
Using Richard's example:
Is it allowable for the site to have a portfolioRef to both the campus and the portfolio as in line 2? Or can an entity only be contained by one higher level entity?
Separately, while it is pretty useful that siteRef has been flattened to space/equip/point. I don't see the need for portfolioRef to follow that same paradigm.
tagOn: ^siteseems sufficient for modelling portfolios so I would propose:tagOn: [^site, ^portfolio (optional)]Brian Frank Mon 21 Jun 2021
I think it should be based on strict containment unless there is a concrete use case otherwise (just like nested equip).
For example here in Richmond, VCU has two campuses:
In the example above, the site snead-hall is contained by the vcu-monroe campus entity, which in turn is contained by the vcu portfolio entity. Campus is just a specific subclass of portfolio.
Sade Odumuye Fri 25 Jun 2021
We also have a need for modeling portfolios and foresee the strict containment, single reference tag setup as explained by Brian generally working for our use cases. Beyond "campus", some examples of where portfolio subtypes might be helpful would be office parks, strip malls/shopping centers, or multi-family housing complexes.
Stephen Frank Thu 27 Apr 2023
To close the loop: This proposal is formalized in https://project-haystack.org/forum/topic/1055