The Haystack Labs WG has spent some time polishing this proposal.

We have a draft of the new proposed tags and welcome the community's input before finalizing.

Changes include new tags: portfolio and campus as well as some modifications to the site tag.

Proposed New Tags

def: ^portfolio
is: ^entity
doc: "A collection of sites"

def: ^portfolioRef
is: ^ref
of: ^portfolio
tagOn: [^site]
containedBy: ^portfolio

def: ^campus
is: ^site
doc: "A collection of contiguous sites. "

def: ^building
is: ^site
doc: "A closed structure with walls and a roof."

Some Explanatory Notes

1. portfolio is a new top-level entity.
2. building and campus both extend site. The correct usage would be campus-site and building-site. This will be added as a usage note.

Proposed Docs for Portfolio

Overview

A portfolio entity can be used as a common grouping of sites that have some common purpose, such as a single owner or property management company or a common end use. Sites belong to portfolios. Portfolios may be grouped together under another portfolio i.e. a portfolio of portfolios. For example, it is allowable to create a portfolio for separate geographic regions and those regions could be grouped together for a main portfolio.

def: ^portfolio
is: ^entity
doc: "A collection of sites"

def: ^portfolioRef
is: ^ref
of: ^portfolio
tagOn: [^site, ^portfolio]
containedBy: ^portfolio

Example

Here is an example of a portfolio entity and its child site entities:

id: @acmeLeasingCo
dis: "Acme Property Management Company"
portfolio

id: @acmeChicagoOfficeBuilding
dis: "Chicago Office Building"
site
portfolioRef: @acmeLeasingCo

id: @acmeDallasOfficeBuilding
dis: "Dallas Office Building"
site
portfolioRef: @acmeLeasingCo

id: @acmeSanFranciscoOfficeBuilding
dis: "San Francisco Office Building"
site
portfolioRef: @acmeLeasingCo

Proposed New Docs for Site

Overview

Sites are modeled using the site marker tag. Sites are used to define geographic locations or areas, while spaces subdivide the geometry within a single site. A good rule of thumb is to model any facility with its own street address as its own site. Examples of sites include buildings, campuses, and utility infrastructure sites (street lights, cell phone towers, etc.).

Tags

Core tags used with sites:

• geoAddr: the geographic free-form address of the site (which might include other geolocation tags such as geoCity or geoCoord)
• tz: the timezone where the site is located
• area: square footage or square meters of the facility. This enables site normalization by area.
• weatherStationRef: associate the site with a weather station to visualize weather conditions and perform weather based energy normalization
• yearBuilt: four digit year in which the building was constructed

Nested Sites

When sites are wholly contained by another site, they should model that relationship via the siteRef tag. For example, when a campus contains multiple buildings, each building should be modeled using the building and site tags, with a siteRef to the parent campus.

Example

Here is an example of a site entity fully tricked out with geolocation tags:

id: @whitehouse
dis: "White House"
site
building
area: 55000ft²
tz: "New_York"
weatherStationRef: @weather.washington
geoAddr: "1600 Pennsylvania Avenue NW, Washington, DC"
geoStreet: "1600 Pennsylvania Ave NW"
geoCity: "Washington D.C."
geoCountry: "US"
geoPostalCode: "20500"
geoCoord: C(38.898, -77.037)
yearBuilt: 1792

Campus Example

Here is an example of a campus site entity with children building sites:

id: @nrelGoldenCampus
dis: "NREL Golden Campus"
site
campus

id: @nrelRSF
dis: "NREL Research Support Facility"
siteRef: @nrelGoldenCampus
site
building

id: @nrelESIF
dis: "NREL Energy Systems Integration Facility"
siteRef: @nrelGoldenCampus
site
building

A few comments I missed before:

For example, it is allowable to create a portfolio for separate geographic regions and those regions could be grouped together for a main portfolio.

To do this I think we need:

def: ^portfolioRef
...
tagOn: [^site,^portfolio]

and utility infrastructure sites

I think utility here needs to be unlinked as we haven't proposed a standard definition for it yet.

yearBuilt

This might need to change to tagOn:[^building]? Or maybe it is fine as-is. I wouldn't think it would typically be used for a campus, though.