I'm interested in how namespaces work in Haystack 4.0, for example in ASHRAE Standard 2016 they state that tags defined by an organisation other than ASHRAE should be prefixed with a Java style `com.example.custom-tag'.

Haytstack 4.0 is organised into what I believe you call libraries which act like namespaces (ph, phIoT etc.). But looking at the defs - for example equip - they don't explicitly reference the library of the defs they use. In this example equip is from phIoT yet but it derives from entity which is defined in ph.

def: ^equip
is: ^entity
docTaxonomy
mandatory
doc: "Equipment asset"
children: [
  {equip},
  {point},
  ]

Are you assertingthat the main ph* namespaces are always "imported" and don't need qualification? If I wanted to add my own tags in my own namespace how would I do that - say I added my extensions in folder called "com.example" and created a trio definition for tags which may be added later to phIoT is there a syntax to disambiguate from "com.example:tag" and "phIoT:tag"?

Also is there any tooling available for Haystack 4.0 yet - i.e to compile the schema to RDF or is that a work in progress?

Haytstack 4.0 is organised into what I believe you call libraries which act like namespaces (ph, phIoT etc.).

Its better to think of them as modules like a programming language versus namespaces like XML or RDF. A library scopes its definitions under a globally unique module name. Then a given model declares which libraries it uses so that you can determine the definitions of each tag.

Currently a given model cannot use two libraries with the same tag name. The future solution to that problem would be to use an "import alias" design more akin to how a programming language would work (such as C# using alias).

Since overlapping names should be rare that keeps instance models much simpler to read/write/use (for all the same reasons most programming languages don't require you to prefix every type name with a namespace at each declaration site).

Also is there any tooling available for Haystack 4.0 yet - i.e to compile the schema to RDF or is that a work in progress?

The RDF scheme for the standard definitions can be downloaded right now from here - is that what you are looking for?

Since overlapping names should be rare that keeps instance models much simpler to read/write/use (for all the same reasons most programming languages don't require you to prefix every type name with a namespace at each declaration site).

I agree it's much simpler (but most programming languages also allow you to use the prefix if you are using two modules that import the same identifier). I'm not sure it is necessary except for the fact that ASHRAE appears to mandate it, i.e. their goal seems to be the taxonomy authority under 233p so tags added by vendors that perhaps have different semantics to the ASHRAE 233p tags are supposed to be prefixed according to ASHRAE STANDARD 135-2016 (i.e. if using the new(ish) Tags object - which I've not actually encountered yet on a commissioned BMS).

My other question on the custom tag to define a compressor tag is probably relevant. That's something that will probably clash with a ph tag at some stage as it makes sense to add it.

The RDF scheme for the standard definitions can be downloaded right now from here - is that what you are looking for?

Thanks, I'll take a look. Ideally, I'd be able to define an instance in trio and validate (i.e. automate the compilation to ttf and validation against the RDF) rather than creating an RDF instance as trio is easier to work with but that will work for now.

PS In the alpha example CH-1 is rdf:type phIoT:elec-meter, it should also be a union with phIoT:chiller if I'm not mistaken?

alpha:a-0766 a phIoT:elec-meter ;
    ph:hasTag phIoT:chilled,
        phIoT:chiller,
        phScience:elec,
        phIoT:equip,
        phIoT:hvac,
        phIoT:meter,
        phScience:water,
        phIoT:waterCooling ;
    rdfs:label "Alpha Waterside CH-1" ;
    phIoT:chilledWaterRef alpha:a-07b8 ;
    ph:dis "Alpha Waterside CH-1" ;
    phIoT:equipRef alpha:a-07b8 ;
    phIoT:siteRef alpha:a-0000 .

Was this generated by a tool from the trio file? Or did you manually follow the steps in Rdf.fandoc?

... their goal seems to be the taxonomy authority under 223p so tags added by vendors that perhaps have different semantics to the ASHRAE 223p tags...

You are correct, the BACnet Committee has not come to a consensus on the names and what those names mean, but generally agrees that the names that are defined by the committee should follow the same proposal submission, review, public review and comment period, and publication process as anything else defined by ASHRAE.

The standard has a syntax for simple tag names that are reserved for ASHRAE (those without a prefix) and those used by an organization with a registered vendor identifier, or with the very Java-like reversed DNS prefix. So "temp" is reserved for ASHRAE (along with all the names like "0-anything") and Haystack can use "876-temp" or "com.project-haystack.temp".

This prefix syntax is adopted from CSML (ASHRAE 135-2012 Annex Y.1.4) and works fine for XML document exchanges but not so well with the Semantic Web and Enterprise Knowledge Graphs. Just like processing CSML and other XML-based data documents, these names would go through another translation process to turn them into IRI's. There are no proposals on what kind of schema document would be published so that an organization can say that "999-temp" is a subclass of "876-temp" or "0-temp" or any other temp-like tag.

There is another addenda, Annex-BO that hasn't been adopted yet, that breaks the history with XML and more closely aligns the name/value pairs with the predicate/literal content of RDF. It is quite like Turtle, so the phScience:air style names would be perfectly acceptable. The BACnet Device Object would have the phScience: prefix defined as https://project-haystack.org/def/phScience/3.9.7# or whatever version or namespace is being used.

If this moves forward, organizations are free to publish their own ontology using any of the usual file formats like Turtle, JSON-LD, or RDF/XML and that specifies exactly what the organization defines their tags to mean. For example, Cornell University could publish cu:cstemp as being a condenser supply temperature, and the value of the "tag" is the chiller identifier, very similar to the Utah Tagging Standard. The ASHRAE model will be published in http://data.ashrae.org/standard223/.

I believe, and others do as well, that the reason why you haven't seen this widely adopted right now is because ASHRAE has not yet published its "tagging dictionary."

PS In the alpha example CH-1 is rdf:type phIoT:elec-meter, it should also be a union with phIoT:chiller if I'm not mistaken?

Its not designed to assume that all chillers are also elec-meters in the meta model. However if you have an instance of a chiller that also measures electrical usage, then that instance would implement both of those types.

However, note in the current working ontology in GitHub we have added the elec-input type to the chiller equipment type with the assumption that all chillers do input electricity.

However, note in the current working ontology in GitHub we have added the elec-input type to the chiller equipment type with the assumption that all chillers do input electricity.

Thanks Brian, yes I did notice after I posted that github ontology has been updated cf the RDF on the Website. It makes sense as in my experience whilst chillers are electric equipment the meters are attached the compressors(s) of which there is often (in the Australian buildings I've investigated) two. So in order to work out the chiller electrical consumption, you have to traverse down a tree to the meter nodes (similar with the CHWS which has multiple potentially metered points ie. the pump vsd'd, fan vsd's, compressors etc). So I feel the need to tag the actual points which provide a kWe value so I can select a root node and all the kWe points below it.

And thanks to Joel for the useful context. Has the 223P working group published anything publically? My understanding is based mostly on press releases and a number of presentations I've come across.

... with the assumption that all chillers do input electricity.

The first time I heard about a steam driven chiller was "wait, what?" moment.

Has the 223P working group published anything publically?

No, nothing yet. The next thing published will be an "advisory public review" which is like a beta version, where a "public review" is like a release candidate.

Looking at the "protos" today - seems like an excellent idea, I don't see how you can enforce consistent tagging unless you have some form of a template.

They don't seem to be in the defs.ttl file yet, other than as string values, i.e. ph:children "ZincDict(\"{air co2 point}\")"^^ph:xstr seems to be the only reference to the air co2 point proto that I can find.

Will they eventually make it in as an owl:Class? It seems to make sense, it would certainly make it easier to link to other ontologies if Haystack included prototype classes for common equipment or points?

Brick is an ontology that does exactly that, creates a distinct class name for a specific concept based on OWL, and since these concept models exist in the same domain its not entirely surprising that they use similar labels. But apart from having a notion that something has a tag, the two are very different.

Both Haystack tags and Brick concepts and tags can coexist in the same graph, project Hasty is making a cross reference of the concepts between them.

They don't seem to be in the defs.ttl file yet, other than as string values

This is an oversight, we should probably expand those in RDF

Will they eventually make it in as an owl:Class?

Prototypes are not "classes" per se - they are templates for instances. The fundamental design issue always comes down to how far to take the class hierarchy. If you take it too far you then end up with essentially a type per instance. If you don't take it far enough you don't have "named" things that are useful enough for interoperable models.

There is no clear answer for the right balance on this yet. The mechanism for generating new "types" (which would be owl:Classes) is the conjunct. For example if we wanted a first class type we could coin discharge-air-temp-sensor. We don't currently have that today, although the framework supports it just fine. Most discussions around first class types tend to boil down to something which might have a SKU. For example an air-temp-sensor makes sense because its a specific part. But adding role/context into the type such as discharge-air-temp-sensor makes things fuzzy from that same perspective since I can move that same sensor from the discharge duct to another duct. Although you can easily argue from an application perspective that the role/context is a first class "type".

But in lieu of a solid requirement to take things that far, we've decided to play it safe and keep the point hierarchy very shallow. Prototypes fill a gap at least from a tooling/documentation perspective. But I am not sure how well they will work for validation, which is a prime goal for 2021 to figure out.

I understand what you're saying, it's really only a discharge-air-temp-sensor because we prefer flat over a nested representation. Discharge is actually a property of the thing it's attached to and not the thing itself.

One thing I have been thinking about - how do you ensure that when you query the graph (specifically using SPARKL) via tags that you only get the points you expect and not a superset.

i.e. say you want all supply-air-temp-setpoint's - you have to query for all point instance which have these tags. But you also don't want them to have additional tags - perhaps some devices have settings such as max-supply-air-temp-setpoint and min-supply-air-temp-setpoint for example? If I do something like

SELECT ?entity
WHERE {
    ?entity ph:is ph:marker
}

I get tags that identify the point type such as air, temp etc. But also tags that provide additional metadata (ahuZoneDeliveryType etc.).

How do you resolve this? How do I say "give me all points which have {supply air temp setpoint} but no more?

Also what's the best way to report missing tags - here, github or some other forum? I've identified a number of chiller related tags which may be omitted, particularly compressor, min and max etc. There's only a handful but they're used quite frequently on our buildings.

Its a good question. For the past few years, the design requirement is that whenever a "contextual" tag is added to narrow a type, that there is always some term you can use in your query to match it. Its talked about as something like "query not rule", in that you should never have to query the absence of tags.

A good example is the zone temp tags described here - where typically unless you know want occ/unocc cooling/heating setpoint, you query for the "effective temp sp" tags.

I am not sure what you are referring to with min/max - I don't believe there are any point prototypes currently using that. Right how min/max is only defined as the value tags minVal/maxVal. But if you did see something that doesn't follow those narrowing rules post it on the forum please.

Yeah sorry, that was conceptual - I was going to raise that min/max are also not tags at the moment. We have a considerable of points that require these tags since the BMS presents them as points (i.e. they're the upper / lower limit of some sp (or maybe a design value) available as a bacnet object). You probably could use minVal / maxVal on the sp point - but then you'd have to ensure they stayed in sync with the BMS.

Another case is fault indicators, I encountered a chiller where many of the sensors have two values, the measurement, and a fault indicator. {chilled water leaving temperature sensor} vs {chilled water leaving temperature sensor fault}.

I'll post a separate message with the concepts I couldn't find a model for.