#929 Portfolio Entity

Jon Schoenfeld Thu 17 Jun

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


id: @campus
dis:"Some Campus"
id: @buildingA
dis: "Building A"
portfolioRef: @campus

What do you think?

Richard McElhinney Sun 20 Jun

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 Frank Mon 21 Jun

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 Frank Mon 21 Jun

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 mroz Mon 21 Jun

For nesting relationships, is there currently a 1:1 limit on the ref structure or is 1 to many possible?

Using Richard's example:

  1. a site is contained by a campus and has a portfolioRef tag to a campus
  2. a site is also contained by a portfolio and has a portfolioRef tag
  3. 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 Frank Mon 21 Jun

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:

id: @vcu
portfolioRef: @vcu
portfolioRef: @vcu
id: @snead-hall
portfolioRef: @vcu-monroe

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

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.

Login or Signup to reply.