>
```
Since property types don’t specify package names, we don’t know which type/class is meant. In the above example either EXPR\_TYPE\_DEF from “lang\_100” or from “expression\_104” could be used.
This wasn’t an issue before “lang\_100” and “proc\_100” since before that all the classes were globally unique.
I’m I missing something and non-unique class names can be used for properties without also specifying their package?
---
### Author:  [@sebastian.iancu](https://discourse.openehr.org/u/sebastian.iancu)
#### Post date: [12 November 2021 11:34 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/3 "2021-11-12T11:34:43Z")
I think there is a need for a package dependency maps: some specs release requires others to be used, or are not compatible with others.
I this case (@thomas.beale better correct me), the EL was part of BASE 1.0.4, but later was extracted as a separate component EL 1.0.0 (which supposed to be used with BASE 1.1+). There are similar issues on AM 1.4 and AOM Profile vs BASE, or BASE vs RM 1.0.2. this dependencies are nowhere expressed in a computational form (as far as I know).
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [12 November 2021 11:59 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/4 "2021-11-12T11:59:11Z")
The EXPR\_TYPE\_DEF classes were experimental and are discontinued, so you could rename this however you want; for EVENT, I suggest for now you rename it in your private clone as ‘PLAN\_EVENT’, which we’ll probably do one day anyway. No need to complicate things in your local setup for now.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [12 November 2021 12:17 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/5 "2021-11-12T12:17:44Z")
OK. I’ll rename it locally for now.
I’ll rename EVENT to BASE\_EVENT, since PLAN\_EVENT already exists in PROC.
* * *
I guess this means that I can stop adding support for namespaces when validating BMMs 🤔
---
### Author:  [@erik.sundvall](https://discourse.openehr.org/u/erik.sundvall)
#### Post date: [12 November 2021 17:58 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/6 "2021-11-12T17:58:53Z")
Having unique class names would be great for keeping the upcoming URN syntax short/compact too.
---
### Author:  [@borut.jures](https://discourse.openehr.org/u/borut.jures)
#### Post date: [12 November 2021 19:04 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/7 "2021-11-12T19:04:23Z")
I see two options at the moment:
1. Use package name + type name when specifying property type in BMMs. That would be unreadable due to the length.
2. Keep using class names as globally unique. This doesn’t mean we shouldn’t use namespaces for working classes (I use short URL but in the backend I use package names + class name).
Most class names are unique without trying. Only the EVENT in PROC is non-unique and it can get some prefix to make it unique.
To me the most important part of having unique names is that everybody knows about which class we are talking about (without mentioning its model/package).
---
### Author:  [@thomas.beale](https://discourse.openehr.org/u/thomas.beale)
#### Post date: [12 November 2021 19:45 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/8 "2021-11-12T19:45:27Z")
> [@borut.jures](#):
>
> To me the most important part of having unique names is that everybody knows about which class we are talking about (without mentioning its model/package).
That is our general approach as well; I’m not sure why we didn’t call PROC:EVENT something unique. But this can be changed, so we can solve it.
---
### Author:  [@pablo](https://discourse.openehr.org/u/pablo)
#### Post date: [12 November 2021 19:55 UTC](https://discourse.openehr.org/t/globally-unique-class-names/2068/9 "2021-11-12T19:55:55Z")
IMHO with package+class being unique is enough, though having all classes from all models banned uniquely would be a quality sign.