Consistency in DB service tags

[Jay911]

I just noticed something on the HomePatrol and posted about it on the HP forums, then came over here and realized it appears that way on the HP/Sentinel software, apparently, due to the design of the RRDB.

This might seem like a nitpicky little thing to gripe about, but it's there nonetheless.

The law service tags all appear without dashes, as in "Law Dispatch", "Law Tac", and "Law Talk". The other three main public safety related batches of service tags use a dash in between each word, i.e. "Multi-Dispatch", "Fire-Tac", "EMS-Talk".

IMO it should be standardized one way for all 12 service tags ("Dispatch", "Tac", and "Talk" for each of "Law", "Fire", "EMS", and "Multi"). My preference would be without the dash, but that's just me.

 

[kb32]

I just noticed something on the HomePatrol and posted about it on the HP forums, then came over here and realized it appears that way on the HP/Sentinel software, apparently, due to the design of the RRDB.

This might seem like a nitpicky little thing to gripe about, but it's there nonetheless.

The law service tags all appear without dashes, as in "Law Dispatch", "Law Tac", and "Law Talk". The other three main public safety related batches of service tags use a dash in between each word, i.e. "Multi-Dispatch", "Fire-Tac", "EMS-Talk".

IMO it should be standardized one way for all 12 service tags ("Dispatch", "Tac", and "Talk" for each of "Law", "Fire", "EMS", and "Multi"). My preference would be without the dash, but that's just me.

I too have noticed that and agree with you that all should be without the dash.

 

[Baylink]

I disagree: tags are generally *single words*, so you can tell where each one starts and ends; I personally advocate using the hyphens, rather than not. It reduces a *whole bunch* of confusion otherwise necessary.

And FWIW, while I have not actually tagged anything yet, I do hope that taggers are presented with a sorted list of all the tags already extant, and asked to pick one of those, before optionally creating a new one...

 

[Jay911]

You can't create new service tags. There are a fixed set of tags to choose from.

And I don't see how "Fire-Tac" is better than "Fire Tac", quite frankly. I also don't see how one can get confused without the dash.

 

[Baylink]

And I don't see how "Fire-Tac" is better than "Fire Tac", quite frankly. I also don't see how one can get confused without the dash.

Fire Tac Law Talk Maintenance

How many tags is that?

Fire-Tac Law-Talk Maintenance

That?

 

[GTR8000]

Fire Tac Law Talk Maintenance

How many tags is that?

Fire-Tac Law-Talk Maintenance

That?

I think you're confused. There can be only one tag assigned per entry, so there's no situation where you'd see "Fire Tac Law Talk Maintenance". You'd either see "Fire-Tac" or "Fire Tac", where it makes no difference if there is or isn't a hyphen. Jay's point is a valid one: either use the hyphen for all tags, or drop it from all tags...but keep it consistent, not a mixture.

 

[Baylink]

Oh, of course. These aren't "tags", as we know that unadorned jargon noun in the year 2010. They're "category descriptors". Tags there can be more than one of attached to an object.

Given that, I don't care which way they go either. I suspect we might see a case where one word of a tag must itself be hyphenated. So no hyphens is my suggestions.

 

[Jay911]

Fire Tac Law Talk Maintenance

How many tags is that?

Three.

Fire-Tac Law-Talk Maintenance

That?

Three.

How many do you expect to see on a given channel, i.e. a HomePatrol's display?

Oh, of course. These aren't "tags", as we know that unadorned jargon noun in the year 2010. They're "category descriptors". Tags there can be more than one of attached to an object.

No, no, and no. What I describe in my original post are service tags. They are defined by RadioReference to categorize frequencies and talkgroups. They are definitely tags, as defined by the RadioReference database.

 

[Baylink]

Wow; it's so nice that I can't quote the part you're replying to.

If you're saying "three tags" to both of those, then I'm goin with "You're makin' it up, for 600, Alex".

The only way to be able to look at those two strings, one hyphenated and one not, and come to the conclusion you did, is to admit background knowledge of the tag cloud -- I was *hoping* that it was implicit in my query that such knowledge wasn't admissible in that context, but I guess not.

Feel free to call them "service tags". Just understand that if you abbreviate that on first reference to "tags", J Random Reader is highly likely to misunderstand -- as I did -- what you mean by it.

Ths thread has nothing to do, at this point, for me, with RR's database; it is about generic technical terminology in the current day.

 

[Jay911]

Baylink, I'm pretty sure you're misunderstanding the whole concept being outlined here.

Here is a completely random example - go to Clark County, Nevada (NV) Scanner Frequencies and Radio Frequency Reference and follow along.

On the right side of every frequency in the list on that page, there is a column called "Tag". Hover your mouse over the word "Tag" and it will describe the column for you as "Service Tag for this frequency". Service Tag is a term defined by RadioReference's database structure for the purpose of identifying what purpose a frequency (or talkgroup) is for. There is no "wiggle room" for interpretation or debate; this is the Service Tag.

The service tag is utilized by some modern scanners and software packages to identify particular groupings of frequencies or talkgroups. For example you could tell a software package to download only frequencies matching "Law Dispatch", and all frequencies with other service tags would be skipped.

There is no situation at all in which your hypothetical example above - with three different service tags appearing together - would be possible. The design of the database simply prohibits that situation from occurring.

The issue that I described in my first post in this thread is that some service tags use dashes and some do not. It's purely an aesthetic gripe, but they all should follow one format or another. As far as I'm concerned, visually, the absence of the dash is more sensible. The world will not end if the decision is made to go the other way and insert dashes into the Law tags, but one way or another, a decision should be made.

As for whether or not I have "background knowledge" of the "tag cloud" (?), given that I was a database admin here for a number of years, I guess I do.

Ultimately, this thread is not for "J. Random Reader" as you put it. It's for the benefit of the DB admins and the webmaster. I will say, however, it takes a lot of guts to come into a thread and tell the original poster that he has no idea what he's talking about, when you yourself demonstrate a clear lack of understanding of the topic at hand.

 

[Baylink]

Not misunderstanding the concept, no, but I see that I'd missed that you were, in fact, calling them "service tags" right along.

My apologies.

> There is no situation at all in which your hypothetical example above - with three different service tags appearing together - would be possible. The design of the database simply prohibits that situation from occurring

And yes, we'd already established that I got that.

 

[hfxChris]

Ths thread has nothing to do, at this point, for me, with RR's database...

You may be in the wrong discussion then, as that's what this is about...

 

[Baylink]

Yes, Chris; we'd already cleared up the confusion, and disposed of the issue.

 

[loumaag]

Let me comment here in relation to Jay's original point.

At this point they probably cannot be changed to establish a consistency. All software/hardware vendors have been working with list as it was established, to change those would probably cause unnecessary problems for a semantic non-issue. Clarity is not lost the way they are and nothing is actually gained by any change to the list to align them.

 

[b52hbuff]

Looking at the SOAP API, it looks like the tag information is transferred as an integer. Take a look at this:
NuSOAP: RRWsdl
...and click on 'getTAG' to see the parameter definitions:
message: getTagRequest
parts:
id: xsd:int

So I suspect the service tags are stored and transferred as an enumerated type. My guess is that changing how the enumeration is displayed would require updating the various presentation applications (e.g. rr.com web app, starsoft programs, uniden programs). As long as the definition of the values was the same (and it would be), it would just be a nuisance to see differences in how these values were displayed.

More information on RR.com API is here:
API - The RadioReference Wiki

And since we're so fond of the HP-1, here is a snippet from it's internal file:
C-Freq CFreqId=42 CGroupId=13 Sheriff Countywide (Control 1) Off 156210000 AUTO TONE=C179.9 2

The last number '2' is the service tag for 'Law Dispatch'. So if Uniden wanted to 'fix' the issue for you, all they'd need to do is to change the table where they translate '2' into 'Law Dispatch'. Or however you wanted to display the data.

So the change could be done. The change would be trivial. It should be made across multiple platforms, to reduce confusion. But if it were rolled out incrementally, or even partially done, it wouldn't effect operation, since the data encoding is really based on the integer and not a string.

It wouldn't necessarily have to involve RR.com, but they could also change the display strings.