Clearance among Name, Source Name, SourceIdentifier, ID, UUID

[jbkoh]

There are currently four different 'names' of an entity in BuildingDepot as Name, Source Name, SourceIdentifier, ID, UUID (UUID is currently a combination of Type and Name.)

Do we have any clear definitions distinguishing those items? I think we just need one of them and a random string UUID.

[bbalaji-ucsd]

As I was responsible for creating two of these, I can answer why those exist. Source Identifier -> BACnet Identifier Source Name -> BACnet Name If the point is not from BACnet, then use the corresponding source. This was important to preserve to basic operations. Regards, Bharath

…

On Wed, Jul 12, 2017 at 3:42 PM, Jason Beomkyu Koh ***@***.*** > wrote: There are currently four different 'names' of an entity in BuildingDepot as Name, Source Name, SourceIdentifier, ID, UUID (UUID is currently a combination of Type and Name.) Do we have any clear definitions distinguishing those items? I think we just need one of them and a random string UUID. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#49>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADFqQvVgABZ2wEKXHJnicYR_4dN94yMlks5sNUvsgaJpZM4OWS9S> .

[jbkoh]

I see. We'd better document this at some point.

Btw, what was the reasoning of putting this as columns instead of using Tags?

[joshuagluck]

UUID is currently a combination of Type and Name as a part of Brick integration. An easy to understand label (Name) was needed to perform searches on, so that Users could potentially search through the Brick graph (e.g. the results would have meaningful names, not just random UUIDs).

We combined Type and Name (Type:Name) to provide additional description to these values, as well as to increase the size of the namespace (so you know the Brick type of whatever you're working with, at the very least, and you can name multiple different entities with different types the same thing, if you want, without it being a problem).

It was additionally decided we wanted to ensure that these Type:Name's were unique, to avoid redundant and extraneous sensors from being created (how do you know which one is the one you want, otherwise). Since Type:Name had to apply to every entity, and Type:Name had to be unique, there was no reason to generate a separate random UUID. No reason we couldn't have an additional random UUID, I just don't know what the point would be?

[jbkoh]

There are redundant information in those columns and I am trying to understand the differences. A user would have more difficulties. For example, you put "identifier" to both "source_name" and "source_identifier", which has no usage and is different from their original purposes that Bharath described. Another discomfort is that a user can't search a sensor with the name that the user provided as it vanishes with the combination of EntType. I do not think we need to combine EntType and user-given name for UUID but it'd better using the user-given name directly. The uniqueness requirement remains at the same level (I don't think people would use a same name for different EntTypes.) If we separate out Name and EntType from UUID, it will be clearer for a user while both information is reachable from anywhere else both through REST APIs and the web UI. I would suggest in the future

1. a user provides UUID (or call "name"). If not given, generate a random string (standard UUID)
2. other information is encoded as Tags (or in further future, no tags but edges.)

Removing redundancies and clearing up the usage will be more attractive.